Add 2.29.1 as bugzilla "Target Milestone"?

[Carlos O'Donell]

On 09/14/2017 06:46 AM, Nick Clifton wrote:
> Hi Carlos, 
>>> Does binutils have any process here for who is supposed to add
>>> the milestone before the release goes out?
>>
>> Not as far as I know.  
> 
> Actually I just found this note in Tristan's how-to-perform-a-binutils-release
> checklist:
> 
>   Rename the current HEAD version entry in Bugzilla, and create a new
>   one.  E.g. rename "2.16 (HEAD)" to 2.16, and create "2.17 (HEAD)".  Go
>   to "Edit products" from the bottom toolbar, click on "binutils", then
>   on "Edit versions".  If you don't have permissions to do this,
>   either ask Daniel Berlin to fix your account or ask Daniel Jacobowitz
>   to do it.
> 
> So presumably wither Tristan or Daniel or Daniel is the person to thank.

That's not the same thing.

Each product, e.g. "binutils", in bugzilla has:

* components

* versions

* milestones

This particular question is about "milestones", but your note are about
"versions."

The "versions" field is important in that it allows *users* to submit
bugs against that particular version.

While as Hans-Peter notes you need "miltestones" to track *when* the bug
was fixed. We do the same thing in glibc.

As an example in glibc we have an automatic script that runs at release
end to create part of our release announcement and it trawls the bugzilla
looking for bugs that are closed and with the current releases milestone
and considers those newly fixed bugs for the release. They get an entry
generated for the release announcement i.e. [NNN] <Description>
e.g. [21622] libc: [tile] missing SA_* for POSIX.1:2008
This is all done with a script that talks bugzilla xmlrpc to sourceware.
We could clone this for binutils release announcements?

This is slightly off topic.

I think the question is back to: You don't have a process for adding new
milestones. Should you?

-- 
Cheers,
Carlos.