Open Stack

On Mon, Mar 28, 2011 at 2:54 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On Mon, Mar 28, 2011 at 2:32 PM, Todd Willey <todd at ansolabs.com> 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.

I'd say that forking is a form of consumption, and not contribution.
I'd really like to make contribution as easy as possible to avoid
forking.

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

Can't you know what it fixes or adds by reading the merge proposal?  I
think it is reasonable to make merge proposals be detailed enough to
answer any questions that a blueprint would have answered.  Thats what
the "Needs Information" status is for.  The whole MP process is for
debating and discussing.  I actually prefer the linear discussion of a
MP, as opposed to a BP, so I can see what changes based on feedback,
and see new revisions that actually fix what is wrong.  Compare that
to a BP where you only have a text blob that is maintained by the
proposer, isn't generally updated after questions are raised on
mailing list or summit, and isn't displayed inline with the code.

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

I agree with John's post that the PTL should solve some of the
problems we have with a unified vision.  I don't see developers
working on their own interests being at odds with the direction of the
project as a whole.  Of course if someone clearly doesn't care about
the direction of the stack as a whole, we would do right to reject
their patches that would stray from our vision.  I think that isn't
likely though, as our developers are our users.  Service providers and
users have their own needs to tend to as well as the overall scope of
the project.  We're always going to be getting MPs for things that
aren't in the scope of our release vision, but we should accept them
as long as they don't go against that vision or other goals of the
project.

Clearly blueprints are about process and not about code.  Merge
proposals are a hybrid of code and process.  Blueprints are about
managing expectations, whereas merge proposals are about managing
code.  I think if you are working on a self-contained change you don't
need to manage the expectations of people working on other parts of
the system because you're not going to interfere, and their
expectations about how they should write code can go unchanged.  You
do, however, need to have a process required to get your changes
accepted into the code, and need to outline your reasoning and
implementation goals.

>
>> 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 tend to have the problem of figuring out review priority of branches
even with the inclusion of blueprints.  I think launchpad doesn't have
a good interface for integrating the blueprint hierarchy with merge
proposals aside from prerequisite branches which are manual,
non-obvious from the merge proposal list view, and are easy to
overlook.  Hopefully core review days and PTL will mitigate this.  I
don't really see how a MP with a blueprint that isn't linked to any
others somehow conveys any more information than a MP.  I think there
are ways to make progress in determining review order aside from
requiring blueprints.  In the meantime, just move them to the bottom
of your priority.  Nobody will know but you.

As for the "why" question, I don't see why a MP can't convey that
information as effectively as a blueprint.  They are both blobs of
text, only at least with a MP you can point to actual code to answer
questions.  Also with a MP you can see the series of question-response
to get more context.

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

I read the initial problem as "some things don't have blueprints and
are developed in isolation" which I didn't see as a problem.  Now i
see it as:
* coherency of vision
* review priority
* determining "why" you built something
* branches dropping right before freeze (I don't think this is solvable)

These are problems I can get behind solving.  It still remains to be
seen if requiring blueprints is the best practice, but at least we
have goal to work towards.

>
> -jay
>

-todd[1]