[Buildbot-devel] Volunteering and some suggestions.

[Marcus Lindblom]

On 2009-12-23 22:52, Dustin J. Mitchell wrote:
> 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?

I like having feature requests in Trac too (however, I'm quite the fan 
of Trac and similar systems), however we could/should keep those on a 
"To be determined" or "Feature requests" milestone until they are 
implemented, to avoid too much clutter. It helps to know if other people 
have similar itches when I decide to scratch my particular one.

For patches, I agree github is probably the best medium for transferring 
patches. It's also so easy to set up for the contributor, and _very_ 
easy for us integrators to pull/test/apply from, so we could almost 
singlehandedly use that for accepting code contributyions. It's also 
possible to see, beforehand, if other commits would apply cleanly, and 
it's reasonably easy to ask for improvement etc etc and have others keep 
their patches in sync with the current HEAD. Patch-files in Trac tend to 
go stale (i.e. don't apply cleanly) whereas github has a view that 
automatically checks this.

(Sidenote, I sometimes find myself wishing a ticket that refers to and 
describes what's been changed and how discussion goes, as I sometimes 
find it non-obvious to figure out from a 'pull request' what the point 
of it all is.)

(Related, I really like the naming of branches to ticket-numbers (i.e. 
'bug473') in git, because it makes it very obvious what's going on and 
it's possible to use stable identifiers/URLs when pointing to the work 
on Github.)

But, I might be more trac-happy than most (Trac part of my paying work, 
and I'm the main proponent of structure and general ordnüng at my shop), 
so if it's too much for folks here, I can probably live with other 
workflows as well.

Cheers,
/Marcus