On Thu, 24 Jan 2013 06:50:39 -0500 (EST)
Kamil Paral <kparal@xxxxxxxxxx> wrote:
<snip>
> > It's also worth considering the possibility that blocker tracking
> > could
> > be moved out of BZ itself and into the blocker webapp; this has
> > several
> > advantages, like better integration with the webapp, reducing BZ
> > spam,
> > and giving us a mechanism for asynchronous review of blockers
> > without BZ
> > spam. So that may possibly be the best option, but it depends on
> > someone
> > (hi Tim!) having time to write the code. Still, it's one of Tim's
> > long-term plans, and people may feel it's best to stick with tracker
> > bugs until we're ready to go to that plan instead of using flags as
> > an
> > intermediate step.
>
> Actually I thought about this just a short time ago when looking at
> Tim's new proposal of blocker submission form. We could manage all
> that information outside of Bugzilla. What does it bring us?
>
> 1. faster, better interface (probably)
> 2. less BZ spam
>
> but also
>
> 3. lots of extra work to duplicate basic functionality - the tracker
> app has to be able to manage the list (add/edit/remove items), do
> authentication/authorization (not everyone can do everything), offer
> notifications, and many more. We are given that automatically by
> using Bugzilla. 4. obligation to maintain it - if something goes
> wrong with our current tracker app, we can fall back to Bugzilla just
> fine, it's just a bit less convenient. If we move the data into the
> app, we depend on it completely.
>
> I think, for the time being, it's just better to use Bugzilla as a
> backend and create a pretty UI for it, as we currently have. We're
> quite scarce on human resources even now, I wouldn't want to put more
> maintenance burden on us. The benefits of leaving Bugzilla doesn't
> seem to outweigh the drawbacks.
I see a couple of potentially large benefits to creating/maintaining
our own system.
1. Enabling more asynchronous conversation around blockers
- I see this as a potentially huge benefit with the potential to
reduce the amount of time we spend in review meetings and not
implicitly excluding people who can't attend those meetings.
2. Making queries faster (although this is mitigated by using the
current tracker setup as a cache)
- The bz queries that we're using right now are pretty complicated
and slow. Interfacing with external systems is pretty slow, in
general and is the primary reason why the tracker only syncs
every 30 minutes. That's probably overkill but there are times
when the sync can take 10 minutes or more.
I have no intention of writing all of that code from scratch; in my
mind that would be pretty much the definition of insanity or
naïveté (depending on how you look at it and how generous you're
feeling). There is software out there which could form the base of such
a system without making upgrades intractable and hopefully would end up
being most of what we want/need.
Tim
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
