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

[Ulrich Mueller]

>>>>> On Mon, 22 Sep 2014, hasufell  wrote:

> Ulrich Mueller:
>> | • 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?

It is a very common example that should be mentioned.

>> | • 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?

Everything else, like abbreviating PN, or moving it to third or later
line, doesn't seem reasonable. So, I'd go for exceptions to the 75
char rule.

>> | • 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.

Right.

> 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?

Sounds good. Just say that the summary should be prepended by an
indicator what part of the tree is (mainly) affected, followed by some
examples that need not cover all corner cases.

>> 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.

Yes, I meant adding a warning, to make devs aware that there may be a
problem. A not quite perfect commit message is no real breakage, so it
doesn't merit a fatal error.

Ulrich