Release notes for future versions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Release notes for future versions

Mark Côté-2
dkl has been chugging away at the release notes for 5.0rc1.  I would
like to remind all developers, reviewers, and approvers that any
significant change should be tagged with the "relnote" keyword.  Trying
to figure out what should go into the release notes is very tedious when
the keyword is regularly neglected.

Second, I'd like to propose an amendment to this process: rather than
waiting until the first release candidate, any change that requires a
relnote should have the relnote added before the bug is resolved.  This
will vastly speed up the release process, since the release manager
won't have to read through bug comments to get the gist of changes.  dkl
suggests using the User Story field, which makes sense to me, since the
release note is essentially a very brief summary of the change.

Finally, if someone is looking for a way to contribute to Bugzilla, I'm
sure dkl would appreciate help with future releases!  It's a perfect
opportunity to help out if you don't feel comfortable coding on Bugzilla.

Mark

--
Mark Côté
Assistant Project Lead, Bugzilla
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Gervase Markham
Hi,

On 15/01/15 18:26, Mark Côté wrote:
> dkl has been chugging away at the release notes for 5.0rc1.  I would
> like to remind all developers, reviewers, and approvers that any
> significant change should be tagged with the "relnote" keyword.  Trying
> to figure out what should go into the release notes is very tedious when
> the keyword is regularly neglected.
>
> Second, I'd like to propose an amendment to this process: rather than

Can I counter-propose a different amendment?

We should keep the release notes in the docs/ folder as reST, and
require the patch to contain a patch to the release notes if it's
release-noteworthy. This means all the work is done at the time of patch
submission. The release manager has the option of trimming down the list
(and so we can err on the side of inclusion when considering whether
bugs are note-worthy), but won't need to go and seek information to add
it. So it would make their job easier.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Frédéric Buclin
Le 16. 01. 15 11:49, Gervase Markham a écrit :
> We should keep the release notes in the docs/ folder as reST, and

I disagree. This requires to compile the docs to read them. I think it's
much easier to simply have an HTML page as we do currently.


> require the patch to contain a patch to the release notes if it's
> release-noteworthy. This means all the work is done at the time of patch
> submission.

I disagree here too. It's not the job of the contributor to decide what
should be relnoted and what shouldn't. And even if we say this should be
relnoted, it's not his job to follow our guidelines to document new
features. Also, some features require several bugs to be fully
implemented. It's much easier to relnote relevant information once the
whole feature is implemented. And so it's easier to do this after all
the related bugs have been fixed. And it's already hard enough to find
contributors, so please don't ask them to do more.

I made another proposal on IRC yesterday. The idea is to still add the
'relnote' keyword as we always did, but we update release notes for each
development release instead of waiting for rc1. The bug list between two
consecutive dev releases is not that big. And we have a better idea of
what is important and what is pretty minor.


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Gervase Markham
In reply to this post by Gervase Markham
On 16/01/15 18:10, Frédéric Buclin wrote:
> I disagree. This requires to compile the docs to read them.

No, because there will be a copy on bugzilla.readthedocs.org.

>> require the patch to contain a patch to the release notes if it's
>> release-noteworthy. This means all the work is done at the time of patch
>> submission.
>
> I disagree here too. It's not the job of the contributor to decide what
> should be relnoted and what shouldn't.

Well, the contributor in collaboration with their reviewer.

Who adds the relnote keyword at the moment?

> I made another proposal on IRC yesterday. The idea is to still add the
> 'relnote' keyword as we always did, but we update release notes for each
> development release instead of waiting for rc1. The bug list between two
> consecutive dev releases is not that big. And we have a better idea of
> what is important and what is pretty minor.

I like that idea. :-) That may well help.

Gerv


-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Dave Lawrence
My proposal for discussion for an updated release notes process

1) When a bug is approved for inclusion in a release, the approver decides if a release note
is warranted and adds the relnote keyword to the keywords field of the bug (happens more or less now).

2) The approver also sets the target milestone appropriately so the release manager will know which
release notes should contain the summary.

3) Once we are ready for a development snapshot to be made for the next release, the release
manager looks for all bugs targeted for that release and has the relnote keyword set. Also  a top level release
notes bug is created for tracking and to also contain the high level key points for the release which will be
reviewed separately.

4) The release manager goes through the bug list and adds a brief summary of the bug fix to the "User Story"
field for each bug.

5) The release manager sets the relnote? flag for each with the approver as the requestee. Would someone else
be better for the requestee?

6) The requestee reviews the release note summary and sets the relnote+ flag or relnote- if something needs to be changed.

7) Once all release notes are reviewed, the release manager will use a script to pull the high level summaries, each of the
individual summaries per bug and using a template, create a new release notes page to be shipped with the final release.
The individual summaries can be separated by topic or component.

The goal of all of this is to figure out how to:

1) start this whole process as early as possible so that it can be revised  over time and be ready when release time comes around.

2) And to be able to script this so that the release process can systematically pull everything using a bug query and construct
the release notes page easily.

Thoughts?
dkl

On 01/21/2015 09:35 AM, Gervase Markham wrote:

> On 16/01/15 18:10, Frédéric Buclin wrote:
>> I disagree. This requires to compile the docs to read them.
> No, because there will be a copy on bugzilla.readthedocs.org.
>
>>> require the patch to contain a patch to the release notes if it's
>>> release-noteworthy. This means all the work is done at the time of patch
>>> submission.
>> I disagree here too. It's not the job of the contributor to decide what
>> should be relnoted and what shouldn't.
> Well, the contributor in collaboration with their reviewer.
>
> Who adds the relnote keyword at the moment?
>
>> I made another proposal on IRC yesterday. The idea is to still add the
>> 'relnote' keyword as we always did, but we update release notes for each
>> development release instead of waiting for rc1. The bug list between two
>> consecutive dev releases is not that big. And we have a better idea of
>> what is important and what is pretty minor.
> I like that idea. :-) That may well help.
>
> Gerv
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dkl@...>

--
David Lawrence
[hidden email]
bugzilla.mozilla.org

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Frédéric Buclin
Le 21. 01. 15 16:25, David Lawrence a écrit :
> 4) The release manager goes through the bug list and adds a brief
> summary of the bug fix to the "User Story" field for each bug.

In that case, instead of doing this + setting the relnote flag +
writing/running a script, it would be much easier to update
page/release-notes.html.tmpl directly and attach a patch for review.


LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes for future versions

Dave Lawrence
Well, my thinking was when we do a single patch with all relnotes combines in a
single file initially, it is up to the single reviewer to go back through all the bugs
and verify that the relnote is correct for each. By having each relnote attached
to the inidividul bugs and then asking for review, the approver would only need
to look at that specific relnote. The final reviewer for the top level release notes
bug would therefore only need to look at the high level key points. My proposal
spreads the work load and also the approvers normally have a good understanding
of what is being solved by each bug report.

dkl

On 01/21/2015 07:37 PM, Frédéric Buclin wrote:

> Le 21. 01. 15 16:25, David Lawrence a écrit :
>> 4) The release manager goes through the bug list and adds a brief
>> summary of the bug fix to the "User Story" field for each bug.
> In that case, instead of doing this + setting the relnote flag +
> writing/running a script, it would be much easier to update
> page/release-notes.html.tmpl directly and attach a patch for review.
>
>
> LpSolit
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dkl@...>

--
David Lawrence
[hidden email]
bugzilla.mozilla.org

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>