Re: [gentoo-dev] Flourish Conference Reminder
On 04/04/07, Seemant Kulleen [EMAIL PROTECTED] wrote: Please except my apologies I don't know about excepting them. I might accept them though. :) -- -Charlie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tue, 03 Apr 2007 10:10:30 -0700 antarus [EMAIL PROTECTED] wrote: I think there is a difference. Take the issue with the ubuntu installer that left the root password in a log in /var. Who was responsible? Ubuntu. Why? Because it's their installer, their project. And who would be responsible if someone put a back door in apt? Ubuntu or Debian? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Flourish Conference Reminder
or accepting them I suppose makes more sense. Alright, last email from me that's flourish .. I'll let you guys get back to what you do best. Sorry again, I'll go through the proper channels from now on. -- Samir On 4/5/07, Charlie Shepherd [EMAIL PROTECTED] wrote: On 04/04/07, Seemant Kulleen [EMAIL PROTECTED] wrote: Please except my apologies I don't know about excepting them. I might accept them though. :) -- -Charlie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Wed, 4 Apr 2007 01:51:56 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: - PMS: - status update from spb - moving it to Gentoo svn - schedule for getting remaining issues settled Same question as last time this came up: Can you name any other projects where the Council has become involved in scheduling issues? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 05 Apr 2007 09:28:17 +0100: On Wed, 4 Apr 2007 01:51:56 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: - PMS: - status update from spb - moving it to Gentoo svn - schedule for getting remaining issues settled Same question as last time this came up: Can you name any other projects where the Council has become involved in scheduling issues? If I may... take this as at least certain members of the council agreeing with you that certain package management issues are holding up Gentoo (note, I did NOT say portage, per se, but package management issues in general, I'm deliberately leaving it at that general level). Logically, an agreement on some sort of current base package spec, PMS, is, I believe most will agree, the next big step in resolving that issue. Viewed from that angle, the repeated emphasis on a time-line of sorts (regardless of the word used to communicate the idea), let's say for argument's sake (since I don't know others, but am not at a level to know for sure) uniquely, only underscores the importance the council (or certain members thereof, anyway) is now attaching to the issue. Or are you now arguing that movement on package management is /not/ holding back Gentoo, now? BTW, from my read of the portage-dev list, there are several things there on hold for EAPI-1, as well, and while a full definition of EAPI-0 isn't absolutely necessary before moving on EAPI-1, if it's possible time-wise, it's the most logical and convenient way, so that too is holding on the definition of EAPI-0, meaning all three projects appear to be awaiting it in some form or another, thus making it even /more/ critical timewise, regardless of how things turn out package-manager-wise down the pike. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On 4/5/07, Alexandre Buisse [EMAIL PROTECTED] wrote: Well, the thing is, vote happens only once a year, and quite a lot of things can be done during that time. I just think that not having any rule at all concerning limitations to the council is tying our hands in our back. If the council never messes up, then this rule won't ever be used, and if they do, we'll be happy to have this handy rather than having to argue for ages and being told you elected us, so shut up and if you don't agree, don't vote for us next time (which is an answer I actually got several times). Why not simply allow trustees to veto a council decision ? This does not give trustees enough power to be a second council, but would permit them to stop something that they believe will damage Gentoo. This is very little red tape IMHO. If it's only stupid and not harmful it will be solved naturally with the current structure by waiting for the next elections (either at the end of the term or because enough council members resigned due to the situation). Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Wed, 4 Apr 2007 15:17:18 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: Alexandre Buisse wrote: [Wed Apr 04 2007, 02:36:43PM CDT] I won't take this to the council myself, but I think this should be discussed at the very least: we need a way to limit the council power, since it seems there is nothing to this effect in the metastructure glep. For what it's worth, I deliberately wrote the GLEP that way. The truth of the matter is that the Council has only whatever power the devs permit, so adding additional restrictions seems like a really bad idea to me. Right. Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Flourish Conference Reminder
On Thu, 2007-04-05 at 09:16 +0100, Charlie Shepherd wrote: On 04/04/07, Seemant Kulleen [EMAIL PROTECTED] wrote: Please except my apologies I don't know about excepting them. I might accept them though. :) Nice catch. My language skills are degrading rapidly :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, Apr 05, 2007 at 09:26:41AM +0100, Ciaran McCreesh wrote: Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp04r7RTHldf.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Wed, Apr 04, 2007 at 12:27:09PM -0400, Mike Frysinger wrote: sorry, due to the thread (things for Council to talk about), i thought the work you were talking about was stuff for the Council to discuss ... that seems to not be the case Ah, sorry about that. As you said, right now there is nothing on my mind that needs to be actually discussed by the council. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpCCFkeImvi3.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote: Why not simply allow trustees to veto a council decision ? This does not give trustees enough power to be a second council, but would permit them to stop something that they believe will damage Gentoo. This is very little red tape IMHO. I believe that the trustees do not necessarily have any jurisdiction over the council. They are concerned with legal type matters that affect the foundation, not with technical and political things within Gentoo itself. I could be wrong about this, but that's how I read it. Thanks, Seemant signature.asc Description: This is a digitally signed message part
[gentoo-dev] Switch to libchipcard3
Hi, I'm currently the maintainer of libchipcard. There are three slots of libchipcard in the tree at the moment. I think there's nothing in the tree any more that deps on 1, so that is about to be removed soon. Now, I wanted to ask if there are any issues that would prevent us from getting rid of libchipcard2 also. From what I know, the only stuff dep-ing on libchipcard is the aqbanking-stuff (and with that gnucash, qbankmanager and others). libchipcard3 contains some api-breakage, but that should be fixed by a simple revdep-rebuild. If there are no issues with it (especially gnucash-users, please test and report bugs, I don't use gnucash), I'd request stable-marking of libchipcard 3.0.2 soon and remove all 1+2-stuff. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] pgpdBpOHyiMSC.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Fri, 06 Apr 2007 00:09:12 Wernfried Haas wrote: On Thu, Apr 05, 2007 at 09:26:41AM +0100, Ciaran McCreesh wrote: Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. If Gentoo goes all political and ties itself up in hundreds of rules, regulations, and miles of the proverbial red tape it will cease to be effective, and become a fork target to be effectively taken over by somebody or other with superiour people and technical skills. Don't the names Debian, Shuttleworth, and Ubuntu ring bells? -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote: On 4/5/07, Alexandre Buisse [EMAIL PROTECTED] wrote: Well, the thing is, vote happens only once a year, and quite a lot of things can be done during that time. I just think that not having any rule at all concerning limitations to the council is tying our hands in our back. If the council never messes up, then this rule won't ever be used, and if they do, we'll be happy to have this handy rather than having to argue for ages and being told you elected us, so shut up and if you don't agree, don't vote for us next time (which is an answer I actually got several times). Why not simply allow trustees to veto a council decision ? This does not give trustees enough power to be a second council, but would permit them to stop something that they believe will damage Gentoo. Actually, while it isn't spelled out, this is likely the case, since the trustees (and the Foundation members, by extension) are the holders of the Gentoo name. The Foundation is what grants the Council its power by allowing Gentoo (Linux) to govern itself. Trust me, if the Council were doing something nasty and underhanded that would endanger Gentoo, the trustees would try to do *something* to prevent it. That being said, I don't think that anybody is out to try to harm Gentoo. We (the Council) understand that we cannot appease everybody all the time and don't make any apologies for not being able to do so. This is very little red tape IMHO. That being said, the Trustees really don't have jurisdiction over the Council's technical decisions or their decisions on how to actually run Gentoo. This is a power the trustees could have, but it isn't one they necessarily *do* have. I have no idea if they would even want it and my opinion doesn't matter a whole lot, since I would be in conflict of interest in pretty much any decision. If it's only stupid and not harmful it will be solved naturally with the current structure by waiting for the next elections (either at the end of the term or because enough council members resigned due to the situation). There's a huge difference between the Council doing something against Gentoo and the Council doing something certain people don't agree with. The former is completely intolerable while the latter is very likely to happen with any decision the Council makes. Some people will always spout off conspiracy theories and their opinions on how they think things should be, which is all fine and dandy except that it isn't how things *are* currently. If someone wants something changed, they can very well work to get it changed. Trying to force the Council to do something via underhanded tactics or baseless accusations doesn't do much. Getting the community together does. If the community decided that the Council is only allowed to hold meetings on Thursday when the moon is full, we'd abide by it. I just find this whole situation hysterical since you have so many people saying the Council needs to grow a pair and actually try to enact some good, and when we do, you hear a few vocal individuals running around screaming like we killed their kitten. So which is it? Would you rather have a strong Council that is capable of making decisions without having to worry about whether that decision is popular or not, or would you rather have a weak Council that cannot do anything without prior developer approval, completely castrating their abilities to enact change for fear of being removed from office? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 08:19 -0400, Seemant Kulleen wrote: On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote: Why not simply allow trustees to veto a council decision ? This does not give trustees enough power to be a second council, but would permit them to stop something that they believe will damage Gentoo. This is very little red tape IMHO. I believe that the trustees do not necessarily have any jurisdiction over the council. They are concerned with legal type matters that affect the foundation, not with technical and political things within Gentoo itself. I could be wrong about this, but that's how I read it. Correct. Currently, the Council (or anyone, really) would have to do something to endanger our copyrights, trademarks, or our legal standing for the trustees to do anything. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
On Thu, 5 Apr 2007 10:37:28 + (UTC) Duncan [EMAIL PROTECTED] wrote: Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 05 Apr 2007 09:28:17 +0100: On Wed, 4 Apr 2007 01:51:56 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: - PMS: - status update from spb - moving it to Gentoo svn - schedule for getting remaining issues settled Same question as last time this came up: Can you name any other projects where the Council has become involved in scheduling issues? If I may... take this as at least certain members of the council agreeing with you that certain package management issues are holding up Gentoo (note, I did NOT say portage, per se, but package management issues in general, I'm deliberately leaving it at that general level). snip Or are you now arguing that movement on package management is /not/ holding back Gentoo, now? I want a consistent answer, and to know why the Council considers PMS to be more important time-wise than, as far as I can see, any other project ever. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 5 Apr 2007 14:09:12 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: On Thu, Apr 05, 2007 at 09:26:41AM +0100, Ciaran McCreesh wrote: Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Which is all very well, but it's kind of hard to evaluate the effectiveness of Council members and the Council as a whole if they're doing things behind everyone's backs and making horrible threats to try to prevent people from publishing logs of their goings on... I mean, what're people supposed to think from the likes of these? Kugelfang there have been, at that time, 6 council members plus one non council members in that channel ... Kugelfang ciaranm: and that's all i'll say regarding that, until the rest allows me to speak about the contents of that meeting ... Kugelfang i really wish i could publish this thing and: wolf31o2|mobile we're entrusted by certain outside parties to not disclose things that are spoken to us in confidence tove wolf31o2|mobile: how are outside parties involved in our coc? i don't understand this. can you please elaborate on it? wolf31o2|mobile tove: no, I cannot elaborate, nor do I care to... just realize that Gentoo has responsibilities to outside parties that provide services and goods to Gentoo... we have relationships that we would like to maintain... and that's about all I can say (or have time to say... I am at work) I mean, when it's reached the point where certain Council members are threatening to pull each others' access if anyone goes public with whatever it was that was discussed, *something* has to be done... The details can remain private if necessary, but publishing a brief summary along the lines of we discussed x and y and decided z *has* to be less harmful than the current mess where people are deleting their work and considering resignation because of whatever it is the Council are up to... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Ciaran McCreesh wrote: Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? This is getting silly; a secret meeting which is officially announced? You cannot stop people from talking amongst themselves. It doesn't work and it's counter-productive. Consulting a PR in recent times was a smart move, and not one that can be done in the public glare, akin to a discussion with an attorney. I for one am glad the Council did it, and gladder still that it was in confidence. I have no interest in knowing all the ins and outs, so long as there are people there who _will_ sort out issues which have to be dealt with. In my estimation, there are a good set of dedicated individuals who truly care about gentoo. I might not agree with everything they do or say; so what? They provide the best distro out there, and contrary to your allegations, for a user it's better and more stable than ever. Comparing binary package managers to a source-based one is facile imo. RH or Ubuntu can do what they want: the competition for gentoo is basically sourcemage. There are loads of gentoo users who have never had to reinstall in several years of use. That simply doesn't happen with the `competition' which you cite. It seems like gentoo is going from a cottage-industry to a medium-size organisation. People can work for the same organisation, sharing the same general ideals, but with completely different approaches; they just work on different teams. imo that's a good thing, so long as all acknowledge that there is a _collective_ goal, which no individual could achieve, and agreed standards of behaviour are upheld. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Ciaran McCreesh [EMAIL PROTECTED] wrote: If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Which is all very well, but it's kind of hard to evaluate the effectiveness of Council members and the Council as a whole if they're doing things behind everyone's backs and making horrible threats to try to prevent people from publishing logs of their goings on... Please evaluate the council's effectivness based on their achievements. And no, secret meetings don't count towards that. Seriously, i understand that the council should be as transparent as possible, but there are issues that need some confidential handling. threatening to pull each others' access if anyone goes public with whatever it was that was discussed, *something* has to be done... Um, that's hard to say without the thing in the open. I just trust the involved parties to have enough insight to bring anything that would harm gentoo to public scrunity (and following outcry). The details can remain private if necessary, but publishing a brief summary along the lines of we discussed x and y and decided z *has* Um, wait. Council *decisions*, as long as they're affecting gentoo's ways, must be out in the open. We won't end up with National Security Letters to infra or something (and i trust there'll be an uproar, if it ever reaches that point). Say, if the council decides to ice a project, how can that be kept secret? -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpSbg74jRcs0.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 14:51 +0100, Ciaran McCreesh wrote: details can remain private if necessary, but publishing a brief summary along the lines of we discussed x and y and decided z *has* to be less harmful than the current mess where people are deleting their work and considering resignation because of whatever it is the Council are up to... Except we *did* do that when we first published what we'd done with the CoC. Just because ti didn't have a shiny Meeting Summary in the topic doesn't mean it wasn't the outcome of the meeting. You know the topic of discussion. You know the outcome. The details are private. Even you admit that is fine. I mean, all this the Council is hiding something conspiracy theory is bullshit. How about when I hang out with Mike Doty and we discuss Gentoo stuff? Is that some super-secret meeting where we're trying to circumvent some supposed requirement for transparency? Of course not... If the individual members of the Council feel like getting together and discussing something, we're perfectly free to do that. We don't have to tell you what we discussed. We're allowed to bounce ideas off each other, especially when discussing things said to us in confidence. I understand that some people disagree with this, but this is a simple fact of life. There are going to be cases where people will say something to someone in confidence and not include everyone in on it. There's nothing we can do about that and there is plenty of precedence for it. When someone asks me not to betray their trust, I won't. That's just how I am. If others feel that their knowing stuff that is honestly insignificant in detail since the end result turned out to be the same and done publicly, well, they're more than welcome to run for Council, themselves, but if they were to divulge such information after being privy to it, disciplinary action would *need* to be taken to retain the trustworthiness of Gentoo as a whole. Now, that being said, we *did* have a *public* meeting about our discussion, and all *decisions* we made were 100% public. I'm sorry if anyone feels like they were slighted by not being included in the discussions prior to the public meeting, but there's nothing anywhere that says that we have to have all of our discussions in public or even made publicly available. We *do* have to have all of our decisions made public, obviously. Personally, I'd just assume make the thing public just to shut people up, but I've really grown to have a stance where I'm less likely to give in to this sort of pressure, since it will do nothing more but prove that being a whiny bitch and trying to pressure people into doing something will get people what they want. I surely don't want to set *that* precedent. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 05 Apr 2007 10:47:37 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: I mean, all this the Council is hiding something conspiracy theory is bullshit. Then why are certain Council members, you included, threatening to remove other Council members' and Gentoo developers' access if logs of whatever it was that occurred are published? What could possibly have been discussed related to the CoC that this level of threat is necessary or appropriate? Why are certain Council members claiming that if anyone disagrees with them they will soon not have a Gentoo email address? Honestly, the only reason there is any suggestion of a conspiracy is because of the threats being made by certain people to keep a certain log a secret... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote: Honestly, the only reason there is any suggestion of a conspiracy is because of the threats being made by certain people to keep a certain log a secret... The log contains information that was given to us in confidence. How much plainer do I have to make it? We can not, and WILL NOT break that trust. It really is that simple. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Switch to libchipcard3
Asking here and hoping everyone reads it may result in stable tree breakage. Open a bug and cc all maintainers of packages which depend on it, to get a definitive answer, please. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Chris Gianelloni wrote: On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote: Honestly, the only reason there is any suggestion of a conspiracy is because of the threats being made by certain people to keep a certain log a secret... The log contains information that was given to us in confidence. How much plainer do I have to make it? We can not, and WILL NOT break that trust. It really is that simple. Here's how it appears to someone reading all this, though: Ciaran *already knows* what's going on, which means that some person(s) who *were* privy to those meetings have talked, plain and simple. If that's true, then the information is out one way or another, and now the Council can decide if they want to talk about it first or let someone who wasn't actually at those meetings to divulge all the details. I guess it comes down to the trust you expect the Gentoo developers who voted for you in the first place to have in you against the trust the council members have in each other. This isn't a matter of throwing someone to the wolves, but consider the rest of the trust. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 09:04 -0700, Josh Saddler wrote: Chris Gianelloni wrote: On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote: Honestly, the only reason there is any suggestion of a conspiracy is because of the threats being made by certain people to keep a certain log a secret... The log contains information that was given to us in confidence. How much plainer do I have to make it? We can not, and WILL NOT break that trust. It really is that simple. Here's how it appears to someone reading all this, though: Ciaran *already knows* what's going on, which means that some person(s) who *were* privy to those meetings have talked, plain and simple. If that's true, then the information is out one way or another, and now the Council can decide if they want to talk about it first or let someone who wasn't actually at those meetings to divulge all the details. Well, from what I can gather, he only *thinks* he knows what was going on and he's filled in the blanks himself with whatever ideas he's come up with on his own. If he really does have the logs, he wouldn't be spouting off at the mouth since he would know that there's nothing damning in there, at all. I guess it comes down to the trust you expect the Gentoo developers who voted for you in the first place to have in you against the trust the council members have in each other. This isn't a matter of throwing someone to the wolves, but consider the rest of the trust. :) I'm not sure I follow what you're saying here. Are you saying that Gentoo developers would lose trust in us because we are keeping our word to people who spoke to us in confidence? Are you referring to a potential leak? As I said, I will not betray the trust put in me. If someone says something in confidence to me, it'll stay that way. I cannot speak for all of the other Council members, but I put the same level of trust in them to do the same. If one of them really has taken private conversations and made them public, then we really do have a problem and we need to address it, because that can severely damage Gentoo as a whole very easily. If nobody trusts us anymore, why will they support us? Simple. They won't. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Mike Doty wrote: apparent decline of QA in our packages. Anyone got numbers for that? Talking opinions, as in the SCM discussion, isn't real meaningful. Thanks, Donnie What metric would you use? the number of stages tried against a live tree before one can install? the number of companies leaving gentoo for another distro? bugs? mailing list posts? number of users? I don't know of a good metric for what you ask. Here's what I do know: 1) a QA team was formed in 06 2) QA has not visibly improved since then. To the outsider, it looks like it's gotten worse. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo Council Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iQCVAwUBRhUk0oBrouQZ9K4FAQLY0QP/fa1wU/4yJsc7eY5m/GVCrsJPNYreQf70 JxnWDBfu1bCn6byGjYnRb5rHc0MIJ6BfwxEm1cD6KKF89fRIG4RxZyzGDZd3ISnv m5tkhjHnl4EQHJyGHI/Jh5SQomFNDZJBtoRLP0YHuejCfrd6YjXoLd/PGMKogBg1 LSlthDzxrmw= =qj95 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 05 Apr 2007 09:04:09 -0700 Josh Saddler [EMAIL PROTECTED] wrote: Here's how it appears to someone reading all this, though: Ciaran *already knows* what's going on, which means that some person(s) who *were* privy to those meetings have talked, plain and simple. If that's true, then the information is out one way or another, and now the Council can decide if they want to talk about it first or let someone who wasn't actually at those meetings to divulge all the details. No, I don't know what's going on exactly -- I only have access to what people have said in public, and even then I'm not watching most of the IRC channels in which such things are usually said. What I do know: I know that there's a log involving a conversation between four or five Council members and one or two non-Council members that certain Council members are trying extremely hard to keep secret. I know that topics discussed in this log include the Code of Conduct and Gentoo sponsors, including OSL, and that it goes far beyond a private conversation. I know that at least one Council member would rather that this log were published. I know that at kingtaco and wolf31o2 have made threats along the lines of if you screw us over we will remove your access, including to a fellow Council member. I know that at least one Gentoo developer is seriously considering resigning because of what the Council have been doing on this, and that several more have expressed extreme dissatisfaction at the way the Council is handling things. I know that the person responsible for the CoC is no longer involved with it because of the Council's actions. I know that at least one Council member has made claims to the effect of if we don't get our way with this, Gentoo will be dead within a week, and that you can disagree all you want, but you won't have an @gentoo.org address if you do. What I *don't* know is what the heck the Council has done to get Gentoo into such a mess, if those claims are true. Or, if they're not, I don't know how Council members can get away with making the kind of threats they are making. Now, to resolve this... Why don't the people involved get together and publish a several paragraph summary of what was discussed? They can agree to leave out anything that really is sensitive, but since the majority of the log presumably isn't, it would be good to see a public summary. I guess it comes down to the trust you expect the Gentoo developers who voted for you in the first place to have in you against the trust the council members have in each other. This isn't a matter of throwing someone to the wolves, but consider the rest of the trust. :) It kind of stops becoming a matter of trust when Council members that also have infra powers make threats about removing other Council members' access... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 05 Apr 2007 12:24:06 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Well, from what I can gather, he only *thinks* he knows what was going on and he's filled in the blanks himself with whatever ideas he's come up with on his own. If he really does have the logs, he wouldn't be spouting off at the mouth since he would know that there's nothing damning in there, at all. I know that you and kingtaco threatened to remove a fellow Council member's access if he didn't go along with you on whatever it was you were discussing. If there's nothing damning in there, why would you do such a thing? I'm not sure I follow what you're saying here. Are you saying that Gentoo developers would lose trust in us because we are keeping our word to people who spoke to us in confidence? Are you referring to a potential leak? There is nothing stopping you from posting a several paragraph summary of whatever it was that was being discussed. Leave gaps for confidential things as appropriate, but don't use it as an excuse for burying the whole thing as you're trying to do here. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Ciaran McCreesh wrote: On Thu, 05 Apr 2007 12:24:06 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Well, from what I can gather, he only *thinks* he knows what was going on and he's filled in the blanks himself with whatever ideas he's come up with on his own. If he really does have the logs, he wouldn't be spouting off at the mouth since he would know that there's nothing damning in there, at all. I know that you and kingtaco threatened to remove a fellow Council member's access if he didn't go along with you on whatever it was you were discussing. If there's nothing damning in there, why would you do such a thing? From what I have read so far, it wasn't a question of someone being pressured to go along with.. whatever it was they were discussing but rather to keep a confidence. Mr Gianelloni is right: if other parties cannot have confidential discussions with Gentoo, it will damage the distribution. As such, it is imo incumbent upon council members to keep such matters (whatever they might be) private. He has already stipulated that all decisions we made were 100% public and We do have to have all of our decisions made public, obviously. That's transparent enough for me at least. I don't want to be privy to every discussion, and I certainly don't want to know about say aspects of other people's private lives which might affect their work, or even that company X is having confidential talks with gentoo, which might come to nothing. I just want to enjoy the software and the community, and these frankly paranoid ramblings make the dev list much less fun. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for April
* Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: pciparm init script for sys-apps/pciutils
Le Wed, 04 Apr 2007 23:43:07 +0100, Steve Long [EMAIL PROTECTED] a écrit : federico wrote: Steve Long ha scritto: What benefits does it show; why would I want it on my machine? because it provides a place to store those settings; latency timer settings? the coder in me can like that idea, the usr wants to know so what? http://www.gentoo.org/doc/en/articles/hardware-stability-p2.xml I have to say the pci latency tweaks were successful for me with my old hardware. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] QA sucks
* Mike Doty [EMAIL PROTECTED]: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. So what do you want to do about it? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? -mike pgpWtl3EG7L68.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 19:06 +0100, Steve Long wrote: He has already stipulated that all decisions we made were 100% public and We do have to have all of our decisions made public, obviously. Exactly. Everything that was decided was done so in public and quite plainly. If certain people have a problem with that, I'm honestly so fed up with this conspiracy bullshit that I've decided to just let those people think whatever it is that they feel like. I don't have the time nor the energy to combat such ignorance and outright lies. What I do with my Council hat on, I do with the best intentions of Gentoo at heart. If the developer community feels I'm not doing that job to the best of my ability, they can vote my ass out next election. Gentoo is *not* a government. It doesn't have checks and balances, and it really doesn't need them. The Council is elected for exactly this sort of thing. We are elected to represent the interests of Gentoo as a whole. Pissing off a very minority of the developer pool because we decided to actually make a decision is something I am fully ready to live with and accept the consequences for doing. I'm sticking with my principles and simply ignoring the continued noise on this subject. If anyone feels like talking to me about it, they can contact me privately so we can have a secret conspiracy discussion that nobody else knows about. Oh noes! Cabal! *roll eyes* -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 14:09 schrieb Wernfried Haas: If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Especially as there are council members who don't rely like any privacy in that at all. vapier comes to my mind there :-D Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thursday 05 April 2007, Ciaran McCreesh wrote: Unfortunately, what the GLEP doesn't do is prevent the Council from having secret meetings and refusing to discuss not only the content of those meetings but even the topic. Perhaps a requirement that any Council meeting logs be made public would be useful, with a waiver that the Council can have a secret meeting if it officially announces that it is doing so? what exactly does this solve ? nothing ? we go from having meetings nobody knows about where discussions happen that no one sees to having meetings everyone knows about where discussions happen that no one sees ... the only thing that comes from this is now people have more things to refer to vaguely to support lame hypothetical sitautions ive got a better idea Ciaran, stop spreading FUD ... i do believe we have something now that says purposefully spreading FUD is a no no -mike pgpTlO1F2WVYB.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? That's seems like a reasonable time frame. Any information would be outdated at that time, and not have any effect over current issues. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. I disagree. The QA team is doing a lot of work. * Mr_Bones still runs QA checks on the whole tree daily and people are still scared if he pops up and pastes his repoman/pquery output. * Tove still looks out for anything obviously wrong, and he's quite good at constantly buggering people about it. * Other people including myself run different (selected) kinds of QA checks on a case by case basis and usually fix the affected parts of the tree, and sometimes nobody but the maintainers notice that. * You don't need to be a member of the QA project/team to do QA. I say this here, but i think that should be self-evident. * Antarus and spb are preparing to take actions against at least one persistent QA offender, and devrel told them how to do it properly. * QA team, one of its subprojects to be precise, has recently published the draft for Package Manager Specifications. * The work of our QA team is mostly under the hood (and i don't mean sekrit by that!), and that's how it should be done imho. Naturally this can mean that people think they aren't working at all if they don't see flamewars and/or big announcements/blog entries on how they fixed QA problem X. I prefer a silent QA team personally. * There is at least one outstanding QA issue that i know of which is related to Portage and can't be fixed w/o slot deps properly. Read: KDE's problems with ranged deps and the way it currently breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. * There is a _lot_ of minor QA stuff on bugs.g.o, and everybody (not only QA team members) are invited to work on it. The only prerequisite for helping with it is: Know what you do. If you don't, learn it. * QA _starts_ by such minor things as whitespace problems or proper ChangeLog entries, so there is enough work for everybody out there to help with! If anybody is interested, i can provide you (this is all gentoo ebuild devs*) either with lists of QA problems in the tree to fix, or with tools that enable you to search for one particular (kind of) QA violation in the whole tree, whatever your prefer. Danny *I'm only adressing gentoo devs here as patches against the whole tree don't make sense. The tree changes to fast for it. -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 21:20 schrieb Mike Frysinger: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? -mike What happened to 1 year? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 22:15 +0200, Danny van Dyk wrote: Am Donnerstag, 5. April 2007 14:09 schrieb Wernfried Haas: If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Especially as there are council members who don't rely like any privacy in that at all. vapier comes to my mind there :-D I don't like it, either. I understand that there are sometimes requirements on keeping things private, but I'm all for doing everything as publicly as possible. It keeps complete wastes of time like this current thread from cropping up as easily, for one. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thursday 05 April 2007, Danny van Dyk wrote: Am Donnerstag, 5. April 2007 21:20 schrieb Mike Frysinger: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? What happened to 1 year? i'm fine with 1 week, but if people want to argue lower ... -mike pgp4YAlgmVwkl.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote: Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. I disagree. The QA team is doing a lot of work. * Mr_Bones still runs QA checks on the whole tree daily and people are still scared if he pops up and pastes his repoman/pquery output. Last I knew, bones wasn't part of the QA team anymore. Historically he's operated as the scary guy who didn't need a team to spank your ass anyways. (that's a joke about him, not the QA team also). pcheck btw, not pquery (former does quality checks, latter is for metadata lookup). And you claim you can recommend to people which tools to use :-) * You don't need to be a member of the QA project/team to do QA. I say this here, but i think that should be self-evident. Agreed, although worth keeping in mind the question specifically was what the QA _team_ was up to; thus would try to address that instead of pointing out non-qa team folk do things. Simple example- I still do a bit of QA, doesn't mean it's even remotely quantifiable as QA team work (which is what he was asking) :) Don't particularly want to get sucked into yet another QA team are lazy slackers discussion, just pointing out bits above. Advice wise, take it or leave. Meanwhile onto the real meat of the email... * There is at least one outstanding QA issue that i know of which is related to Portage and can't be fixed w/o slot deps properly. Read: KDE's problems with ranged deps and the way it currently breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. Elaborating a bit, this actually is only a problem for pkgcore and paludis; portage isn't affected since it prefers to try pulling the metadata from $PORTDIR; reasoning is that way screw ups in the metadata that are now locked in the vdb can be worked around via it. You can trigger the same issue in portage via wiping pretty much everything in PORTDIR (switching the tree, or just a literal rm of everything but profiles crap), but that's fairly corner case. Don't much like the behavior myself, but updates/* would need expansion to address the (massively long term) reasoning for portages behavior. Upshot, running from vdb only instead of the dual lookup would speed up portages resolution via less IO/parsing... Either way, the kde/qt issue was known from the get go- since slot deps weren't available when they started down this path, they should have used new style virtuals instead. Yes it's ugly, backwards compatibility usually isn't utterly pretty- upshot of it however is that the upgrade node is just a new style virtual, no real cost for the operation. Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual needs to have been on release media for at least 6 months would apply here at the very least. The problem is that 2.1.2 is the first portage version to have slot deps- that is a fairly recent stabling, so there still would be a good chunk of time to wait *if* the daft old method of just shoving stuff in and watching things break was took. Meanwhile, worth remembering during the interim while slot deps aren't usable, new style virtual does address it (even if it's a gross trick) :) ~harring pgpSqqRDjEheH.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On 4/5/07, Chris Gianelloni [EMAIL PROTECTED] wrote: I just find this whole situation hysterical since you have so many people saying the Council needs to grow a pair and actually try to enact some good, and when we do, you hear a few vocal individuals running around screaming like we killed their kitten. So which is it? Why would the council need to grow a pair when it already has SpanKY's ;o) I only proposed the veto thing because I felt that it could be a good compromise to reassure those devs who fall for the conspiracy theories, so that they feel safe and get back to work. I never believed the council would realistically do something that would harm Gentoo. I'm sorry for the confusion if any. Would you rather have a strong Council that is capable of making decisions without having to worry about whether that decision is popular or not, or would you rather have a weak Council that cannot do anything without prior developer approval, completely castrating their abilities to enact change for fear of being removed from office? Agreed, here. There was one vote last summer when we collectively decided that the current council members were the best for the job. And that's all we need until next summer. I have been reading carefully a lot of emails and irclogs for some time, especially during the recent events, and I must say that I'm very pleased with the way things went, and how people (of the council and devrel mainly) interacted. While I'm not 100% satisfied with the outcome, which may be a sure sign the right decisions were made, I certainly won't complain. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Ned Ludd kirjoitti: On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. We don't have to decide to open up all the old archives but instead we can decide that posts from now on will be made public after X amount of time has passed. Regards, Petteri -- Gentoo/Recruiters lead Gentoo/Java lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, Apr 05, 2007 at 02:18:40PM -0700, Ned Ludd wrote: I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. As far i remember the idea was only to make mails public from whenever this applies, not the ones sent before. So you can still stop sending your weekly goat pics once that happens. :-] cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpRjeCV5NaCu.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring: On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote: Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: apparent decline of QA in our packages. Why do you want this to be a council topic if it wasn't even a topic here or on gentoo-qa@ ? Because our QA sucks and noone is doing a damn thing about it. I disagree. The QA team is doing a lot of work. * Mr_Bones still runs QA checks on the whole tree daily and people are still scared if he pops up and pastes his repoman/pquery output. Last I knew, bones wasn't part of the QA team anymore. Historically See my comments regard QA team membership and doing QA work. Having a QA team doesn't magically improve the quality of the tree. he's operated as the scary guy who didn't need a team to spank your ass anyways. (that's a joke about him, not the QA team also). pcheck btw, not pquery (former does quality checks, latter is for metadata lookup). And you claim you can recommend to people which tools to use :-) I never claimed i'd recommend your set of tools. This doesn't mean they are inferior, it's just that i can't recommend what i don't use and know. * You don't need to be a member of the QA project/team to do QA. I say this here, but i think that should be self-evident. Agreed, although worth keeping in mind the question specifically was what the QA _team_ was up to; thus would try to address that instead of pointing out non-qa team folk do things. Simple example- I still do a bit of QA, doesn't mean it's even remotely quantifiable as QA team work (which is what he was asking) :) Don't particularly want to get sucked into yet another QA team are lazy slackers discussion, just pointing out bits above. Advice wise, take it or leave. Heh... Meanwhile onto the real meat of the email... * There is at least one outstanding QA issue that i know of which is related to Portage and can't be fixed w/o slot deps properly. Read: KDE's problems with ranged deps and the way it currently breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. Elaborating a bit, this actually is only a problem for pkgcore and paludis; portage isn't affected since it prefers to try pulling the metadata from $PORTDIR; reasoning is that way screw ups in the metadata that are now locked in the vdb can be worked around via it. AFAIK zmedico spoke about moving portage to use vdb metadata instead. Before this could happen we needed a fix for it. You can trigger the same issue in portage via wiping pretty much everything in PORTDIR (switching the tree, or just a literal rm of everything but profiles crap), but that's fairly corner case. Don't much like the behavior myself, but updates/* would need expansion to address the (massively long term) reasoning for portages behavior. Upshot, running from vdb only instead of the dual lookup would speed up portages resolution via less IO/parsing... Either way, the kde/qt issue was known from the get go- since slot deps weren't available when they started down this path, they should have used new style virtuals instead. Yes it's ugly, backwards compatibility usually isn't utterly pretty- upshot of it however is that the upgrade node is just a new style virtual, no real cost for the operation. Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual needs to have been on release media for at least 6 We can push for an EAPI=1 == (EAPI=0 + slot deps)... months would apply here at the very least. The problem is that 2.1.2 is the first portage version to have slot deps- that is a fairly recent stabling, so there still would be a good chunk of time to wait *if* the daft old method of just shoving stuff in and watching things break was took. What breakage specifically? Portage versions that don't support EAPI? Meanwhile, worth remembering during the interim while slot deps aren't usable, new style virtual does address it (even if it's a gross trick) I prefer we solve this problem instead of hacking around it once more. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
On Fri, Apr 06, 2007 at 12:16:18AM +0200, Danny van Dyk wrote:
* There is at least one outstanding QA issue that i know of which
is related to Portage and can't be fixed w/o slot deps properly.
Read: KDE's problems with ranged deps and the way it currently
breaks the vdb's RDEPEND entries, especially regarding qt and
kdelibs.
Elaborating a bit, this actually is only a problem for pkgcore and
paludis; portage isn't affected since it prefers to try pulling the
metadata from $PORTDIR; reasoning is that way screw ups in the
metadata that are now locked in the vdb can be worked around via it.
AFAIK zmedico spoke about moving portage to use vdb metadata instead.
Before this could happen we needed a fix for it.
Suspect zac could confirm that's it's about weekly now for me nagging
him about gutting that ;)
You can trigger the same issue in portage via wiping pretty much
everything in PORTDIR (switching the tree, or just a literal rm of
everything but profiles crap), but that's fairly corner case.
Don't much like the behavior myself, but updates/* would need
expansion to address the (massively long term) reasoning for portages
behavior. Upshot, running from vdb only instead of the dual lookup
would speed up portages resolution via less IO/parsing...
Either way, the kde/qt issue was known from the get go- since slot
deps weren't available when they started down this path, they should
have used new style virtuals instead. Yes it's ugly, backwards
compatibility usually isn't utterly pretty- upshot of it however is
that the upgrade node is just a new style virtual, no real cost for
the operation.
Breaking EAPI=0 via pushing slot deps in isn't much of an option in
my opinion; usual needs to have been on release media for at least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...
Can, yep, although that was originally blocked by EAPI=0 must be
defined, which folks seem to have backed off on.
One issue with adding EAPI=1 having just slot deps is that it skips
out on some long term changes intended- default src_install for
example, hell, making the default phase functions into an eclass
equivalent template. Clarifying, instead of
src_compile() {
default src compile crap
}
would do
base_src_compile() {
default src compile crap
}
That way if you just need to tweak one thing, you can still use the
default src_compile- basically same trick EXPORT_FUNCTIONS does.
Either way, EAPI=1 *should* have a bit more then just slot deps in my
opinion; very least it needs discussion to discern what folks want.
months would apply here at the very least. The problem is that
2.1.2 is the first portage version to have slot deps- that is a
fairly recent stabling, so there still would be a good chunk of time
to wait *if* the daft old method of just shoving stuff in and
watching things break was took.
What breakage specifically? Portage versions that don't support EAPI?
Breakage there I'm referring to trying to is a set of folks
trying to shove it into EAPI=0.
Meanwhile, worth remembering during the interim while slot deps
aren't usable, new style virtual does address it (even if it's a
gross trick)
I prefer we solve this problem instead of hacking around it once more.
Even with EAPI=1 route, still going to require some time to actually
address it- have to define EAPI=1, make sure portage supports it
fully, make sure it's stable for all arches, etc. That's a several
month proceess, best case, 30 days if somehow everyone agrees to
eapi=1 today, zac implements it tonight, and releases it tomorrow
morning (with no bugs).
So... again- it's not pretty, but it's not an issue that's going to be
solved tomorrow, so it's not a bad idea to take a look at ways to work
around it. Very least, if the new style virtual route was taken,
switching over to slot deps (when available) would be easy- update the
virtual, then start pruning the tree for anything depending on the
virtual.
~harring
pgpUYtZfJCyM1.pgp
Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thursday 05 April 2007, Wernfried Haas wrote: On Thu, Apr 05, 2007 at 02:18:40PM -0700, Ned Ludd wrote: I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. As far i remember the idea was only to make mails public from whenever this applies, not the ones sent before. So you can still stop sending your weekly goat pics once that happens. :-] i'd like both, but i'll take what i can get -mike pgpQhCeFDIaCz.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual needs to have been on release media for at least 6 We can push for an EAPI=1 == (EAPI=0 + slot deps)... Can, yep, although that was originally blocked by EAPI=0 must be defined, which folks seem to have backed off on. Not sure if slot deps themselves could even replace version ranges hacks without also solving bug 4315 (native version ranges) in all cases. IMHO it should be possible at least to specify slot+usual version limit, to make it worth EAPI bump. One issue with adding EAPI=1 having just slot deps is that it skips out on some long term changes intended- default src_install for So what, longer term changes could wait for EAPI=2. Why not make experience with EAPI bumping with something smaller for a start, instead of trying to make one big bump that will bring all changes we can think of now, but will be implemented only in 2010... Now it may look like I contradict myself saying to bump ASAP but not without solving bug 4315 first. But I see slot deps without limits only half of a feature. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFXsstbrAj05h3oQRAid6AJ4lJldHuRwA0rHdr+CwGlth6zgG5wCgixJO 7PWG4j0nMOqdyR57bMW+r3E= =Cnya -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Freitag, 6. April 2007 00:41 schrieb Vlastimil Babka:
Brian Harring wrote:
Breaking EAPI=0 via pushing slot deps in isn't much of an option
in my opinion; usual needs to have been on release media for at
least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...
Can, yep, although that was originally blocked by EAPI=0 must be
defined, which folks seem to have backed off on.
Not sure if slot deps themselves could even replace version ranges
hacks without also solving bug 4315 (native version ranges) in all
cases. IMHO it should be possible at least to specify slot+usual
version limit, to make it worth EAPI bump.
Please have a look at the slot dep format proposal. AFAIK none of the
P{aludis,kgcore,ortage} devs disagreed on that.
One issue with adding EAPI=1 having just slot deps is that it skips
out on some long term changes intended- default src_install for
So what, longer term changes could wait for EAPI=2. Why not make
experience with EAPI bumping with something smaller for a start,
instead of trying to make one big bump that will bring all changes we
can think of now, but will be implemented only in 2010...
I agree fully. Nobody said we can't finetune the EAPI steps/bumps.
Now it may look like I contradict myself saying to bump ASAP but not
without solving bug 4315 first. But I see slot deps without limits
only half of a feature.
Nobody but talked about that.
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Danny van Dyk wrote:
Not sure if slot deps themselves could even replace version ranges
hacks without also solving bug 4315 (native version ranges) in all
cases. IMHO it should be possible at least to specify slot+usual
version limit, to make it worth EAPI bump.
Please have a look at the slot dep format proposal. AFAIK none of the
P{aludis,kgcore,ortage} devs disagreed on that.
Sorry, I thought it was only about what's already implemented in portage
and that's AFAIK only =cat/package:slot . Fine then.
- --
Vlastimil Babka (Caster)
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGFX9QtbrAj05h3oQRAsPnAJ45IEwpsKQywZstG/hNgeRZVhoc6wCfcn3n
YG1bvuQg9z0BzLiTqFEtQKE=
=gEao
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Am Freitag, 6. April 2007 00:11 schrieb Brian Harring:
You can trigger the same issue in portage via wiping pretty much
everything in PORTDIR (switching the tree, or just a literal rm
of everything but profiles crap), but that's fairly corner case.
Don't much like the behavior myself, but updates/* would need
expansion to address the (massively long term) reasoning for
portages behavior. Upshot, running from vdb only instead of the
dual lookup would speed up portages resolution via less
IO/parsing...
Either way, the kde/qt issue was known from the get go- since
slot deps weren't available when they started down this path,
they should have used new style virtuals instead. Yes it's ugly,
backwards compatibility usually isn't utterly pretty- upshot of
it however is that the upgrade node is just a new style virtual,
no real cost for the operation.
Breaking EAPI=0 via pushing slot deps in isn't much of an option
in my opinion; usual needs to have been on release media for at
least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...
Can, yep, although that was originally blocked by EAPI=0 must be
defined, which folks seem to have backed off on.
EAPI=0 will be defined by PMS once accepted by the council
One issue with adding EAPI=1 having just slot deps is that it skips
out on some long term changes intended- default src_install for
example, hell, making the default phase functions into an eclass
equivalent template. Clarifying, instead of
src_compile() {
default src compile crap
}
would do
base_src_compile() {
default src compile crap
}
That way if you just need to tweak one thing, you can still use the
default src_compile- basically same trick EXPORT_FUNCTIONS does.
What has that to do with slot deps? You can incremently define EAPI=2
and include it there.
Either way, EAPI=1 *should* have a bit more then just slot deps in my
opinion; very least it needs discussion to discern what folks want.
Is there any technical reason why EAPI=1 should be a major step that
includes all we want to get in/get rid off?
months would apply here at the very least. The problem is that
2.1.2 is the first portage version to have slot deps- that is a
fairly recent stabling, so there still would be a good chunk of
time to wait *if* the daft old method of just shoving stuff in
and watching things break was took.
What breakage specifically? Portage versions that don't support
EAPI?
Breakage there I'm referring to trying to is a set of folks
trying to shove it into EAPI=0.
I was not talking about that at all. And yes, i know how you are
refering to. And yes, it's up to the council to decide that.
And yes, there is a bug[1] covering it.
Meanwhile, worth remembering during the interim while slot deps
aren't usable, new style virtual does address it (even if it's a
gross trick)
I prefer we solve this problem instead of hacking around it once
more.
Even with EAPI=1 route, still going to require some time to actually
address it- have to define EAPI=1, make sure portage supports it
fully, make sure it's stable for all arches, etc. That's a several
month proceess, best case, 30 days if somehow everyone agrees to
eapi=1 today, zac implements it tonight, and releases it tomorrow
morning (with no bugs).
Very well. I'd like to target this for KDE people to use it for kde-4.
So... again- it's not pretty, but it's not an issue that's going to
be solved tomorrow, so it's not a bad idea to take a look at ways to
work around it. Very least, if the new style virtual route was
taken, switching over to slot deps (when available) would be easy-
update the virtual, then start pruning the tree for anything
depending on the virtual.
And what about the vdb RDEPENDs on said virtual? That the whole point,
sanitize the vdb metadata.
Danny
[1] https://bugs.gentoo.org/show_bug.cgi?id=170161
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] *DEVELOPMENT* mail list, right?
When you pop into your mail client of choice and find 50+ unread messages in the last few hours, you know what kind of day [EMAIL PROTECTED] is having. Don't suppose we could get on with that silly topical thing of development? Surely there's a usenet channel where you can discuss conspiracy.gentoo at length? Or at least take it to the user list? /me stretches and blinks So, fellow devs, what's new with development? For those interested, genlop has migrated into gentoo as a project with the permission of upstream, which no longer maintain it. Um...any new tools or projects people are working on? Anyone? -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpunOQNpiFbJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
On Fri, Apr 06, 2007 at 12:41:50AM +0200, Vlastimil Babka wrote: Brian Harring wrote: Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual needs to have been on release media for at least 6 We can push for an EAPI=1 == (EAPI=0 + slot deps)... Can, yep, although that was originally blocked by EAPI=0 must be defined, which folks seem to have backed off on. Not sure if slot deps themselves could even replace version ranges hacks without also solving bug 4315 (native version ranges) in all cases. IMHO it should be possible at least to specify slot+usual version limit, to make it worth EAPI bump. One issue with adding EAPI=1 having just slot deps is that it skips out on some long term changes intended- default src_install for So what, longer term changes could wait for EAPI=2. Why not make experience with EAPI bumping with something smaller for a start, instead of trying to make one big bump that will bring all changes we can think of now, but will be implemented only in 2010... A 101 small little bumps results in a general pain in the ass for ebuild devs; if a change is ready to go for EAPI=1 (whether implemented now, or bloody simple), and folks *agree to it*, then it should go in. I'm not advocating waiting for every little thing to be shoved in. That said, there are lots of minor tweaks that have been desired, but haven't been implementable since they would break backwards compatibility and no versioning scheme existed. I've got a list floating around somewhere of the specifics, but top of the head- 1) killing DEPEND/RDEPEND autosetting once and for all 2) shift the default phase funcs into a fake eclass; basically the base_src_compile example in the previous email. 3) default src_install (currently is empty) 4) *potentially* chunking up src_compile into src_configure and src_compile. 5) slightly addressed via #2, a 'prepare phase' for patching and other crap. Not a huge fan, but it's also not something I'm pushing. 6) drop useq/hasq 7) whatever api additions required to remove the need for raw vdb access by ebuilds (contents, IUSE, and USE seem to be the primary ones atm till use deps are available). 8) potential, although it requires work- glep33. I'd probably be willing to do the portage modifications for that one; upshot of it is that it allows breaking eclass api as needed, further reorganizes their on disk layout so signing/manifests can sanely be integrated. So... #8 is slightly large admittedly. Rest are pretty damn minor, bit of discussion required, but minimal real work to code it- stuff like that, no reason *not* to slide it into eapi=1. Now it may look like I contradict myself saying to bump ASAP but not without solving bug 4315 first. But I see slot deps without limits only half of a feature. So far, the syntax I've seen for 4315 has made me want to club baby seals, hit the hash pipe, and make a run for the presidency... Offhand, majority of the tree issues can be addressed via slot deps- the remaining chunks that can't, can be addressed via a slightly smarter resolver combined with folks using blockers- simple example, need =1.3 2.0 for a non-slotted package, use =1.3 !2.0. Can invert it to 2.0 !1.3 if you prefer, although the latter is slightly preferable on the offchance the package some day becomes slotted. Granted, it's not perfect- point is it's actually doable now without format changes. Other question there is how many ebuilds in the tree actually *need* this, beyond just slot deps. Either way, folks ought to chime in... ~harring pgpmqvRrJjXxB.pgp Description: PGP signature
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Cummings wrote: When you pop into your mail client of choice and find 50+ unread messages in the last few hours, you know what kind of day [EMAIL PROTECTED] is having. Don't suppose we could get on with that silly topical thing of development? Surely there's a usenet channel where you can discuss conspiracy.gentoo at length? Or at least take it to the user list? /me stretches and blinks So, fellow devs, what's new with development? For those interested, genlop has migrated into gentoo as a project with the permission of upstream, which no longer maintain it. Um...any new tools or projects people are working on? Anyone? I'm working on figuring out how to fix things I don't maintain (stupid lack of graphics *bonks the app*)..and trying to get motivated to deal with a package that has a nasty install to be upgraded to a new version. Does that count? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFYVxSENan+PfizARAlASAJ91A85lHSoocCZHpQACxBJZZ4BaWACdHC33 ufXQQonw7lFh3G5hVORYiGs= =oyCR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] s390 and s390x dev hosts
thanks to some awesome sponsor help, we have s390 and s390x hosts now (btw, as of two days ago, we have a port of Gentoo to s390x) for devs who wish to help out the s390/s390x team, feel free to contact me ... note that i mean people who wish to join the s390/s390x team, not just test random package $foo, as our resources are able to accommodate just that for now ... -mike pgp3fKTcZPj9U.pgp Description: PGP signature
