Author: intrigeri Date: To: Public mailing list about the Tails project Subject: Re: [Tails-project] writing the release notes for 1.3
Hi,
The proposal on #8689 adds a requirement not only for a changes file,
but also for a release notes snippet. Let me elaborate on the vision
I'm putting behind it.
The initial idea was: before a branch is proposed for merging, the
developer who has been working on it reaches out to doc writers to get
the draft end-user doc and release notes snippet reviewed, and
possibly improved. I believe that for a great part of the major
changes that are worth documenting in the release notes, this
communication already has to happen for the end-user doc polishing
anyway. So it adds a little bit overhead, but not that much.
Now, I can see that this would add more work for doc writers, and
could block features from landing into the testing branch. Given how
you (sajolida) currently 1. are practically the only person who has
the commit-bit for non-trivial changes to the doc, and 2. already have
a hard time dealing with all the doc things you feel you have to
review/improve before they get merged — perhaps it's not the best
idea ever.
So, instead, perhaps we can make it so a *draft* release notes snippet
is mandatory for any branch carrying changes that might be worth
mentioning in the release notes. It's left at the discretion of the
reviewer to ack/nack whether a given branch can freely skip this
requirement. This draft release notes snippet could also be a good
place for developers to dump all the info they think you might need to
write a good piece of text about their shiny new feature.
And then, instead of having a week for making the release notes as
good as you would like (before the RC and the actual release), you or
anyone else interested can incrementally work on it during the entire
release cycle.
Even better: this does *not* conflict with the proposal of giving more
exposure to the release notes improvement effort: the draft release
notes, once automatically assembled from the snippet at RC time, can
be published on a blueprint as you suggested, etc.
So it seems to me that this would lighten the RM workload, improve our
time-to-release, and allow doc writers to spread their work on the
release notes over the course of the release cycle. Catchy, uh? :)
sajolida wrote (21 Feb 2015 17:07:01 GMT) : > I'm also wondering whether we should point to tickets from the release
> notes. Most of those tickets are quite pointless to users who want to
> know what's new. Only some of them include relevant discussions on why
> we did this or that, but still... People who want to dive into the gory
> details can find them in the changelog already, no?