Open Stack

I agree with the spirit of what you're saying, but if you're working on a new feature, you should have a blueprint.  Just like when you're fixing a bug, you have a bug report.  We've gotten people mostly out of the habit of committing bug fixes with no bug report.  Now we have to get people out of the habit of committing features with no blueprint.


- Devin


On Mar 28, 2011, at 11:32 AM, Todd Willey wrote:

> Open == Accessible.  Open != Verbose.  I'm willing to discuss more at
> the design summit, but my biggest concern is that we let the most
> people possible can contribute.  This includes those who work behind
> closed doors on their own pet projects.
> 
> This thread started specifically in response to a few branches that
> didn't hinder anyone else's work, but also didn't have blueprints.  So
> what?  Blueprints should only be required for coordination when doing
> large work that can conflict with others'.  Code should be the only
> artifact required to contribute, as that will keep contribution more
> accessible.  If these proposers had run afoul of any other work in
> progress where the other branch _did_ have a blueprint, we could have
> just said "Sorry, you'll have to rebase after this other thing goes
> in, and coordinate better in the future," at which point they could
> have kept working to get their patch to land or walk away without
> getting it approved.  Reviews are open so people working on branches
> that have blueprints can complain if a "rogue" branch gets proposed
> that would interfere with their plans.
> 
> I really feel like we're making a problem where none exists.  You can
> certainly craft a scenario where a lack of coordination causes a
> problem in a branch like this, but we don't have actual evidence it
> will happen.  If it does, we can just push back against the proposer
> to fix things.  Whats the problem with that?
> 
> -todd[1]
> 
> On Mon, Mar 28, 2011 at 1:53 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On Mon, Mar 28, 2011 at 1:38 PM, Justin Santa Barbara
>> <justin at fathomdb.com> wrote:
>>> No objection to a discussion during the summit, but I've been able to watch
>>> all of these branches and others evolve here:
>>>  https://code.launchpad.net/nova
>>> For example, when I wanted to add VNC support because my system wouldn't
>>> boot, it was easy for me to look at the vnc_console branch and get the
>>> libvirt XML magic from there.  If I was feeling brave, I could have grabbed
>>> the whole branch and merged it into my tree.  That feels _very_ open to me.
>> 
>> Rubbish. Open development means knowing the general directions and
>> specifications that people are working on by open discussions, open
>> blueprints/specs, and active communication between teams. I can go to
>> github and see how many people "forked this" (ugh.). That doesn't give
>> me any clue as to what people are attempting to do with the code in
>> the long term.
>> 
>> The problem we've been having revolves around the fact that we have
>> dozens of developers working on Nova, with no real guidance as to the
>> long-term direction of the project, and teams just doing whatever the
>> heck they want to, without ML discussion and blueprints, and then
>> expecting people to just merge branches a few days before feature
>> freeze.
>> 
>>> <jaypipes_troll> Just another benefit of bazaar being a centralized version
>>> control system, I guess </jaypipes_troll>
>> 
>> I don't know what the heck you are talking about.
>> 
>> -jay
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp