El jue, 18-10-2012 a las 09:36 -0400, Rich Freeman escribió: > On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill <[email protected]> wrote: > > On Wed, 17 Oct 2012 15:00:12 -0400 > > Rich Freeman <[email protected]> wrote: > >> I think the whole developers-can't-handle-47-EAPIs thing is a red > >> herring. The fact that there are packages written in Erlang in the > >> tree doesn't cause me any issues even though I haven't had to do any > >> work in Erlang. If I ever wanted to maintain such a package then I'd > >> take the time to learn it as needed. Likewise, if I wanted to > >> maintain a package that used EAPI joe and I really prefer to work in > >> EAPI fred, then I'd revise it at my next convenience. > > > > Well, it's not just about ebuilds you maintain. Think about something > > like the gcc-porting trackers where you have to touch a lot of ebuilds > > across the tree. You really do have to have a working knowledge of the > > differences between EAPIs to do so. My browser bookmark to the EAPI > > cheatsheet is one of the more frequently used as it is. > > Can't you just ask the maintainers to fix their ebuilds? And if they > don't respond or at least cooperate, well, then treeclean them. I > don't think that library maintainers should have to bend over > backwards to fix reverse dependencies, within reason. If out of the > whole tree two packages are blocking an upgrade, give a deadline or > treeclean them. If we have 47 bazillion packages that don't work on > the newer lib, then slot it and bug upstream. > > I do agree that trying to auto-mangle ebuilds from 47 different EAPIs > doesn't make sense. Just assign a bug to the maintainer saying "do > this to your ebuild, or get it on EAPI foo so that I can fix it, by > <date> or it is gone." The deadline is important - I've seen a > pattern on -dev where bugs linger without deadlines for months, and > then a deadline of two days is imposed, and then a big flame war > breaks out. Just set a deadline up-front and make it reasonable. > > Rich > >
I didn't think eapi4 features were still "unfamiliar" to so many people... let's say, what about deprecating eapi1, 2 and 0 for newer ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for newer ebuilds (eapi3 changes look to be minor when compared with eapi2) ?
signature.asc
Description: This is a digitally signed message part
