Re: release process

["Sergey Udaltsov" <sergey udaltsov gmail com>]

So, how would you propose to automate that process?

Regarding your reasons:
1. Sometimes one visible change consists of several commits. Things
like build process fixes, small code reorganization etc would not be
visible in these files at all
2. There is README file - it could contains details about the process.
If some newbie introduces the changes, and they are not mentioned in
the release notes - I do not see it as a deadly problem. Frankly, I do
not see the need in double-checking
3. Well, if we could formalize the way Commit messages are written, we
could create a script which would prepend NEWS file automatically.
That is a valid solution too. Could we have short guidelines (in
README file perhaps)?

Sergey

On Dec 22, 2007 12:26 PM, Jens Granseuer <jensgr gmx net> wrote:
> Sergey Udaltsov wrote:
> > What I'd propose is having two files: NEWS.since_last_stable and
> > NEWS.since_last. The maintainers of the submodules would put a list of
> > significant (user-visible?) changes in these files (it is not
> > necessarily to get to the level of every individual bug). That would
> > make release process much easier.
>
> I'd like to avoid this extra step, mainly for 3 reasons:
>
> 1) it's one extra step for each commit (more or less).
> 2) we sometimes have external committers who cannot be expected to
>     know about some internal g-c-c policy, so the release builder
>     would have to double-check anyway.
> 3) if extracting the important changes from the ChangeLogs doesn't
>     work, that means the commit messages (or ChangeLog entries, but
>     ideally, they should be the same anyway) aren't good enough. I'd
>     rather distribute an occasional kick in the backside to the
>     authors of sub-par ChangeLog entries than complicate the daily
>     routine. It's not like we release once a week.
>
> Jens
>