openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Mon, Mar 28, 2011 at 2:32 PM, Todd Willey <todd@xxxxxxxxxxxx> 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.

It's not about letting people contribute. It's an open source project.
Anyone can contribute. Anyone can work on a fork of their
PetProjectStack.

But when it comes to merge proposal time, and especially the backlog
that always shows up around Feature Freeze, I couldn't care less about
PetProjectStack unless it has a blueprint or bug tied to it that lets
me know the patch fixes something or adds something to the project
that has been debated and discussed.

> This thread started specifically in response to a few branches that
> didn't hinder anyone else's work, but also didn't have blueprints.

Not true. There were only a few branches that didn't have bugs or
blueprints assigned to them. Those branches are what Thierry and
myself were talking about.

> 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.

IMHO, this doesn't work for projects with dozens of developers and
many teams all working towards a unified goal (you know, that whole
"this release is about X" thing?). It works spectacularly well for
projects with developers all working on their own forks of stuff that
want to do their own hacks but don't care about the direction of the
project as a whole. In other words, the blueprint/discussion process
is designed to bring unity to the project's direction and goals. it's
about *process*, not code.

> 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.

We complain because "rogue" branches interfere with the process of
trying to figure out what branches are to be reviewed in which order
and priority. They add to the chaos when I can't answer the "why"
question that Justin alluded to earlier.

> 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?

If the problem didn't exist, I wouldn't bring it up.

-jay