[Openstack] Feature Freeze status
jaypipes at gmail.com
Thu Mar 31 22:28:59 UTC 2011
Well said. I don't disagree with any of your points or suggestions
below. Looking forward to a productive chat about it at the summit in
a few weeks.
On Thu, Mar 31, 2011 at 6:09 PM, Vishvananda Ishaya
<vishvananda at gmail.com> wrote:
> There has been a lot of great discussion and airing-out around blueprint and
> merge process. I think some good points have been raised on all sides. I'd
> like to weigh in with some perspective-changing suggestions about how we can
> manage specs and blueprints that I think everyone will be happy with.
> Basically we are all in the process of learning how to manage a large
> open-source project with 100+ developers, and I think managing a group that
> large by throwing everyone into a pool and hoping that all of the developers
> can collaborate effectively is a bit optimistic. The suggestions that I
> outline below are not radical changes from how we are currently doing
> things, but hopefully it will help clarify the process.
> People have extolled the value of blueprints many times, and I agree that
> they are very valuable. But I think blueprints are much more valuable from
> a project management perspective than they are from an 'in-the-weeds' coding
> I would suggest that blueprints are used to give a broad overview of an
> intended feature and enough technical information for the PTL and other
> teams to ensure that work isn't being duplicated. Since we all work in
> teams, I think it is reasonable to expect every team to have a contact
> person that is responsible for ensuring that the team's blueprints are
> up-to-date with what they are actually working on. Internal to the team
> this can be managed however they see fit. It can be offloaded to individual
> developers or handled by a project manager, etc.
> If we can all strive to follow this limited use of blueprints, I think it
> gives us the advantages that they provide for project management without
> putting too much strain on the developers.
> Detailed specs beyond a brief technical overview should not be required in
> all cases. It is strongly recommended (but not required) for a team to make
> available any internal specifications that they are using. For small
> features, a simple link to a public branch is enough.
> Detailed Specs should be required in the following cases:
> * A large feature that touches a lot of the code
> * Code that will need multiple merge proposals
> * Features that are being worked on by multiple teams
> * A feature that is blocking features by other teams.
> I think we could
> Teams should be encouraged to keep their branches in the public as work goes
> on. This allows curious community members to drill down into the current
> development and see what is going on. This is especially important for
> teams using agile development.
> Merges should be evaluated on merit. If we get a large feature without an
> associated blueprint/spec, we can help educate the developer on the
> blueprint / spec process, but i don't think we should block merging if the
> feature is well designed and tested. Obviously if the feature interferes
> with other blueprints in the pipeline, we can block it.
> In conclusion, I strongly agree with soren's comment that the core
> developers should be following the suggested process, and I will mea culpa
> in my own avoidance of blueprints. I think a lot of the issues the
> developers have had are due to a feeling that it is a) complicated and b)
> not valuable. Hopefully with the understanding of the value that has been
> provided in this thread and the clarification and suggestions I've provided,
> we can all improve our teamwork.
> Please let me know if I've missed anything.
> 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
More information about the Openstack