| 1 |
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge <peter@×××××.se> wrote: |
| 2 |
> hasufell wrote: |
| 3 |
>> > A version bump plus cleaning up older ebuilds will be considered |
| 4 |
>> > one logical change, I suppose? |
| 5 |
>> |
| 6 |
>> I'd consider it two logical changes |
| 7 |
> .. |
| 8 |
>> But I don't have a strong opinion on that |
| 9 |
> |
| 10 |
> I do - I think this is really important. Having clean history makes a |
| 11 |
> huge difference for anyone who wants to use that history. |
| 12 |
> |
| 13 |
> One argument against those clean professional development practices |
| 14 |
> that comes up over and over is that it takes more time, ("mimimi I |
| 15 |
> don't have time to be part of any solution") which is sometimes true |
| 16 |
> - but since git makes committing so easy usually the difference |
| 17 |
> isn't very big, and the payoff when you benefit in the future is |
| 18 |
> quite significant. |
| 19 |
|
| 20 |
++ |
| 21 |
|
| 22 |
A git commit is virtually instantaneous since it is entirely local. |
| 23 |
|
| 24 |
> |
| 25 |
> |
| 26 |
>> Do you think this should be added explicitly? |
| 27 |
> |
| 28 |
> I think keeping rules vague is probably the only thing that somehow |
| 29 |
> scales. |
| 30 |
> |
| 31 |
|
| 32 |
++ |
| 33 |
|
| 34 |
I think we should start out with decent guidelines, and then move on from there. |
| 35 |
|
| 36 |
Nobody is going to die if some of our commits are sloppy out of the |
| 37 |
gate. One of our biggest strengths as a distro is the autonomy we |
| 38 |
give individual developers, and guidelines are usually more productive |
| 39 |
than rules. |
| 40 |
|
| 41 |
If they get abused, we can deal with it. |
| 42 |
|
| 43 |
-- |
| 44 |
Rich |
Archives