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