On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
