Proposals for commit log policy

[Patrick Venture]

On Tue, Aug 28, 2018 at 8:44 AM Andrew Geissler <geissonator at gmail.com> wrote:
>
> 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.

Downstream we do manual bumps for our repo forks and it is a manual
process and we're looking at ways to automate it and provide the
information.  Right now, the bump, albeit manual ends up looking like:

"""
.... phosphor-pid-control: bump srcrev

Bump includes:
* 2524323 test: dbus: dbusactiveread
* 0ef1faf test: dbus: passive read interface
* 0df7c0f dbus: transition to interface for testing

Change-Id:
Signed-Off-By:
"""

So it's certainly not as informative as Joel's kernel ones in some
ways.  Our approach just lists, in order, the patches.  But like I
said, we're trying to automate that process to just include the
minimal details.

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