[Buildbot-devel] Volunteering and some suggestions.

[Dustin J. Mitchell]

On Wed, Dec 23, 2009 at 3:14 PM, Marcus Lindblom <macke at yar.nu> wrote:
> Perhaps we could steal^h^h^h^hadopt some procedure from twisted, that
> has a bunch of extra fields for patches such as 'has patch', 'patch
> needs improv', 'need test', 'need doc'. Etc.
>
> Then ppl could triage better, and we could more easily see which patches
> are applicable or not.

I like this, but without a commitment to set those fields
appropriately, I'm not sure it would make much difference.  I'll say
it so you don't have to: my laziness is an important factor in this
discussion.

We should probably think carefully about what we want Trac to be for.
I see three *separate* categories of artifacts we might want to track:

 1. features (patches)
 2. bugs (things that need to be replicated, investigated, and eventually fixed)
 3. support requests
 4. enhancement requests

Of course, the boundaries between these categories are porous - a user
may present something as a bug that is actually a support request, or
a bug might become a feature as it gets fixed.

We have other communication channels in use, too:
 a. github (**great** for patches!!)
 b. #buildbot (good for support requests)
 c. buildbot-devel (good for support requests and bugs)
 d. Trac (good for bugs)

At this point, I'll take patches on any of those channels, but I'll
admit I'm not equally responsive on all of them.  I would prefer to
share the support burden with others in the buildbot community, so
support requests should get directed to the channel(s) with the most
eyeballs and best reaction time.  Buildbot bugs often require a lot of
back-and-forth, and sometimes have no real solution, so those are best
kept somewhere that can organize their history and track their
evolution.  Enhancement requests are tricky - they are quite popular,
but since most devs scratch their own itches, enhancement requests
generally lie fallow forever in the "0.7.+" milestone.

So in writing the above I've convinced myself that we should take
measures to *only* allow bug reports in trac.  Which means that we can
make an effort to close out the other stuff, and then have a much
leaner Trac.

Other opinions?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com