[Buildbot-devel] Volunteering and some suggestions.

[Marcus Lindblom]

Gavin wrote:

> 2. I think it would benefit this project _greatly_ if Buildbot Trac Issues
> were linked to the mailing list. All Issue activity I feel should be relayed
> to the list so everyone knows what's happening there. Having this current
> discontinuity between the list and the open issues is stifling progress.
> People will go to the Issue Tracker and get more involved I feel if they can
> see what is going on from their inbox. There are many patches there and
> recent issues that some folks here probably have no clue about unless they
> remember to check the tracker. The issue tracker is just a nice way to file
> issues, but the mailing lists is where it all happens.

The trac time line can be an rss-feed. I use this to keep track of wiki 
edit and ticket changes. I also use github's rss-feed to keep track of 
the repo (Dustins, mine and a few others I follow.)

Thus, I don't really feel the need for automated e-mails on the list. I 
like that it's human only.

But it's just my personal 0.02 SEK (i.e. not much at all, these days ;) 
and I'm willing to follow public opinion.

> 3. Going through the Issues, there are quite a few with what seem like
> trivial patches already attached. Some many months old. Some of those people
> have spent time working on the project to help improve it for their own and
> everyone elses benefit, and provided some nice diffs etc. How much easier
> does it need to be? The moral of some of these folks will wain if their
> patches are left hanging on an issue tracker for weeks or months at a time.
> 
> I wonder if Trac can be configured or a custom feed configured to send an
> email once a week to this list for all issues that contain a patch, is that
> do-able?

We could add one or two custom fields to Trac, similar to Twisted's 
Trac, that indicate whether a patch exists and if it's good enough. Then 
we just have a wiki page with a TicketQuery() macro or two to list all 
suitable tickets.

> I have just downloaded the latest trunk, would it help if I rounded up a few
> of these patches and other ideas and applied them to my copy? Then a one off
> merge to trunk (or a branch for testing by others if need be) would be
> easier and time saving for you guys? Let me know if you want me to do that.

Putting them in your repo is always a good plan, as it's easy to pull, 
merge and test and all that.

However, it'd be best to have a separate branch for each bug (or sets of 
bug that relates) if some of them need more testing/work before they are 
ok to merge. It all depends on how much they interact, but if you fix 
from 10 bugs on one branch and a few fixes in the middle cause 
regressions we might have to avoid the whole lot until it's fixed.

I'm sure you know this.. use good judgement and all, but I feel  it's 
worth repeating every now and then, IMHO.. (especially to myself) ;)

Cheers
/Marcus