Re: [gentoo-dev] stabilization commits and atomicity

[Rich Freeman <rich0@gentoo.org>]

On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> Ahh, so what you're referring to here is stabilization of multiple
> unrelated packages in a single commit..  ok..  i'm not so
> comfortable with that idea..

Nor am I.  A commit should be a set of related changes.  Stabilizing
all of KDE-n in one commit makes a lot of sense.  Stabilizing 5 random
packages in one commit doesn't make sense.  By all means push them all
at once, but don't commit them all at once.  It isn't like we have to
pay for each commit.

I also don't have a problem with fixing multiple bugs in one commit.
In an ideal world you'd do that on a branch and then do a merge, and I
don't have a problem with that either, but I get that we tend to not
work that way.  If you want every commit to stand on its own and
you're porting to a new EAPI and fixing 3 bugs at the same time, I
don't expect maintainers to rewrite their bugs into the new code to
port it to the new EAPI, then fix each bug in turn.

> BUT, nothing stopped us from doing this
> with CVS (although the mapping of commit between CVS and GIT aren't
> exactly 1:1), so i guess it's fine..?

In cvs all commits were at the file level, even if you happened to
create more than one as a single operation.  If you did one commit
that touched 100 ebuilds, you were actually doing 100 commits, and
there is nothing that really ties those 100 commits together and by
the time it gets to rsync you might only get 50 of them if the timing
is right.

So, this actually is a new problem, or rather benefit.

>
> What about simply keeping things as they are but not strictly
> enforcing them when they are used in a manner like this for special
> cases, such as ago's stabilizations or other security@ or arch team
> keyword-related commits?
>

I don't think we're strictly enforcing anything now but I could be
wrong.  I think we should have guidelines that recommend best
practices and try to stick to them.  If there is a really good reason
to do things differently, that is why we call them "guidelines."

-- 
Rich