1 |
On Mon, Mar 3, 2014 at 3:13 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> Dnia 2014-03-03, o godz. 15:05:12 |
3 |
> Ian Stakenvicius <axs@g.o> napisał(a): |
4 |
> |
5 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
6 |
>> Hash: SHA256 |
7 |
>> |
8 |
>> On 03/03/14 02:43 PM, Michał Górny wrote: |
9 |
>> > Dnia 2014-03-03, o godz. 12:14:13 Ulrich Mueller <ulm@g.o> |
10 |
>> > napisał(a): |
11 |
>> > |
12 |
>> >> Can we clarify that the ban includes updating the EAPI in |
13 |
>> >> existing ebuilds? |
14 |
>> > |
15 |
>> > So how we are supposed to handle updating rev-deps to use proper |
16 |
>> > slot? Convert ancient versions to a new EAPI or just drop them |
17 |
>> > completely? |
18 |
>> > |
19 |
>> |
20 |
>> That's up to you, as maintainer, isn't it? |
21 |
> |
22 |
> If I am fixing a few dozen ebuilds due to change in dependency package, |
23 |
> I'm not the maintainer. |
24 |
|
25 |
I think we do need to be careful about not creating barriers to |
26 |
maintenance like this. If people are given the choice of doing a lot |
27 |
of work to make a small improvement vs not doing an improvement at |
28 |
all, they'll often pick the latter. |
29 |
|
30 |
We definitely want to phase out the old EAPIs, but changes to existing |
31 |
ebuilds shouldn't require bringing them fully up-to-date. It should |
32 |
be done if it makes sense, however (at the discretion of the person |
33 |
doing the work). |
34 |
|
35 |
Rich |