| 1 |
On 10/19/2015 07:08 PM, Rich Freeman wrote: |
| 2 |
> On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius <axs@g.o> wrote: |
| 3 |
>> |
| 4 |
>> Ahh, so what you're referring to here is stabilization of multiple |
| 5 |
>> unrelated packages in a single commit.. ok.. i'm not so |
| 6 |
>> comfortable with that idea.. |
| 7 |
> |
| 8 |
> Nor am I. A commit should be a set of related changes. Stabilizing |
| 9 |
> all of KDE-n in one commit makes a lot of sense. Stabilizing 5 random |
| 10 |
> packages in one commit doesn't make sense. By all means push them all |
| 11 |
> at once, but don't commit them all at once. It isn't like we have to |
| 12 |
> pay for each commit. |
| 13 |
> |
| 14 |
|
| 15 |
We already know that. But if e.g. ago runs his scripts at 00:00 with |
| 16 |
~300 packages stabilized, the history (without git command line) on |
| 17 |
github/gitweb will be fun to read (and people DO that). |
| 18 |
|
| 19 |
The argument is that those are related changes to the subsystem "stable |
| 20 |
arch" (and affect not random ebuild details, but stable arch only, as in |
| 21 |
KEYWORDS). Ofc, people can still create atomic commits if the |
| 22 |
stabilization is security related. |
Archives