On Tue, 2006-05-02 at 12:35 -0700, Matt Zimmerman wrote: > On Tue, May 02, 2006 at 07:55:53PM +0100, Matthew East wrote: > > On Tue, 2006-05-02 at 11:43 -0700, Matt Zimmerman wrote: > > > [...] > > So, that handles the "changing" part. Not the "seeing" bit though. There > > is literally no field which tells the normal user what release has been > > targetted, AFAICS. > > Yes, that seems like a Malone bug.
The bug is that Malone doesn't show the field if a milestone isn't already set. I think this bug is meant to capture that: http://launchpad.net/bugs/40025 But I'm asking the reporter to confirm. > > > My understanding is that in the future, Malone will incorporate this > > > workflow: anyone can "nominate" a bug for a milestone, but an authority > > > must > > > confirm it. > > > > Sounds quite cool, if the authorities have time to deal with all the > > requests. > > The alternatives would seem to be: > > - Keep the current situation (only privileged users can set milestones) > > - Anyone can set a milestone (this was a nightmare because I had to go > around and clean up where people had set milestones incorrectly) > > - Create a separate privilege level specifically for milestones, add anyone > to it who might have a legitimate reason to set a milestone on any > package, keep them informed about the relevant policies for milestone > settings, etc. > > - Allow anyone to propose a milestone target, but require confirmation from > a privileged user > > The last of these seems superior to any of the others, regardless of how > much time the drivers have. It certainly requires the least of my time. I see another possibility: * Allow a configuration option to define a release management team. Then two options (more thought needed on the wording, just putting forth the idea): (*) Allow only members of the release management team to target bugs ( ) Allow any logged-in user to target a bug, subject to approval from the release management team Without making this configurable, I think it will be extremely difficult for Malone to scale from small, release early, release often, anyone-can-have-a-commit-bit projects all the way to large projects, which rely on heavyweight processes and workflows to coordinate hundreds of contributors or more. Brad -- launchpad-users mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/launchpad-users
