Manual work is required to change 'fix committed' bugs to 'fix released' when a milestone is released.

When you are proud of a release that fixes 100 bugs, you realize how painful it is to change them manually...

Agreed. However, I'd suggest one minor modification to this idea: That it be a project-specific setting.

Some projects may wish to track this manually because it fits in with a model of verifying each bug, whilst others will do that verification beforehand, which they may use a tag for.

In the options for a project, it should ask "Do you want to automatically close bugs whose fixes have been committed when they are released in a milestone?" or something along those lines, so that it's perfectly clear that the settings changes how Launchpad will work with bugs.

@Lionel -- As an aside, you do not have to close them manually. You can use Launchpad's email interface to modify bugs en masse, so when you make a release, you can do something like this:

  for bug in 1 2 3 4 5 6 7 8 9 10; do printf " bug $i\nstatus fixreleased\n\n"; done

In your favorite shell, and paste the results in an email to be sent to <email address hidden>, which will process the bulk request. See https://help.launchpad.net/Bugs/EmailInterface#bug for more info on that.

I want to do this. I use a Launchapd API script to do this. I did not have the hours necessary to close the 82 bugs my team closed last release. The fix-release status change will be project specific. Downstreams may need to integrate those changes.

In Michael B. Trausch's workaround, something is quite unclear: where does the list of bug numbers come from? It's not actually going to be "1 2 3 4 5 6 7 8 9 10".

Do you have to go to the bugs page and manually type in all the bug numbers, or is there a script of some sort that can get a list of all the fixed bugs targeted to a milestone?

Fixed in db-devel r8923.

This feature was backed out because of timeouts--sending email notifications happens in the request. It is trivial to re-enable this feature after the email notification issue is solved. There is no easy solution, but it appears the most ideal way to solve this is to move the rules that create the messages to the individual subscribers out of proc. This is not easy, but it will also address many performance issues in bugs--it is worth estimating before considering a simple process that updates bug statuses for recent releases.

On Sat, 2010-01-30 at 18:27 +0000, Curtis Hovey wrote:
> This feature was backed out because of timeouts--sending email
> notifications happens in the request. It is trivial to re-enable this
> feature after the email notification issue is solved. There is no easy
> solution, but it appears the most ideal way to solve this is to move the
> rules that create the messages to the individual subscribers out of
> proc. This is not easy, but it will also address many performance issues
> in bugs--it is worth estimating before considering a simple process that
> updates bug statuses for recent releases.

Considering there are several API scripts floating around to do this...
it would seem better to handle it in Launchpad than having everyone
causing this problem on their own :)

  --Ted

One nice thing to consider here is that we can use the event of a milestone being released to send a single email for all the bugs, rather than one per bug. That might permit Ubuntu to use fix committed and not overwhelm folk with email at release time.

In a way, this is a workaround for denormalization in the model: the whole milestone is either released or not, but every bug needs to be manually updated. Rather than fixing this directly, we could fix bug 163694 by having just one 'fixed' state, which would make this unnecessary.

It wouldn't make it unnecessary - folk that want to see 'development
done but not shipped' would then likely want In Progress to convert to
Fix Released upon milestones being released.

On 11 April 2011 09:38, Robert Collins <email address hidden> wrote:
> It wouldn't make it unnecessary - folk that want to see 'development
> done but not shipped' would then likely want In Progress to convert to
> Fix Released upon milestones being released.

There is definitely something there, but I don't know if it should be
automatic conversion from inprogress to fixreleased. If I have
something inprogress targeted at a milestone that released, it seems
likely that it either missed the milestone or is now fixed.

On Sun, 2011-04-10 at 23:38 +0000, Robert Collins wrote:
> It wouldn't make it unnecessary - folk that want to see 'development
> done but not shipped' would then likely want In Progress to convert to
> Fix Released upon milestones being released.

I think that this distinction is important. For instance, we can have
something Fix Committed in the project but Fix Released in distro.

Also, as another data point, I've patched lp-project-upload to do this
behavior for me -- so at least as far as I'm concerned -- there is an
adequate work around.

Really bad thing and stupid .

Please enhance importance onto "high"

Thanks

Andreas