Please, test and mark app-admin/eselect stable on x86, amd64, ppc and sparc. It's needed for stabilization of dev-lang/php. Reproducible: Always Steps to Reproduce:
CCing arches.
Jakub, please do NOT take it upon yourself to request archs stabilize a package without even talking to us first. Luckily no archs have done so yet. It is in my opinion (and the other eselect devs) that what is currently in portage is not sufficient for stable. We want to do another release for possible stable, however we're not going to rush it into stable. Unfortunately, you guys will have to hold off using eselect for the time being.
(In reply to comment #2) > Jakub, please do NOT take it upon yourself to request archs stabilize a package > without even talking to us first. Luckily no archs have done so yet. Uhm? I've done it b/c PHP herd (CHTEKK and Stuart) asked me to do so... > It is in my opinion (and the other eselect devs) that what is currently in > portage is not sufficient for stable. We want to do another release for > possible stable, however we're not going to rush it into stable. Unfortunately, > you guys will have to hold off using eselect for the time being. This thing clearly seems to miss a clear concept. Then again, php herd can reinvent the wheel and write a simple bash script to create 6 symlinks, that's all we need. However, I suspect that you can expect the same approach when asking php herd to switch to eselect later; like - WONTFIX.
Will the PHP herd get upset if the next eselect release suddenly breaks their module? Until eselect 1.0 is out, there's no guaranteed stable API between releases, so this may well happen.
We know that the API may well change, and we're not going to be upset if it does, just notify us of the change before you then stable the new&changed eselect version, so we can accordingly prepare a new&updated version of the eselect-php modules. :) Best regards, CHTEKK.
(In reply to comment #3) > (In reply to comment #2) > > Jakub, please do NOT take it upon yourself to request archs stabilize a package > > without even talking to us first. Luckily no archs have done so yet. > > Uhm? I've done it b/c PHP herd (CHTEKK and Stuart) asked me to do so... That's no excuse for not checking with the maintainers first. > > > It is in my opinion (and the other eselect devs) that what is currently in > > portage is not sufficient for stable. We want to do another release for > > possible stable, however we're not going to rush it into stable. Unfortunately, > > you guys will have to hold off using eselect for the time being. > > This thing clearly seems to miss a clear concept. Then again, php herd can > reinvent the wheel and write a simple bash script to create 6 symlinks, that's > all we need. However, I suspect that you can expect the same approach when > asking php herd to switch to eselect later; like - WONTFIX. > If that's what they want to do, then that's their prerogative. I told Stuart when he first mentioned he needed a stable eselect that there were no guarantees that it'd be stable by then and that we would not rush it to stable for that sole reason.
(In reply to comment #6) > That's no excuse for not checking with the maintainers first. I did not mean to apologize, so I hopefully don't need an excuse. But I'm definitely sorry for filing this bug and wasting my time. I've probably missed something, now that it's required to check w/ maintainers to be allowed to assign a keywording bug to maintainers and respective ARCHs. > > > It is in my opinion (and the other eselect devs) that what is currently in > > > portage is not sufficient for stable. We want to do another release for > > > possible stable, however we're not going to rush it into stable. Last release is 2 1/2 months old, maybe this whole thing would even get somewhere if you actually released something for people to test. > If that's what they want to do, then that's their prerogative. I told Stuart > when he first mentioned he needed a stable eselect that there were no > guarantees that it'd be stable by then and that we would not rush it to stable > for that sole reason. Thanks for cooperation, closing this bug. Next time, I'd really appreciate if eselect team at least would not confuse people by providing mistaken information (like CHTEKK has been told yesterday to file a bug to get this stable).
> (like CHTEKK has been told yesterday to file a bug to get this stable). Just a little clarification: I did check with the eselect maintainers, yesterday I asked in #gentoo-eselect and I was told that if I wanted it stabled, I should ask arch teams, I was never told there is no plan to mark it stable or anything contrary to mark it stable... So I asked the arch-teams (x86 specifically) and there I was told that there is nothing against stabling eselect, to please file a bug for it, and that was then done by Jakub on my request, and for doing that I thank him. :) So now I'm not sure, will this be stabled or not? It seems to me ciaranm is not against it, and I repeat, if the API changes for the next eselect releases, we know and we will adapt to it and change our eselect-php modules, so that's no problem for us, but this way in the meantime we and others have a stable, useable eselect imo. Best regards, CHTEKK.
I'm not necessarily against it if the arch teams are happy stabling something that might undergo massive API unannounced changes before the 1.0 release...
(In reply to comment #7) > (In reply to comment #6) > > That's no excuse for not checking with the maintainers first. > > I did not mean to apologize, so I hopefully don't need an excuse. But I'm > definitely sorry for filing this bug and wasting my time. I've probably missed > something, now that it's required to check w/ maintainers to be allowed to > assign a keywording bug to maintainers and respective ARCHs. It's called common courtesy. > > > > > It is in my opinion (and the other eselect devs) that what is currently in > > > > portage is not sufficient for stable. We want to do another release for > > > > possible stable, however we're not going to rush it into stable. > > Last release is 2 1/2 months old, maybe this whole thing would even get > somewhere if you actually released something for people to test. Oh so you're volunteering to help us? Listen, it's really just Danny and I who do most of the work; neither of us have time to work on eselect as our main project. If you're not going to help, then don't bitch. > > > If that's what they want to do, then that's their prerogative. I told Stuart > > when he first mentioned he needed a stable eselect that there were no > > guarantees that it'd be stable by then and that we would not rush it to stable > > for that sole reason. > > Thanks for cooperation, closing this bug. Next time, I'd really appreciate if > eselect team at least would not confuse people by providing mistaken information > (like CHTEKK has been told yesterday to file a bug to get this stable). > Unfortunately, ciaranm is not on the eselect team, so dont blame us. Bottom line, I dont have a problem with a stable eselect. I have a problem with a stable eselect-0.9.6.
> Unfortunately, ciaranm is not on the eselect team, so dont blame us. http://www.gentoo.org/proj/en/eselect/index.xml says otherwise, so if possible update that page to not confuse people, thanks. > Bottom line, I dont have a problem with a stable eselect. I have a problem with > a stable eselect-0.9.6. Ok, then, since PHP Herd wants to stable the new dev-lang/php, we'll probably program our mini-alternative that works on those 6 symlinks (little BASh script will do) and that's it. Best regards, CHTEKK.
