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