Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

[hasufell]

Ulrich Mueller:
>>>>>> On Sun, 21 Sep 2014, hasufell  wrote:
>
>> https://wiki.gentoo.org/wiki/Gentoo_git_workflow
>
>> But so far, not many people have been particularly interested in the
>> details of these things. I'm also not sure if the ML is the right
>> way to figure out these details.
>
> Where else should this be discussed then? Discussion page of the wiki
> page?
>
> | commit policy
> | • atomic commits (one logical change)
>
> A version bump plus cleaning up older ebuilds will be considered one
> logical change, I suppose?
>

I'd consider it two logical changes (e.g. imagine a user complaining
about ebuild removal... you cannot easily revert it if it's not a
separate commit). But I don't have a strong opinion on that and I'm not
sure if we can enforce commit rules in such fine-grained details, can we?

Do you think this should be added explicitly?

> | • commits may span across multiple ebuilds/directories if it's one
> |   logical change
> | • every commit on the left-most line of the history (that is, all
> |   the commits following the first parent of each commit) must be gpg
> |   signed by a gentoo dev
> | • repoman must be run from all related ebuild directories (or
> |   related category directories or top-level directory) on the tip of
> |   the local master branch (as in: right before you push and also
> |   after resolving push-conflicts)
>
> Have you tested if running repoman in the top-level directory is
> realistic as part of the workflow?
>

This is really just meant for stuff like mass commits, not regular
ebuild stuff.
Ask patrick, he's running repoman all the time, probably even top-level.

> | commit message format
> | • all lines max 70-75 chars
> | • first line brief explanation
> | • second line always empty
> | • optional detailed multiline explanation must start at the third
> |   line
> | • for commits that affect only a single package, prepend
> |   "CATEGORY/PN: " to the first line
>
> In some cases of long package names, this may be in conflict with the
> first item. "dev-python/rax-default-network-flags-python-novaclient-ext: "
> as a prefix doesn't leave much space for an explanation. ;)
>

I'd say that's rare enough to warrant exceptions in that case. Or are
you suggesting to drop CATEGORY/PN completely? I mean... it's not
strictly necessary, since you can just look at the files that have been
touched and run git log on an ebuild directory, but I think it will
still make using the history easier, especially since mass-commits will
not have CATEGORY/PN and can very easily be identified. It's also common
practice in various overlays.

Do you want me to add this exceptional case as a valid reason to have
more than 75 chars in the first line?

> | • for commits that affect only a single package, but also modify
> |   eclasses/profiles/licenses as part of a logical change, also
> |   prepend "CATEGORY/PN: " to the first line
> | • for commits that affect only the profile directory, prepend
> |   "profiles: " to the first line
> | • for commits that affect only the eclass directory, prepend
> |   "ECLASSNAME.eclass: " to the first line
>
> Maybe just "eclass: " would be slightly more systematic? (Because for
> all others it is a directory.)
>

Not sure either. This is again just a convenience thing for history
readability, not strictly necessary information. But I'd personally go
for full eclass name.

> | • for commits that affect only licenses directory, prepend
> |   "licenses: " to the first line
>
> Same for commits that affect licenses and profiles?
>

You are probably referring to license_groups. I'd say it matters more
what the intention is and not so much what directories in particular
were touched. If you want to add a new license and have to edit
profiles/license_groups, I'd still just prepend "licenses: ".

Maybe I should add this as a general idea to the commit guideline. I
think that's better than specing the whole through which will probably
just confuse people, no?

> | • for commits that affect only metadata directory, prepend
> |   "metadata: " to the first line
> | • mass commits that affect a whole category (or large parts of it)
> |   may prepend "CATEGORY: " to the first line
>
> All in all, this looks sane to me. Is it planned to enforce this
> policy by repoman?
>

Good question. I'm not sure if it's a good idea though. It might get in
our way for corner cases and whatnot. Maybe as a polite warning it would
be ok.


Also, if you have ideas of wording something better in particular,
please share or just edit the wiki.