Re: Lost changelogs

Am 02.05.2014 19:28, schrieb ida277:
> Eric Steele wrote
>> We tend to not have up to date changelog entries for older branches in 
>> master.
> 
> Which certainly wouldn't be much of a problem for versions that are not
> supported anymore, but as it happened with p.a.portlets there were bugfixes
> lost, which concerned all branches. And we do want support all of them
> still, non?
> 
> Eric Steele wrote
>>  I do try to keep those updated across branches, but with 200+ 
>> packages, it's a nightmare.
> 
> Oh no, I didn't mean to critize you by any means, that would never come up
> to my mind, quite the contrary I am very happy Plone has such cool-blooded
> (in terms of staying calm, even if the server burns), very responsible
> release-managers doing an awesome job, imho.

Working on the release docs with Eric lately
(https://github.com/plone/buildout.coredev/blob/5.0/docs/release.rst)
made me realize how much work it is for Eric to make releases, and how
much we all have to thank him for doing this work over the years.

Unfortunately reviewing and adding changelog entries is one of the
things that we can't fully automate. Though, I guess we should think
about ways how we can shift the workload for this more towards the
community.

Eric does a great job and I would really like to free him from the
boring and repetitive tasks of the release process, so he can focus on
more important things. This is something the testing/release team is
already working on and we are always looking for people that help us
with that.

> I just wanted to emphasize the idea of pull-request-reviewers taking more
> care of these things and if such a concept exists already, so my quest is
> actually how it is decided who is granted to merge pull-requests, or can
> just any core-committer do that on any package (meaning the convention, not
> the actual repo-permissions) ?

Any core committer can merge a pull request. I'm not aware of any
conventions.

I guess we could (and maybe should) use pull requests a lot more.
Though, I think the first step towards a solution would be to define and
document which kind of commits should go into the changelog (features,
bugfixes, translation fixes, test fixes?, fixing typos?, everything
except release related commits?) and how we handle changelogs for
multiple branches.

Once we have defined our "best practices", we can think about ways to
enforce them (automated checks/jenkins/per-commit hooks/pull
requests/reviews/etc.).

Cheers,
Timo

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs