1 |
Marius Mauch kirjoitti: |
2 |
> On Tue, 14 Oct 2008 10:59:39 +0200 |
3 |
> Jose Luis Rivero <yoswink@g.o> wrote: |
4 |
> |
5 |
>> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: |
6 |
>>> On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: |
7 |
>>>> There are some others sceneries but are not so common as the one |
8 |
>>>> presented could be. Any decent solution for this case? |
9 |
>>> There are only a few obvious ones, you'll have to pick which one |
10 |
>>> you like best. Most of the other options basically duplicate these |
11 |
>>> in some way or add more work to them for negligible gain: |
12 |
>>> |
13 |
>>> - Backport the ebuild from EAPI=2 to EAPI=0 |
14 |
>> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is |
15 |
>> going to happen when we release new and more feature rich EAPIs), and |
16 |
>> changes usually come with bugs. The ebuild is committed directly to |
17 |
>> stable implies bugs in stable, which for me is a no-go. |
18 |
> |
19 |
> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to |
20 |
> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many |
21 |
> cases) you could just reuse the foo-1 ebuild for foo-3. |
22 |
> |
23 |
> If there are major differences between foo-1 and foo-2 not related to |
24 |
> the EAPI change then the maintainer probably didn't want foo-2 to |
25 |
> become stable anytime soon, so it's at least questionable if foo-3 |
26 |
> should go straight to stable in the first place. |
27 |
> |
28 |
> And adding a new version directly to stable always comes with a risk, |
29 |
> you can't eliminate that completely. It's all about risk assessment, |
30 |
> and how much work you're willing to do or time you want to spend to |
31 |
> minimize the risk. |
32 |
> |
33 |
|
34 |
There's no need to commit straight to stable. Just make two different |
35 |
new revisions for each EAPI. Then the arch teams can test it like usual. |
36 |
|
37 |
Regards, |
38 |
Petteri |