On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius <a...@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
