Lack of release targeting in Malone (was Re: Bugging questions)

[Brad Bollenbach]

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