openstack team mailing list archive

[Todd Willey <todd@xxxxxxxxxxxx>]

On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
> Todd Willey wrote:
>> Not all features take a long time to plan and implement.  Some are
>> quite tiny.  Some are conceived and implemented near the end of the
>> release cycle.  Size, scope, and timing can change how valuable a
>> blueprint is as the odds that a patch requires coordination tends
>> toward zero.  The information that you point to (what their new shiny
>> thing is, how it works, and how to test it) certainly remains valuable
>> regardless of size, scope an timing, but that information can also
>> live in a merge proposal.
>
> We have always had some tolerance so far for small unplanned features
> that land in time. I still think those should have linked blueprints
> (since I still fail to see the cost associated), even if that means
> creating them retroactively.

Then it is reasonable to ask people in a merge proposal discussion to
file a blueprint, and give them guidance on how to do so.

>
> What I want to avoid is large unplanned features, which hurt project
> external visibility and tend to generate duplicate work and last-minute
> objections. I also want to avoid unplanned features landing *outside the
> merge window*. This whole thread started because a set of unplanned
> features were proposed after FeatureFreeze and required exceptions.

At FFE time why don't we branch and change so proposals default to the
next release then?  I understand that you don't want people focusing
on features instead of bugs, but I doubt that situation will arise.
It could, however, save us from some late proposals.  I don't want to
have to do more work on my end in tracking branches and remembering
dates, I'd rather just push my stuff to launchpad and have it show up
in the list of pending proposals.

>
> I think we outlined the cost of not filing blueprints... Could you
> outline the cost of filing them ?

They aren't standard practice in the open source world.  My main
concern is the amount of indignation that was exhibited for a practice
that is the standard operating procedure in most open source projects.
If we keep that attitude we're going to drive away developers, and I
feel like we should be doing all we can to be welcoming.

We're apache licensed, people don't have to share their work.  They
can either close up or fork.  The best way to avoid that and encourage
them to be open is to take contributions in a way that feels natural
for developers who are making the changes and are willing to share
their work.  if we need more information let's ask nicely, not turn a
merge proposal into a protest.

Most importantly, I think this:
http://wiki.openstack.org/SpecsSubmissionDeadline sets the wrong
precedent.  I understand that it is great for large features, things
that require changes to every hypervisor layer, or some other change
that has ripple effects.  We need to deal with the case that people
have new ideas all the time, not just every three months.  If someone
conceives of a new feature after this freeze, they shouldn't have to
wait nearly six months to see it released if it is small, doesn't
break anything, and doesn't duplicate work or invalidate ideas others
are working on.  You can check those criteria during a merge review.

I'm not in the mindset that every patch is going to be self-contained.
 It makes sense to occasionally postpone things until they can be part
of the next cycle.  I want there to be a practice of cheerfully
reviewing changes to see if they can land or not, instead of trying to
default everything to invalid.  We have reviews for a reason, lets let
them work the way they should.  You've done a great job of determining
which things were valid for FFE, and comments on the proposals have
discussed why it was so late in coming.  It seems like our process is
already working, so I feel like this whole thread is mostly pointless,
other than as a catalyst for people to express their various attitudes
toward different aspects of our processes and how they are used.

>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>