Brainstorming tasks for next sprint

Hugh Brock hbrock at redhat.com
Tue Feb 14 16:48:32 UTC 2012


On Tue, Feb 14, 2012 at 11:44:54AM -0500, Scott Seago wrote:
> On 02/14/2012 11:42 AM, Hugh Brock wrote:
> >On Tue, Feb 14, 2012 at 11:30:08AM -0500, Jason Guiditta wrote:
> >>On 14/02/12 10:59 -0500, John Eckersberg wrote:
> >>>On Tue, 14 Feb 2012 10:46:24 -0500, Jason Guiditta<jguiditt at redhat.com>  wrote:
> >>>>Better patch management than just sending to list.  This is a _very_
> >>>>long-standing issue that we need to attempt (again) to resolve.  I am
> >>>>not against trying pull requests in github (probably on some trial
> >>>>basis, with a small group vetting it and assembling feedback, so as to
> >>>>not throw everybody off on something we may or may not keep).  There
> >>>>are also a number of other projects around for this kind of thing that
> >>>>we could pilot - patchwork and gerrit in the public space, and our own
> >>>>(not the best name) trapaas, that resulted from some work mzatko did
> >>>>for me when he was an intern (think the code is on github, not sure in
> >>>>what state).  I am sure there are plenty of other options we coudl
> >>>>consider, these are just a couple I remember from last tiem I looked
> >>>>at this problem.  But the fact remains - the list is a poor patch
> >>>>management tool, and is insufficient for our needs.
> >>>Yes, this.  I'm curious, given the "attempt (again)" bit, what has been
> >>>done in the past to try and correct this (and ultimately failed)?
> >>The part that always fils is agreement and support of any specific
> >>path.  Someone always pipes up with either 'this is how we do it at
> >>red hat', or "if it's good enough for<insert project>, then it should
> >>be good enoughfor us, what is wrong with you people anyway?'.  I say
> >>enough of tht, and let's try to improve this thing now.
> >As an avid *reader* of the patch flow and the review discussions
> >around patches, I would only ask that the team preserve that aspect of
> >the current setup -- meaning, please don't take away my ability to
> >track everything that's going on with Aeolus code simply by reading
> >the mailing list.
> >
> >Beyond that, as far as I'm concerned it's up to the team to
> >decide. I tend to think that Github pull requests obscure the
> >development discussion more than I would like by pulling the
> >discussion off mail and onto web pages, but again that's just my
> >opinion.
> >
> >Thanks,
> >--Hugh
> >
> Yeah, following patches that I'm not actively reviewing on the
> mailing list is indeed convenient. What is _not_ convenient (and,
> indeed is a bit of an nightmare) is looking at the mailing list
> archives/local folder/whatever and answering questions like "what
> patches are outstanding?" "what's being reviewed?", "is
> <developer-foo> waiting on reviews?", etc. This is what we need to
> fix in one way or another.

Seems easily fixable by something like Trapaas or one of the other
solutions.

(/me suppresses urge to explain how easy it is to do above with
mutt...)

:)

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list