On Thu, 2009-05-14 at 20:20 -0700, David Brownell wrote: > On Thursday 14 May 2009, Zach Welch wrote: > > One point to make here is the conflicting desires of a "release manager" > > and "developers". At their extremes, the former would have us making > > stable releases every night, while the later would have us working madly > > on the trunk (and to heck with releases). > > Not that much. Any good developer is going to be very supportive > of (release) milestones; and too-frequent releases don't help > anyone, even an RM. Releases are largely ways to get everyone > into positive feedback loops, and keep them there. Without them, > it's just goal-less hackery.
True, but I did qualify my statement with "at their extremes." The real world is not binary, but I love to talk about it like it is. Your point about "positive feedback loops" is excellent though, and I agree that is another benefit that answers the "why". :) > All that's needed is to pick a target release period: just how > frequently should there be new OpenOCD releases? > > First one was late January. Late June should be doable for the > next one. That's five months ... maybe that's too long. I think it is. At the current pace of development, I think that we should be shooting at every couple of months. However, a temporal goal is only one way to view release schedules. I read somewhere (not that long ago) that one should choose release schedules based on features _or_ based on dates. So, the community could choose to finish features X, Y, and Z _or_ to finish by the Nth of some Month. We should _not_ attempt to set both goals -- no wiggle room will be left to push back the schedule or drop features. I think this is excellent advice and a policy that I want applied to my projects. A shade of gray might be considered as well, but I like the clarity implied by these black-and-white schemes. They objectify the process, whereas a mix would require some degree of subjective decision making. We are human: nothing will be completely objective. Still, I think clear policies would help avoid most bruised egos and hurt feelings. In the end, the RM should be the single person to make these decisions. > > We must find a happy medium > > so both processes can flow smoothly. Mostly, this means empowering that > > individual to lead the decision to release and having the rest of the > > maintainers comply with the restrictions thusly imposed (merge windows). > > I'd have said there needs to be enough of a team commitment > that supporting the RM's decision making for each release is > a complete no-brainer; and enough of a team that one person > doesn't need to be RM all the time. Again, my binary reductionism gets me into trouble. Clearly, there should be give and take on both parts, but the central idea here is one of responsibilities: only the RM needs to be responsible for leading the process forward. That responsibility should be fairly minimal, because -- yes -- the other developers should be supportive of the process. This gets us back to the point of positive feedback loops. If we manage the release process correctly, then it will make the developers want to help make more releases. The RM should have a very easy job to do. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
