1 |
On Tue, Oct 14, 2008 at 06:17:12PM +0200, Marius Mauch wrote: |
2 |
> On Tue, 14 Oct 2008 10:59:39 +0200 |
3 |
> Jose Luis Rivero <yoswink@g.o> wrote: |
4 |
> > |
5 |
> > EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is |
6 |
> > going to happen when we release new and more feature rich EAPIs), and |
7 |
> > changes usually come with bugs. The ebuild is committed directly to |
8 |
> > stable implies bugs in stable, which for me is a no-go. |
9 |
> |
10 |
> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to |
11 |
> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many |
12 |
> cases) you could just reuse the foo-1 ebuild for foo-3. |
13 |
> |
14 |
> If there are major differences between foo-1 and foo-2 not related to |
15 |
> the EAPI change then the maintainer probably didn't want foo-2 to |
16 |
> become stable anytime soon, so it's at least questionable if foo-3 |
17 |
> should go straight to stable in the first place. |
18 |
|
19 |
I was talking about this case, were foo-2 is in testing and is not ready |
20 |
for stable. It's not questionable to go directly to stable if security is |
21 |
involved in the process. |
22 |
|
23 |
> And adding a new version directly to stable always comes with a risk, |
24 |
> you can't eliminate that completely. It's all about risk assessment, |
25 |
> and how much work you're willing to do or time you want to spend to |
26 |
> minimize the risk. |
27 |
|
28 |
Agree. The question bringing here is: how can we minimize the risk if |
29 |
this situation appear, where we have an EAPI change between ebuilds in |
30 |
stable and testing branch and EAPI in testing can only be managed by |
31 |
testing PMs. |
32 |
|
33 |
> In the end at least one of the above solutions should work in |
34 |
> almost every case. It might sometimes cause a bit more work than a bump |
35 |
> that doesn't involve any EAPI changes, but that's life. |
36 |
|
37 |
Well, when I think about having to revert eapi changes or having to |
38 |
make own backports and apply these solutions directly to stable because |
39 |
we are using some features not supported by stable PMs, I have doubts |
40 |
if it wouldn't be better to avoid these situations and wait for the PMs |
41 |
to be stable. |
42 |
|
43 |
> If you have a real case where both suggested solutions aren't |
44 |
> realistic I'd like to hear about it, otherwise I think we're wasting |
45 |
> time making up solutions for a non-existant problem |
46 |
|
47 |
It's not about realistic, just about how risky the solutions could be to |
48 |
be in our stable branch. Perhaps I'm being very pessimistic. Leave the |
49 |
question here and we will see what happen in the future. |
50 |
We'll back to this if needed. |
51 |
|
52 |
Thanks. |
53 |
|
54 |
-- |
55 |
Jose Luis Rivero <yoswink@g.o> |
56 |
Gentoo/Doc Gentoo/Alpha |