El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió: > On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pa...@gentoo.org> wrote: > > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: > >> On Thu, 21 Jun 2012 08:08:55 +0200 > >> Pacho Ramos <pa...@gentoo.org> wrote: > >> > Also, if I remember correctly, Tommy asked for this some months ago, > >> > you asked for what he sent some days ago and now you require more and > >> > more work to delay things to be implemented. > >> > >> I still haven't seen a clear description of exactly what should be > >> changed and why. I've also not seen a description of exactly what > >> problem is being solved, nor a discussion of the relative merits of > >> implementing a solution to whatever that problem is. All I've seen is a > >> mess of code that "gets it working" in Portage (which isn't the same as > >> "implements it for Portage") and a big wall of text that contains lots > >> that no-one needs to know and little of what's important. This needs to > >> go through the GLEP process, and it needs a PMS diff. > >> > >> In case you're not aware, the first time Gentoo did multilib, it was > >> done as a series of random changes to Portage that no-one really > >> thought through or understood. As you can see, that didn't work... > >> > > > > Then, looks clear to me that the way to get things approved in newer > > EAPIs is not clear enough as looks like a lot of devs (like me) don't > > know them (for example, when things to be added to EAPI need also a GLEP > > and a PMS diff, also the needing to get an implementation for any > > package manager). Is this documented in some place? If not, I think it > > should be documented and, of course, it should be done by PMS team if > > possible as they clearly know what they expect to get for approval if > > needed since, I discussed some days ago, council will simply accept some > > specific features to be included in next eapi once they are accepted by > > PMS team. That way, we could save a lot of time, know what steps are > > pending, try to ask for help for some specific steps and, finally, get > > it discussed in PMS people providing all what is needed. > > > > > >> > I also don't understand why Gentoo is forced to stick with old ways > >> > of doing things until new EAPI is approved > >> > >> That's not what's going on here. The issue is that there might be one > >> person who understands what "the new way of doing things", but he > >> hasn't told us what he thinks that is. Once we get a proper > >> explanation, getting an EAPI out doesn't take long. > >> > > > > But you must confess that old problems like multilib support, force > > package rebuilding or optional dep support are still pending while still > > needing and, the problem with the way things are discussed now is that > > some day anybody arises the problem again, other one demands more things > > to be provided, a discussion starts, the problem gets stalled... one > > year later the same problem arises again. There is clearly a lack of > > information to the rest of developers about how to propose anything to > > get accepted for next EAPI. > > I'm not following you here. > > 1) Usually features need a reference implementation. > 2) For portage, there are like 3-5 people who know portage well enough > to write that for you. > 3) You generally have to convince them to do it before you can move forward. > 4) Most features never even get a reference implementation. > > There is this vague idea that you can just propose something; get > consensus on the ML, everyone goes to implement it, and then it works > just as designed. That is usually called the 'waterfall' model and its > really hard to do correctly. > > What I imagine the process is: > > 1) Submit an idea to the ML; you just need feedback (not consensus, > which is likely impossible for non-trivial ideas.) > 1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly > required. > 2) Take feedback from step one and make an initial implementation. You > will likely find some assumptions in your 'design' from step one were > wrong, as well as other implementation issues (UI, performance, etc.) > 3) Modify your idea to address the problems in 2. > 4) Modify your implementation to address the problems in 2. > 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems. > 6) Submit a diff to PMS outlining how the package manager behavior is > changed by your feature. This generally needs to be specific enough so > that other package manager authors can implement the feature. > 7) Submit a devmanual patch telling users how to use the feature. > > Most people fail at step two; usually because they try to get > 'consensus' at step one, which is stupid and a waste of time. There > are a few hundred people on this list; we will never all agree, on > basically anything. So take the feedback people give you and do > something with it. >
OK thanks :) What I was trying to show is that this process is not clear enough, you even need to say that you "imagine" that it's the process, and looks pretty reasonable but, if that process is kept undocumented, we are doomed to revive the problem again and again About trying to get a consensus, I think it's wanted to not waste time reimplementing things a lot of times. Think for example in ABI_SLOT stuff, we reached some small consensus about, at least, use SLOT/SUBSLOT approach, that will probably save a bit of time to people making the implementation as he won't need to firstly implemente ABI_SLOT way, later get it rejected again and, finally, re-implement it with SLOT/SUBSLOT. The idea is to try to help people doing the huge work of getting the implementation to save as much time as possible. But I also understand your point as looks like usually it's really difficult to reach consensus :/ > > > >> The main problem here isn't even EAPI related. Ebuild developers don't > >> even know what they'll be expected, required or able to do for multilib. > >> > >> > while Exherbo is free to implement and use things like that special > >> > way of handling DEPENDENCIES without waiting for any EAPI to be > >> > accepted... > >> > >> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't > >> have it because Portage couldn't implement it. Now it doesn't have it > >> because it's too controversial to get it approved. > > > > It was only a example, but thanks for the info :) > > > >> Exherbo does have it > >> because it was carefully discussed, compared to alternatives, planned > >> out, tested, accepted by the expendable figurehead, and then rolled out. > >> > >> > or maybe I am wrong and people is able to use any PM manager > >> > compliant with EAPI on exherbo without issues? > >> > >> If anyone ever manages to come up with another package mangler that can > >> get close to implementing what Exherbo needs, then sure. > >> > > > > Then, you accept exherbo is not forced to *only* follow EAPI while you > > force Gentoo and portage to only support features approved in an EAPI? > > > > Portage can use whatever EAPIs portage wishes to publish (Zac has > published portage specific EAPIs in the past.) Generally in gentoo-x86 > you can only use council approved EAPIs; so if portage was to publish > something like 'portage-1' you would have to get council approval to > use it in Gentoo-x86. It seems like a reasonable request to me, why > not talk to them about it. Didn't know that it was allowed. Thanks a lot for the information :) > > The reason exherbo can 'do whatever they want' is because the project > is marketed that way. Seriously, go to Exherbo.org and look at the > 'Why' section. Reason 2 is 'we need to break stuff whenever we feel it > is beneficial.' Gentoo is not marketed that way to our users. We > 'generally promise' backwards compat for 6-12 months. > > If we randomly added stuff to portage without being bound by EAPI then > we end up breaking stuff unintentionally all the time when rolling out > features. > > -A > > Well, I was more thinking on having our own "EAPIs", but I see I didn't explain it properly in previous mail, sorry
signature.asc
Description: This is a digitally signed message part
