Proposals for commit log policy

[Andrew Geissler]

On Tue, Aug 28, 2018 at 5:30 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
>
> > On Aug 22, 2018, at 7:58 PM, Joel Stanley <joel at jms.id.au> wrote:
> >
> > On Tue, 21 Aug 2018 at 22:01, Alexander Amelkin <a.amelkin at yadro.com> wrote:
> >
> >> =================
> >> some-package: bump version 62286ef3 to 4fa63380
> >>
> >> Author Name (2):
> >>  commit 1 synopsis
> >>  another commit synopsis
> >>
> >> Another Author (3):
> >>  great commit
> >>  yet another great commit
> >>  fix previous not-so-great commit
> >>
> >> Change-Id: some-long-gerrit-hash
> >> Signed-off-by: The Version Bumper <bumper at nowhere.net>
> >> =================
> >
> >> What do you think? Is this feasible? Any other ideas how we could simplify creating release notes suitable for end users?
> >
> > I think this is a great suggestion. I would also like to see this happen.
> >
> > Having the maintainers or authors of the packages submit their bumps
> > would ensure this does not become a burden for the central repository
> > maintainer.
> >
> > An advantage of the maintainers of individual packages submitting
> > their changes is they know the best timing for integrating their
> > changes, and know what relevant details should be added to the bump
> > commit message.
>
> I also would like to see this.  To be clear I mean the commit msg text above,
> and not a ‘Impact’ token.
>
> The autobump script was deployed at a time in the project when _every_ repository
> had the same maintainer, so it made some sense back then.  Today we have a much
> more distributed set of maintainers.
>
> I’ve actually disabled the cron job that runs the script, because it needed
> some rework to handle the new openbmc/openbmc repository layout.
>
> I plan on simply _not_ turning it back on, and let maintainers do their own
> bumps like Joel has been doing for the kernel moving forward (Thanks Joel).
> Unless there are major objections.

I object!  At least 90% of the auto bumps today go through without
issue.  This keeps our openbmc/openbmc master consistently up to date
which I think is a big benefit to our community.  We're able to
quickly find regressions with our automated tests which are constantly
running against the new content coming in. I feel like we're adding
more work with minimal benefit here.

To summarize:

- Adds a layer of manual work that has minimal benefits
- Prevents us getting small continuous changes, and instead will
encourage larger big chunks that are tougher to isolate fails on
- Even if individual repo owners are forced to do their own bumps, I
don't think many will address what started this thread, summaries of
the changes and impacts of each commit.

On the other side of thing I realize this is how yocto does it (manual
bumps) and it does allow more individual control for repo maintainers.
I just don't think at this point in our project, it's worth it.

Andrew

>
> thx - brad
>
> >
> > Cheers,
> >
> > Joel