Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 12:52:37 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: I went and created a tiny script[1] to change mips KEYWORDS to ~mips in the tree, and created a patch[2] against the current CVS tree. Were the Council to choose this course of action, the work is mostly done. Ops! Your script doesn't work! You forgot about profiles and eclasses. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 12:33:40 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: This is why I find it funny that people even bother to listen to Ciaran, at all. All he cares about is his little pet projects/teams and doesn't care if it increases workload for everybody else. I mean, where would Gentoo be if not for our support of mips? Oh dear, we'd definitely be nowhere near as popular... *cough* Ah yes, you're entirely right. We should all listen to you instead, because of the brilliant job you're doing on your pet projects, 2007.1 and the GWN. In the mean time, I'll just say that if you don't drop the personal attacks and apologise, I'll have no choice but to take it up with devrel. You're supposed to be arguing technically here, but all you do is go around name calling. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 10 Jan 2008 07:08:46 + Ciaran McCreesh [EMAIL PROTECTED] wrote: In the mean time, I'll just say that if you don't drop the personal attacks and apologise, I'll have no choice but to take it up with devrel. s|devrel|userrel| Thanks, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 2008-01-10 at 07:08 +, Ciaran McCreesh wrote: On Wed, 09 Jan 2008 12:33:40 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: This is why I find it funny that people even bother to listen to Ciaran, at all. All he cares about is his little pet projects/teams and doesn't care if it increases workload for everybody else. I mean, where would Gentoo be if not for our support of mips? Oh dear, we'd definitely be nowhere near as popular... *cough* Ah yes, you're entirely right. We should all listen to you instead, because of the brilliant job you're doing on your pet projects, 2007.1 and the GWN. I'm afraid that once again, you simply don't have a clue what you're talking about. I've not been doing the GWN for a few months now, nor was it *ever* a pet project of mine. Keep it coming. You're entertaining the *hell* out of me. *grin* In the mean time, I'll just say that if you don't drop the personal attacks and apologise, I'll have no choice but to take it up with devrel. You're supposed to be arguing technically here, but all you do is go around name calling. Feel free to bring up an issue with Developer Relations. They'll likely throw it out because YOU ARE NOT A DEVELOPER. Also, you'll notice that rather than call you names, which is really your forte, I have instead pointed out why I think your opinion is completely worthless to Gentoo. If you feel insulted by people pointing out things like you being fired from the project due to your attitude, perhaps you shouldn't have gone and gotten yourself fired? I mean, you made your bed, now lie in it. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, Jan 10, 2008 at 11:49:24AM -0800, Chris Gianelloni wrote: I've not been doing the GWN for a few months now Yes, we noticed that. What about 2007.1? As release engineering lead that *should* be your pet project. -- Alexander Færøy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 10 Jan 2008 11:49:24 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: Feel free to bring up an issue with Developer Relations. They'll likely throw it out because YOU ARE NOT A DEVELOPER. Also, you'll notice that rather than call you names, which is really your forte, I have instead pointed out why I think your opinion is completely worthless to Gentoo. If you feel insulted by people pointing out things like you being fired from the project due to your attitude, perhaps you shouldn't have gone and gotten yourself fired? I mean, you made your bed, now lie in it. I'm sorry, what do you do around here again? -- Ciaran McCreesh signature.asc Description: PGP signature
RE: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: Chris Gianelloni [EMAIL PROTECTED] wrote: Feel free to bring up an issue with Developer Relations. They'll likely throw it out because YOU ARE NOT A DEVELOPER. Also, you'll notice that rather than call you names, which is really your forte, I have instead pointed out why I think your opinion is completely worthless to Gentoo. If you feel insulted by people pointing out things like you being fired from the project due to your attitude, perhaps you shouldn't have gone and gotten yourself fired? I mean, you made your bed, now lie in it. I'm sorry, what do you do around here again? Could everyone just drop the 'mud slinging' already, from all parties/in all directions. The topic of this thread, and the relevant posts as best as I can tell, were about the council meeting. It's going on as I type, so the thread should be over. Join us in #council if you want to see your council at work, addressing the Gentoo business that you requested them to. Kind regards, Christina Fullam Gentoo Developer Relations Lead | Gentoo Public Relations -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 04:11:58 +0100 Matthias Langer [EMAIL PROTECTED] wrote: Really, this discussion is completely pointless unless some mips users/developers join in - or aren't there any at all? I'd imagine most of them are staying well clear of it because they've already seen this discussion a dozen times before and know that it's just the usual malcontents going around making largely bogus claims and backing them up with lots of thinly veiled mips bashing rather than anything relevant... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Tue, 08 Jan 2008 18:59:29 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. We want the Council to do something about this issue. You can deny the issue all that you want or try to deflect conversation from the actual issue, but your opinion isn't very important to the much of the current developer pool, seeing as how it doesn't affect you in any way, having been thrown from the project, and all. Ah, so now what matters is who says something, not whether or not it's true. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On 1/8/08, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. I was going to go with 'the stable glibc changed' or 'some lib this software depended on was updated to a new version' or any other action that could cause software to not work as intended. I'm not trying to make the argument that developers don't screw up. Certainly mr_bones can attest that they do it on a daily basis. I think the argument here is that developers control ebuilds. If a given ebuild is causing 'trouble' for a maintainer it is within their control to remove the ebuild. Just as if a given package is causing the maintainer grief it can be deleted from the tree, so can keywords for a given arch be removed for a given ebuild (and possibly that ebuild removed because it is known to be old and buggy.) If the arch team wants that ebuild in the tree they should do some work to keep a given package up to date in terms of other arches or we should define some sort of metadata that notifies people that the arch team is the 'maintainer' for a given version of a package. I agree that you should not break the arch's tree by removing a given package (or it's last stable ebuild). -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 9 Jan 2008 06:58:40 -0800 Alec Warner [EMAIL PROTECTED] wrote: I think the argument here is that developers control ebuilds. If a given ebuild is causing 'trouble' for a maintainer it is within their control to remove the ebuild. Just as if a given package is causing the maintainer grief it can be deleted from the tree, so can keywords for a given arch be removed for a given ebuild (and possibly that ebuild removed because it is known to be old and buggy.) If the arch team wants that ebuild in the tree they should do some work to keep a given package up to date in terms of other arches or we should define some sort of metadata that notifies people that the arch team is the 'maintainer' for a given version of a package. The problem is this: the impact upon an arch of dekeywording something is almost always far higher than the impact of leaving things the way they are. And even if, like some people here, you don't care about the arch, the impact upon the rest of the tree when you dekeyword is often massive. If, for example, an arch were to have their last stable keyword of something like gtk+ removed by a developer who did it in order to 'fix' a repoman message, a very large number of other developers would then end up with a far bigger repoman mess. Heck, most of the repoman messages people are moaning about are caused by developers doing exactly this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
I'd imagine most of them are staying well clear of it because they've already seen this discussion a dozen times before and know that it's just the usual malcontents going around making largely bogus claims and backing them up with lots of thinly veiled mips bashing rather than anything relevant... Your demand for evidence in this thread doesn't seem balanced with your ability to only offer speculation. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. Let's assume that you are right, and that dropping keywords is not a proper thing to do. What's the proper fix for when keyword requests stagnate in bugzilla? If the arch team in question was to completely disband and stop all keywording today, then you're suggesting the proper thing to do is to never remove the ebuild from portage that has keywords for that arch? And thus, the current system of filing a stabilization request and waiting indefinitely is sufficient? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 9 Jan 2008 10:36:13 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. Let's assume that you are right, and that dropping keywords is not a proper thing to do. What's the proper fix for when keyword requests stagnate in bugzilla? That depends upon whether the keyword request is important. If it isn't, you wait for the arch team to get around to it. If it is (and legitimately so -- we're not talking spurious I want to remove this old version that doesn't affect anything, that works fine and isn't causing any problems beyond it existing here), you ask the arch team to prioritise it, explaining why. If the arch team in question was to completely disband and stop all keywording today, then you're suggesting the proper thing to do is to never remove the ebuild from portage that has keywords for that arch? If that ever comes remotely close to happening then the issue can be raised when it does. You might as well ask what would happen if suddenly all the KDE maintainers disappeared. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 17:49:40 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: What's the proper fix for when keyword requests stagnate in bugzilla? That depends upon whether the keyword request is important. Let's take a real world example: KDE 3.5.5 is old, buggy and has some important issues which won't be fixed anymore. Yet it's the most proven version on mips. If it is (and legitimately so I hope you'll accept it when I say that 3.5.5 is such a legitimate case now. Why? It was good enough to be keyworded stable at one point. What would you suggest to do now? I think we've done all we could short of the following: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. b) package.mask 3.5.5 with a big, fat warning and let the users decide. Same drawbacks as a). ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. c) Drop 3.5.5 from the tree. The cleanest but most radical solution. If mips' users want KDE, they would have to bug (sic!) the mips team. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. The solution I favour by far is c). What's your suggestion or did I miss any other viable solution? Just doing nothing is not an option here, I'd say, but state your case. 3.5.5 was good enough to be keyworded stable at one point. Thus, it can't be *that* bad. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote: 3.5.5 was good enough to be keyworded stable at one point. Thus, it can't be *that* bad. So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? In your world you allow mips users to trivially install now flawed and insecure software, instead of having to add to /etc/portage/package.keywords or package.unmask Yes, this breaks their tree, but it's fixable from the users end as we can rest in the knowledge that mips users have acknowledged the security flaw by adding the package to the above mentioned files. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On 1/9/08, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 09 Jan 2008 17:49:40 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: What's the proper fix for when keyword requests stagnate in bugzilla? That depends upon whether the keyword request is important. Let's take a real world example: KDE 3.5.5 is old, buggy and has some important issues which won't be fixed anymore. Yet it's the most proven version on mips. If it is (and legitimately so I hope you'll accept it when I say that 3.5.5 is such a legitimate case now. Why? It was good enough to be keyworded stable at one point. What would you suggest to do now? I think we've done all we could short of the following: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. b) package.mask 3.5.5 with a big, fat warning and let the users decide. Same drawbacks as a). ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. c) Drop 3.5.5 from the tree. The cleanest but most radical solution. If mips' users want KDE, they would have to bug (sic!) the mips team. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. Actually if they dump kde-3.5.5 and anything depending on it, then they don't break the tree and everyone is happy, no? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 9 Jan 2008 10:07:31 -0800 Alec Warner [EMAIL PROTECTED] wrote: Actually if they dump kde-3.5.5 and anything depending on it, then they don't break the tree and everyone is happy, no? Everyone except the users, who end up with pages and pages of horrible Portage output... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 17:27:52 + Roy Marples [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote: 3.5.5 was good enough to be keyworded stable at one point. Thus, it can't be *that* bad. So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote: So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 9 Jan 2008 19:29:53 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote: So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, so yes. Forcing a mass upgrade is rarely if ever the correct solution to any security issue. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 09 Jan 2008 20:50:38 +0200 Petteri Räty [EMAIL PROTECTED] wrote: So you just ignore for example my post about CIA activity for the mips team? That falls into the highly misleading category. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh kirjoitti: On Tue, 08 Jan 2008 18:59:29 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. So you just ignore for example my post about CIA activity for the mips team? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 9 Jan 2008 20:06:00 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote: Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, So far so good. If users postpone it, that's entirely their responsibility. It's all very well to say that, but which do you care about? Covering your ass and claiming that you have a secure distribution, or the security of end user systems? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wednesday 09 January 2008 18:16:24 Ciaran McCreesh wrote: On Wed, 09 Jan 2008 17:27:52 + Roy Marples [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote: 3.5.5 was good enough to be keyworded stable at one point. Thus, it can't be *that* bad. So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. Lets say that there's just 3.5.5 and 3.5.8 in the tree. 3.5.5 is keyworded stable mips 3.5.8 doesn't have the mips keyword because it's horribly broken on mips A security flaw is discovered in 3.5.5, the solution is to upgrade to 3.5.8. This flaw involves code that has radically changed from 3.5.5 to 3.5.8. For the sake of argument say it will take 1 month of time for anyone to create a patch for 3.5.5 that fixes the flaw OR makes 3.5.8 magically work on mips. During this month, what do you propose happens to the end user? The choices are 1) Carry on as we are, user is blissfully unaware of security flaw and doesn't have time to read GLSA's, etc has he's busy with real life thereby giving Gentoo the reputation of shipping insecure software. 2) Force the user to spend a few minutes adding 3.5.5 to a package.unmask, thereby acknowledging the security flaw but by his own choice keeping the highly insecure software. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote: Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, So far so good. If users postpone it, that's entirely their responsibility. so yes. That's not so good, though, and where we really disagree. Thanks for the straight answer, though. In my book, it's not acceptable to not do one's job properly and by that force others to do more. You basically told me the same when I suggested likewise measures against mips. :-) The only difference being that we supported KDE 3.5.5 for a long time and gave mips months to get up to speed again. Forcing a mass upgrade is rarely if ever the correct solution to any security issue. I absolutely agree. This, IMO, is such a case, though. -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. Can somebody clarify to me why would it cause this? Maybe I just miss something. VB -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh a écrit : On Wed, 9 Jan 2008 20:06:00 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote: Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, So far so good. If users postpone it, that's entirely their responsibility. It's all very well to say that, but which do you care about? Covering your ass and claiming that you have a secure distribution, or the security of end user systems? And what's the point in caring about the security of users systems, when some of them don't care themselves in the first place? Remember, Gentoo is all about choices. If users choose to skip security updates, it's up to them and there's nothing you can do to change it. When their boxes get rooted due to unpatched vulnerabilities, maybe they'll change their mind. Ok, I admit that a few dumbasses will claim that Gentoo sucks and switch to another distro instead, but hey, that's just the way it is. - -- Pierre-Yves Rofes Gentoo Linux Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHhSS/uhJ+ozIKI5gRAgJdAJjymZUrjZfg06W2TMohYZx3FSwsAJ9i4JD/ YZRXDJv/bZWzMXePfuP/Kg== =SFc9 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 14:44 +, Ciaran McCreesh wrote: We want the Council to do something about this issue. You can deny the issue all that you want or try to deflect conversation from the actual issue, but your opinion isn't very important to the much of the current developer pool, seeing as how it doesn't affect you in any way, having been thrown from the project, and all. Ah, so now what matters is who says something, not whether or not it's true. Well, when a non-developer who was thrown out of the project because his attitude and approach was unwanted points out something and makes statements as if he actually were still involved in the process of maintaining packages or working on an architecture team and is unable to get others to agree with him and insists that there isn't a problem but is unable to back it up, then yes, it definitely does matter. I'm just making sure that people are aware of the situation, as you like to portray yourself as important to the Gentoo project, when the project has deemed you as not important and forcibly removed you. Thanks for playing, but you fail. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: And why does repoman do that? Oh. Yeah. Because people with an attitude like yours think that the correct way to fix a repoman message is to start nuking arch keywords, ignoring what it does to the rest of the tree. Dropping keywords works perfectly to have repoman quit complaining, you just have to do a recursive dropping on the rdeps of this package. Perhaps because the people maintaining those archs have better things to do that deal with the same silly ill-thought-out arguments every three months. cia/cvs commits ml says something different, gentoo wise at least. I mean, if vapier can maintain arm/sh/s390, by himself, to a better degree than the mips *TEAM* can do, that should be an indication of a problem. That's an interesting assertion. Can you back it up? Feel free to run imlate scripts and come up with some numbers. Note that I hate whining and I love get solutions. MOST of the packages runs fine if they build fine, MOST of the endian-issues or the 64bit-issues got caught by ppc and amd64 and there aren't that many right now. Ugly arch specific codepath could be present, but, as I said, usually you catch those breaking on gcc. So having some way to test if the package builds (cross toolchain) and if the package at least runs (qemu) IS something that should let small arches with large tree coverage improve a bit. Otherwise you can just reduce the tree coverage. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 15:11 +, Ciaran McCreesh wrote: Heck, most of the repoman messages people are moaning about are caused by developers doing exactly this. No, most of the ones we're complaining about have nothing to do with KEYWORDS, at all, and everything to do with changes to policy and such that have been enacted since the ebuild was last touched. See, repoman doesn't care if you're just making a KEYWORD change or if you're making coding changes to an ebuild. It still will fail if something fails a QA check, even if the failure is on an ebuild you're not touching. As such, it is a serious pain in the ass for architecture teams and developers who are *not* slacking when one particular architecture only has ebuilds that are ancient marked stable. It increases the support burden for *EVERYONE* else to keep this one architecture's stable tree as it currently sits. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:56 +0100, Jan Kundrát wrote: Chris Gianelloni wrote: I have foo 1.0, which is mips. There is foo 2.0, which is stable everywhere else. The foo 1.0 ebuild does not conform to current ebuild standards. I want to commit changes to foo 2.0, and repoman won't allow me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo 1.0, because it's been EOL for 2 years Why don't fix repoman not to scream about such issues, then? What, have repoman complain only about problems in ebuilds that have been changed unless someone does repoman full ? Honestly, that coupled with dropping all KEYWORDS except for the arch in question (in other words, marking something KEYWORDS=mips and then ignoring it, as a maintainer) would be enough to keep package maintainers and other architecture teams from having to deal with the crap left all over the tree due to slacker arches. Of course, tree quality would probably go down even more, since these QA issues would likely never be fixed on said architectures, but who really cares, anyway. The support burden gets lain on the people who are slacking, and not on the package maintainers or other architecture teams. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:11 +, Ciaran McCreesh wrote: On Wed, 9 Jan 2008 10:07:31 -0800 Alec Warner [EMAIL PROTECTED] wrote: Actually if they dump kde-3.5.5 and anything depending on it, then they don't break the tree and everyone is happy, no? Everyone except the users, who end up with pages and pages of horrible Portage output... What, all six of them? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:45 +, Ciaran McCreesh wrote: On Wed, 9 Jan 2008 19:29:53 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote: So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, so yes. Forcing a mass upgrade is rarely if ever the correct solution to any security issue. This is why I find it funny that people even bother to listen to Ciaran, at all. All he cares about is his little pet projects/teams and doesn't care if it increases workload for everybody else. I mean, where would Gentoo be if not for our support of mips? Oh dear, we'd definitely be nowhere near as popular... *cough* -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 20:50 +0200, Petteri Räty wrote: Ciaran McCreesh kirjoitti: On Tue, 08 Jan 2008 18:59:29 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. So you just ignore for example my post about CIA activity for the mips team? Of course, it is common practice to ignore any factual data that supports the opposing side of a discussion. This is Gentoo, man! Where've you been? :P -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:56 +, Ciaran McCreesh wrote: On Wed, 09 Jan 2008 20:50:38 +0200 Petteri Räty [EMAIL PROTECTED] wrote: So you just ignore for example my post about CIA activity for the mips team? That falls into the highly misleading category. Yes, hard numbers are always misleading, especially when they show that the entire team is barely active, at all, and only one of those people is doing *any* mips work. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 20:45 +0100, Vlastimil Babka wrote: Ciaran McCreesh wrote: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. Can somebody clarify to me why would it cause this? Maybe I just miss something. He's making the assumption that this sort of thing would be done improperly and would cause other developers issues. I went and created a tiny script[1] to change mips KEYWORDS to ~mips in the tree, and created a patch[2] against the current CVS tree. Were the Council to choose this course of action, the work is mostly done. [1] http://dev.gentoo.org/~wolf31o2/killmips.sh [2] http://dev.gentoo.org/~wolf31o2/mips_to_testing.patch -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 2008-01-05 at 04:32 +, Ciaran McCreesh wrote: On Fri, 04 Jan 2008 20:20:18 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers ...and how exactly are hundreds of developers and thousands of users being held back? So far as I can see, in cases where anyone really is being held back, the arch teams are quite happy to prioritise -- the people who go around moaning about 'slacker archs' rarely if ever actually have anything holding them back. If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. It happened several times during the 2007.1 release cycle. Of course, I don't feel like wasting my time searching bugs to justify myself to you, so if you're interested, feel free to search on your own. Pretending it doesn't happen doesn't make it go away. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:34 +, Ciaran McCreesh wrote: Ok, so explain: * How perpetually open bugs are a maintenance burden. They don't generate emails and they don't require any work on the maintainer's part. Is the mere fact that they show up in queries all you're concerned about, and if so, have you considered either adapting your queries or requesting a special keyword to make such bugs easier to filter? I have foo 1.0, which is mips. There is foo 2.0, which is stable everywhere else. The foo 1.0 ebuild does not conform to current ebuild standards. I want to commit changes to foo 2.0, and repoman won't allow me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo 1.0, because it's been EOL for 2 years and I've had an open bug for mips to test the newer version for 2 years. I've asked several mips team developers, who all give me the same we don't have enough manpower/horsepower to test that right now excuse. * How unmaintained ebuilds are a maintenance burden. Doesn't that contradict itself? When repoman keeps me from being able to commit due to an ebuild that remains in the tree only for an architecture hardly anyone uses or cares about, that affects me. Now, I know that you're just being your usual self-absorbed argumentative self and I likely shouldn't feed you, but I thought that answering this might clear it up for the people who don't understand this as well as you do. This is especially true since you've been pretty much the main proponent for keeping things as they are with these slack arches. I mean, if vapier can maintain arm/sh/s390, by himself, to a better degree than the mips *TEAM* can do, that should be an indication of a problem. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:35 +, Ciaran McCreesh wrote: On Sun, 06 Jan 2008 14:09:24 +0100 Matthias Langer [EMAIL PROTECTED] wrote: This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? I think you'd need a much larger sample than one to get any meaningful answer there (and it might be worth doing it across all other archs too, to find out whether mips is in any way anomalous). Are there even enough users to get a larger sample? Other than the like 3 devs still working on mips, I thought you were the only actual user. I mean, I've watched things in system get broken on mips and nobody even notices for several weeks. There simply can't be that many people who actually care if nobody even notices when *system* breaks. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 11:36 -0600, Ryan Hill wrote: that has both sides happy here, but that won't happen if you don't admit there's a problem. He doesn't have to admit anything. He is neither an ebuild maintainer nor an arch team developer. Basically, his opinion is useless in this case, as *his* work flow is not affected. As such, I think we can simply just ignore him. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Tue, 08 Jan 2008 14:04:49 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: I have foo 1.0, which is mips. There is foo 2.0, which is stable everywhere else. The foo 1.0 ebuild does not conform to current ebuild standards. I want to commit changes to foo 2.0, and repoman won't allow me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo 1.0, because it's been EOL for 2 years and I've had an open bug for mips to test the newer version for 2 years. I've asked several mips team developers, who all give me the same we don't have enough manpower/horsepower to test that right now excuse. You know what by far the largest cause of repoman not allowing you to commit because of older versions is? Developers screwing up keywords because they don't care about certain archs. Things don't mysteriously break on their own... * How unmaintained ebuilds are a maintenance burden. Doesn't that contradict itself? When repoman keeps me from being able to commit due to an ebuild that remains in the tree only for an architecture hardly anyone uses or cares about, that affects me. And why does repoman do that? Oh. Yeah. Because people with an attitude like yours think that the correct way to fix a repoman message is to start nuking arch keywords, ignoring what it does to the rest of the tree. This is especially true since you've been pretty much the main proponent for keeping things as they are with these slack arches. Perhaps because the people maintaining those archs have better things to do that deal with the same silly ill-thought-out arguments every three months. I mean, if vapier can maintain arm/sh/s390, by himself, to a better degree than the mips *TEAM* can do, that should be an indication of a problem. That's an interesting assertion. Can you back it up? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Tue, 08 Jan 2008 18:38:07 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 02:17 +, Ciaran McCreesh wrote: Oh. Yeah. Because people with an attitude like yours think that the correct way to fix a repoman message is to start nuking arch keywords, ignoring what it does to the rest of the tree. ...for the architecture in question which is proving incapable of keeping up with the state of the tree as it is... Sorry, you fail. Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 02:47 +, Ciaran McCreesh wrote: On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. Actually, nobody ever said anything about things that magically break. It's more the things like ebuilds with bad code that can't really be changed without a revision bump, which would also require the arch team in question to ACTUALLY DO SOMETHING to make stable. Seriously, your thinly-veiled attempts at deflecting the conversation to something that supports your pithy points is laughable. The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. We want the Council to do something about this issue. You can deny the issue all that you want or try to deflect conversation from the actual issue, but your opinion isn't very important to the much of the current developer pool, seeing as how it doesn't affect you in any way, having been thrown from the project, and all. Now, if you have something possibly constructive to add to this conversation, as a user, feel free, but don't pretend like you're still a member of the mips team. You're not. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 02:47 +, Ciaran McCreesh wrote: On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. Software that is not maintained is known to fail after some time; not because the software changes, but the environment the software has to interact with - but i guess you know that very well. Really, this discussion is completely pointless unless some mips users/developers join in - or aren't there any at all? Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On 1/8/08, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 08 Jan 2008 18:38:07 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 02:17 +, Ciaran McCreesh wrote: Oh. Yeah. Because people with an attitude like yours think that the correct way to fix a repoman message is to start nuking arch keywords, ignoring what it does to the rest of the tree. ...for the architecture in question which is proving incapable of keeping up with the state of the tree as it is... Sorry, you fail. Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 09:12 +, Ciaran McCreesh wrote: On Sun, 6 Jan 2008 10:08:47 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: No. What he meant and doesn't dare to say is you didn't ask, but demanded, in your usual dry and pesky I'm a spoiled 6-year old tone. And this as usual results in people ignoring you. People aren't as stupid as you think they are, and they don't want to play this game with you anymore. So don't build a case on the fact that you're not getting answers. Someday you'll understand this. Oh, and council members too aren't as stupid as you think they are. If they decide to discuss this, one of their first steps will surely be to try and evaluate what the current situation is. If I were a council member I'd probably feel offended by such condescension from your part. Ah, so this is what you consider to be solid technical reasoning, is it? You certainly present a compelling case, but probably not for the position you were trying to... This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 06 Jan 2008 14:09:24 +0100 Matthias Langer [EMAIL PROTECTED] wrote: This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? I think you'd need a much larger sample than one to get any meaningful answer there (and it might be worth doing it across all other archs too, to find out whether mips is in any way anomalous). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Christian Faulhammer kirjoitti: Hi, Ciaran McCreesh [EMAIL PROTECTED]: On Mon, 7 Jan 2008 00:35:41 +0100 Christian Faulhammer [EMAIL PROTECTED] wrote: URL:http://tinyurl.com/ypoxyg is a list of closed security bugs where mips is still cced. 163 is the total number, where surely some duplicates can be found (PHP, Mozilla products), but we can assume that quite an extensive number of packages which are vulnerable stay still in the tree. And how many of those have been fixed on mips without the Cc: being removed? How many more of those would have been fixed had the bug not been closed off? As you are so interested in those numbers, I humbly leave it to you to investigate in depth because I have to run a business. A quick check on the 15 newest bugs showed exactly 1 package where mips was not lagging behind, where out of these only 2 are X applications. The bugs reach back until mid-November 2007 (CC date for arches). For the sake of fairness I took 15 bugs in a row from 17 and greater. Where mips lagging behind in 4 packages (from April 2007, 1 X application), 2 packages where mips has been dropped completely (MySQL 5 e.g.). V-Li Also let's see the CIA activity of the MIPS team for last month: kumba: 3 commits cristel: 0 commits iluxa: 0 commits peitolm: 1 commit psi29: 0 commits rbrown: 26 commits (None of the commits listed on the page reference mips) redhatter: 6 commits (Finally some commits mentioning mips) spb: 1 commit From this I would say the mips team is pretty much inactive. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:35 +, Ciaran McCreesh wrote: On Sun, 06 Jan 2008 14:09:24 +0100 Matthias Langer [EMAIL PROTECTED] wrote: This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? I think you'd need a much larger sample than one to get any meaningful answer there (and it might be worth doing it across all other archs too, to find out whether mips is in any way anomalous). Right, but if everyone I ask gives me an answer like this, it will take quite a while before we have even two opinions... As you are engaged in this discussion very heavily, I thought that maybe you are a occasional MIPS user, that could point out, that for example removing stable keywords for all MIPS packages, would have a quite negative impact for most MIPS boxes. The thing that really bothers me about this discussion is, that there seems to be almost no input from the people actually affected (users and developers), which makes the whole thing a bit pointless, unless it turns out that exactly this is the problem, in which case MIPS support may be removed entirely without doing any harm. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 04:32:33 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 04 Jan 2008 20:20:18 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers ...and how exactly are hundreds of developers and thousands of users being held back? So far as I can see, in cases where anyone really is being held back, the arch teams are quite happy to prioritise -- the people who go around moaning about 'slacker archs' rarely if ever actually have anything holding them back. If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. No need to talk about 'slacker archs' since we are REALLY talking about a 'slacker arch' called mips. I've given up hope long time ago, leaving ebuilds behind with KEYWORDS=mips since opening bugs seems useless and maintaining them is too much work (the target of stabilization or keywording changes many times before the bug is finally touched) Mainly, talking about categories (yes, categories, no need to mention single ebuilds at this point) xfce-* and media-* here. IIRC, paludis has the imlate script you can use. - drac -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. Why? You aren't the person I or anyone else has to make a case to. In fact, I never would have mailed the list about this to prevent this very type of potentially-out-of-control discussion from occurring, except that the e-mail from Mike said that discussion topics needed to be sent to the list. We currently get rid of packages that are unmaintained or are old enough that they pose technical problems for developers with today's tools. I see no difference in establishing some similar kinds criteria for arch team keywords (which I'm not even asking for. I'm simply asking for dialogue to determine what kinds of criteria would be appropriate, if any). Similarly, what would the Gentoo policy be if at some time in the future an arch team had no members? What if it had two members, but they were unable to keep up with stabilization requests and were running 6-12 months behind? Sorry, there isn't anybody who can mark that stable, but we're hoping to get someone on the team this year isn't a valid answer in my book. I have no idea what the process is to add an officially support arch to the tree, but certainly it's more than just one guy making a few commits. There's some process that has to be gone through, right? Well, there also needs to be an exit strategy for when lack of interest in maintenance no longer means that arch should be supported. But right now, all I'm asking for it when it's appropriate for an ebuild maintainer to not have to spend any more time waiting for the arch team to respond to requests. If you believe that number is 1 billion days, fine. Those of us who have faced the issue and disagree can also make our opinions heard to the council, and let them decide what should be done, again, if anything. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Chris Gianelloni wrote: This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved once and for all and things can resume normal operation. This thread so far spawned lots of reply from an external contributor making the point of keeping stale ebuilds around and 4 developers against the idea proposing different solutions ranging from force update pending some remote testing to remove the stable keyword for such arches. Anything other suggestions? lu PS: has anybody checked how viable is now qemu-system ? -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 09:03:43 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. Why? You aren't the person I or anyone else has to make a case to. In fact, I never would have mailed the list about this to prevent this very type of potentially-out-of-control discussion from occurring, except that the e-mail from Mike said that discussion topics needed to be sent to the list. Ah, so you'd like the Council to jump to some arbitrary decision, rather than hearing specific examples and evidence from all involved? How will providing specific examples of how people are being held up not be beneficial to the decision-making process? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 12:47:51 +0200 Samuli Suominen [EMAIL PROTECTED] wrote: Mainly, talking about categories (yes, categories, no need to mention single ebuilds at this point) xfce-* and media-* here. So nothing that's a priority for the users of those archs then. Now please provide specific examples of how anyone is being held up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ryan Hill wrote: PS: has anybody checked how viable is now qemu-system ? Does it build with GCC 4 yet? not yet... -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 18:19:10 +0100 Luca Barbato [EMAIL PROTECTED] wrote: PS: has anybody checked how viable is now qemu-system ? Testing on qemu isn't anything like testing on real hardware. It's not a reliable or useful way of doing arch work. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Most of the time, when people are moaning about 'slacker' archs, they don't have any kind of decent technical reason for doing so... In cases where such a reason exists, the arch teams are usually quite happy to prioritise if asked. And the point of me asking for the council to talk about this is to set some kind of guidelines for what happens after you've asked X number of times and let Y number of days go by, where X and Y are amounts open for discussion. Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 4 Jan 2008 06:23:11 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: Most of the time, when people are moaning about 'slacker' archs, they don't have any kind of decent technical reason for doing so... In cases where such a reason exists, the arch teams are usually quite happy to prioritise if asked. And the point of me asking for the council to talk about this is to set some kind of guidelines for what happens after you've asked X number of times and let Y number of days go by, where X and Y are amounts open for discussion. X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 4 Jan 2008 17:26:39 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. Well, I'm asking the council to discuss when pretty much irrelevant no longer applies. Compared to the cost of causing yet more arch breakage, which takes huge amounts of time to fix and leads to far more problems, I'd say X and Y should be something like one billion and three billion respectively, except in those rare cases where Z is genuinely significant. Really, I'd like to see some genuine examples of cases where people think they have a legitimate value of Z... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. Well, I'm asking the council to discuss when pretty much irrelevant no longer applies. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 21:02 +, Ciaran McCreesh wrote: X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. ...and the idea is to let the Council decide what level of Z is acceptable. Currently, it appears as if the issue is maintainers being forced to keep abhorrently old versions of packages, including security-vulnerable packages, simply because a security-unsupported architecture hasn't had time to test/update/whatever. This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved once and for all and things can resume normal operation. I know that I, as an ebuild developer, would be much more comfortable/accepting of having to keep around old versions of packages, if the Council had deemed it to be something important enough. No offence to any alternative architectures or their hard-working team members, but there are some times when we have to look at the common good, and forcing maintainers to spend time keeping older ebuilds that are possibly using older ebuild code and other idiosyncrasies versus the current versions for the more mainstream architectures simply might not be worth it for architectures with a very minimal number of users. I've heard some suggestions for removing stable KEYWORDS on arches that aren't security supported. I see this as a possible solution to such issues, since ~arch packages aren't security-supported in the sense of GLSA and such, so why not keep arches which aren't security-supported from having stable KEYWORDS? Of course, this is a global change which affects multiple architectures, so it should be deferred to the Council. I don't really think it requires a large amount of discussion simply because it is simple to see how it would come to a swift stand-still. The arch teams affected will want nothing to change, the package maintainers will want to make things easier on themselves. This is to be expected. We elect the Council for a reason. Making decisions like this is one of them. Let's let them do their job and follow their leadership. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 22:37 +, Ciaran McCreesh wrote: Really, I'd like to see some genuine examples of cases where people think they have a legitimate value of Z... How about we base X Y and Z on the number of verifiable users of said arch? That's just as arbitrary and fits with the normal pink ponies philosophy of pulling complete bullshit out of the air and using it as a justification or argument. Maybe we'll base it on how many months they've been security-supported? No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers, who could do their jobs just as well without stable KEYWORDS, and an nearly as small number of users, just isn't worth it to us all. How many users do you really think breaking some of these arches affects? If the architecture (or its team) is incapable of maintaining stable KEYWORDS in a timely manner, why should we care about them, again? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 04 Jan 2008 20:20:18 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers ...and how exactly are hundreds of developers and thousands of users being held back? So far as I can see, in cases where anyone really is being held back, the arch teams are quite happy to prioritise -- the people who go around moaning about 'slacker archs' rarely if ever actually have anything holding them back. If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 03 Jan 2008 18:40:43 -0600 Ryan Hill [EMAIL PROTECTED] wrote: I have four versions of freetype sitting around that I'd really like to get rid of And what is the cost of you not getting rid of them? Is there any particular reason it matters when it's done? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 03 Jan 2008 19:21:39 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 03 Jan 2008 18:40:43 -0600 Ryan Hill [EMAIL PROTECTED] wrote: I have four versions of freetype sitting around that I'd really like to get rid of And what is the cost of you not getting rid of them? Is there any particular reason it matters when it's done? The general maintenance cost of any ebuild in the tree. If we want to make an external or global change in how the package is built or used, we have to make sure those changes work with all versions in the tree. And do you actually want to make such a change? If you do, give an explanation, and demonstrate why it can't be solved simply by dependencies. Most of the time, when people are moaning about 'slacker' archs, they don't have any kind of decent technical reason for doing so... In cases where such a reason exists, the arch teams are usually quite happy to prioritise if asked. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote: What word to use in place of distribution, when one wants to include the BSDs and other non-distributions as well, other than Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term? Well we could say meta operating system if we wanted to be really stupid, or we could just admit that we don't have to make a bunch of anal terminology nerds happy and continue on using sane naming -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Friday 06 January 2006 09:37, Duncan wrote: Well, for that matter, distribution is considered at least by my *BSD friends, to be a peculiarly Linux term. From their perspective, Linux has 1001 distributions, but they only have the one *BSD they choose to use. That's what we started changing. Gentoo/FreeBSD is by all means a FreeBSD distribution (actually, PC-BSD started this a bit before of us). We didn't fork it to change the base system, we use FreeBSD basesystem and portage, so it's not like others BSD. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp49E4a6O4La.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Lance Albertson wrote: I never meant that each subproject can't have their own goals. They need to have those of course! I was more directed that there isn't a person in charge of all the subprojects just to keep track of them (Not governing them). i.e. if subproject foo is working on adding feature X to portage, then this person could make sure the portage people know that these folks are wanting to add that feature instead of blind siding them. Of course, if we lived in a perfect world, they would go ahead and work together like that. Can you give examples where this has actually been a problem? Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 11:26, Duncan wrote: This man speaks my mind. That's one of the things I'm worried about with the Enterprise Gentoo thing, and why I think it will make a better separate project than part of Gentoo itself. I agree mostly, too. Just that QA has more aspects than cool nifty package x that has bleeding edge dep y, with dep y sitting due to QA concerns, to quote Brian. A QA team can work concurrently to other subprojects of Gentoo, spot testing ebuild quality, checking e.g. for correct dependencies and licenses (I stumpled about four false ones the last few months) and a lot of other things without slowing development down. It's a pity, that we don't have an proactive QA team. The complaints about Gentoo having no direction, sound (at least in my ears) more like Gentoo is not heading in the direction I want to have it. - so, attract developers who work with you on your goals (We don't have enough devs anyways, ~10% unmaintained packages in the tree speak for themselves) within Gentoo. I for one can't say we haven't seen a lot of improvements in different subprojects, just that it takes time. see the history of the Panama canal for instance, but it takes a *LOT* of work Odd comparison, having in mind how much lives it did cost. Carsten pgpqjjrZxhhvD.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote: Patrick Lauer posted [EMAIL PROTECTED], excerpted below, on Mon, 02 Jan 2006 22:52:43 +0100: Lance Albertson wrote: When I say we have a niche we're perfect at, I'm mainly referring to the source-based nature of our OS. There isn't another distro out there that does it as well as us and we should improve on that fact. Let the other distros get better at being binary-based. Why would one prevent the other from happening? Maybe someone finds an elegant way for Binary Gentoo ... should we stop that person because it conflicts with a weird mission statement? I believe that's where the differing opinions begin to come in. Here's mine. I don't believe that Gentoo, /as/ /Gentoo/, will ever be very successful as an Enterprise distribution, and I don't think that it can every be very successful as a binary distribution, either. The things that make us, that is Gentoo, unique, and the best in our area, by definition are the /same/ sort of things that make a relatively poor enterprise or binary distribution. I completely agree with you here. What Gentoo does is make a meta-distribution, that one can utilize to build their own distribution easily. This isn't limited to Linux, either, thanks to Gentoo/Alt. I think that any single direction that we shoot towards will cause friction internally and will reduce productivity, along with leaving certain projects out. We're simply moving in too many directions to have a single direction. The biggest concern that I see here is a lack of communications, really. We don't need direction. We just need some way for people to know who's going where. I think Koon's MetaBug project would be an excellent idea to assist in this. We need a body with some teeth to get things done in a timely manner. We also need enforcement of some sort to ensure projects are active and reporting information on their status. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Chris Gianelloni [EMAIL PROTECTED] said: On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote: I believe that's where the differing opinions begin to come in. Here's mine. I don't believe that Gentoo, /as/ /Gentoo/, will ever be very successful as an Enterprise distribution, and I don't think that it can every be very successful as a binary distribution, either. The things that make us, that is Gentoo, unique, and the best in our area, by definition are the /same/ sort of things that make a relatively poor enterprise or binary distribution. I completely agree with you here. What Gentoo does is make a meta-distribution, that one can utilize to build their own distribution easily. This isn't limited to Linux, either, thanks to Gentoo/Alt. I think that any single direction that we shoot towards will cause friction internally and will reduce productivity, along with leaving certain projects out. We're simply moving in too many directions to have a single direction. +1 Each project has a direction they want to go in, and by setting some sort of global vision we are only going to restrict this. The biggest concern that I see here is a lack of communications, really. We don't need direction. We just need some way for people to know who's going where. I think Koon's MetaBug project would be an excellent idea to assist in this. We need a body with some teeth to get things done in a timely manner. We also need enforcement of some sort to ensure projects are active and reporting information on their status. Sounds good as well. I'd like to see all of the projects/teams saying what their goals are, or what they have done to move towards their goals. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpYgs2YzrATV.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Mark Loeser wrote: Chris Gianelloni [EMAIL PROTECTED] said: On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote: I believe that's where the differing opinions begin to come in. Here's mine. I don't believe that Gentoo, /as/ /Gentoo/, will ever be very successful as an Enterprise distribution, and I don't think that it can every be very successful as a binary distribution, either. The things that make us, that is Gentoo, unique, and the best in our area, by definition are the /same/ sort of things that make a relatively poor enterprise or binary distribution. I completely agree with you here. What Gentoo does is make a meta-distribution, that one can utilize to build their own distribution easily. This isn't limited to Linux, either, thanks to Gentoo/Alt. I think that any single direction that we shoot towards will cause friction internally and will reduce productivity, along with leaving certain projects out. We're simply moving in too many directions to have a single direction. +1 Each project has a direction they want to go in, and by setting some sort of global vision we are only going to restrict this. I never meant that each subproject can't have their own goals. They need to have those of course! I was more directed that there isn't a person in charge of all the subprojects just to keep track of them (Not governing them). i.e. if subproject foo is working on adding feature X to portage, then this person could make sure the portage people know that these folks are wanting to add that feature instead of blind siding them. Of course, if we lived in a perfect world, they would go ahead and work together like that. I'm not stating that we'd want to restrict everyone from doing what they want, just that there's some kind of direction/guidance/overall project manager that keeps track of all these projects. They would keep track of all this and report back to the council/devs/etc. We've gotten to the size that trying to get everyone communicating with everyone is getting difficult. Having someone overseeing these things might help development and make sure everyone is on the same page. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Lance Albertson [EMAIL PROTECTED] said: Mark Loeser wrote: Chris Gianelloni [EMAIL PROTECTED] said: I completely agree with you here. What Gentoo does is make a meta-distribution, that one can utilize to build their own distribution easily. This isn't limited to Linux, either, thanks to Gentoo/Alt. I think that any single direction that we shoot towards will cause friction internally and will reduce productivity, along with leaving certain projects out. We're simply moving in too many directions to have a single direction. +1 Each project has a direction they want to go in, and by setting some sort of global vision we are only going to restrict this. I never meant that each subproject can't have their own goals. They need to have those of course! I was more directed that there isn't a person in charge of all the subprojects just to keep track of them (Not governing them). i.e. if subproject foo is working on adding feature X to portage, then this person could make sure the portage people know that these folks are wanting to add that feature instead of blind siding them. Of course, if we lived in a perfect world, they would go ahead and work together like that. I'm not stating that we'd want to restrict everyone from doing what they want, just that there's some kind of direction/guidance/overall project manager that keeps track of all these projects. They would keep track of all this and report back to the council/devs/etc. So, is this something like Koon's MetaBug thing? (I have no idea what that is besides what Chris just said about it). I just don't want to see someone else telling the subprojects how to run their team, or what goals they should have. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpaPI7LU2DGc.pgp Description: PGP signature
