trac milestone

[Volker Braun]

Per the recent discussion I will not batch modify the milestone on the currently-open tickets.

[kcrisman]

Per the recent discussion I will not batch modify the milestone on the currently-open tickets.

Thank you.

Did we end up discovering what the secret sauce was for doing it on the database directly?  

More toward resolving this in a happier way, perhaps we should have the default for new tickets changed as well - I couldn't find a place to do that but am not too familiar with the admin interface, e.g. http://trac.sagemath.org/admin/ticket/milestones had nothing relevant.

[Volker Braun]

I did make a new milestone for 6.5 and made that the default.

[kcrisman]

I did make a new milestone for 6.5 and made that the default.

On Friday, November 14, 2014 5:05:30 PM UTC, kcrisman wrote:

More toward resolving this in a happier way, perhaps we should have the default for new tickets changed as well - I couldn't find a place to do that but am not too familiar with the admin interface, e.g. http://trac.sagemath.org/admin/ticket/milestones had nothing relevant.

I meant that some people suggested making no milestone the default.  I'm not sure what I think about that, I can see pros and cons. 

[Clemens Heuberger]

Am 2014-11-14 um 18:05 schrieb kcrisman:
>
> Per the recent discussion I will not batch modify the milestone on the
> currently-open tickets.
>
>
> Thank you.
>
> Did we end up discovering what the secret sauce was for doing it on the database
> directly?

If the database schema at http://trac.sagemath.org/wiki/DBSchema is accurate,

update ticket set milestone='sage-6.5' where milestone='sage-6.4' and status !=
'closed';

could be the trick.

Before trying that, I'd like to see what

select id, summary, milestone, status from ticket where milestone='sage-6.4'
and status != 'closed'

actually gives.

However, the above lines are hardly secret sauce ...

Regards, CH

[Jori Mantysalo]

But how should milestones be used? For bugs it seems easy to have next
release as default milestone, but about enhancements? I have put them on
whislist, if I think that I might do it myself, but don't know when.

--
Jori Mäntysalo

[martin....@gmx.net]

On Friday, November 14, 2014 at 7:25:09 PM UTC+1, kcrisman wrote:

I meant that some people suggested making no milestone the default.  I'm not sure what I think about that, I can see pros and cons. 

I'd vote for no milestone by default. As it currently is, I feel like my tickets opened for 6.4 (#16222 for example) were simply forgotten. I now know they are not, or at least not neccessarily, but it still feels that way. With "no milestone" the default, we could make semantic use of milestones, as outlined below. As they are now, they carry little to no information, at least as far as I can see. So here is how I'd use milestones:

• Blockers must have a milestone, and will block that release
• Things which are fairly important and/or fairly simple could be scheduled for the next release as well
• We might want to set a milestone when requesting review, when granting review, or at the latest when closing
  
• When we set a milestone, we could use the next release for easy changes which could make it into any beta at any time
  
• In contrast, major changes which might affect a lot of code should probably be scheduled for an early beta of some release, so they might be deliberately aimed at a milestone one release after the next one (e.g. my work for #11542 feels a bit like this)
  

[kcrisman]

These seem like helpful suggestions.