Re: [gentoo-dev] ML changes
On 7/12/07, Mike Doty [EMAIL PROTECTED] wrote: All- We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. This will probably remove the need for -core(everything gets leaked out anyway) but that's a path to cross later. We're voting on this next council meeting so if you have input, now would be the time. Consider this my last post ever to gentoo-dev ML if this really goes through. Degrading non-dev contributers like myself to second-class citizens is definitely not going to make me want to contribute anything more. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08
On 7/4/07, Blackace [EMAIL PROTECTED] wrote: I'd like to nominate: avenj See https://bugs.gentoo.org/show_bug.cgi?id=169826. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Bye Gentoo!
It's with a bit of sadness but also a bit of relief that I'm finally retiring from Gentoo. I've been a Gentoo developer for nearly 4 years now and I like to at least pretend that I've made some important contributions to Gentoo during that time. I've had a lot of fun but my frustrations have grown these past several months and I've been entertaining the idea about retiring from Gentoo for probably 6 months now. The past couple months the desire to leave Gentoo have become much stronger and I think it's finally time for me and Gentoo to go our separate ways. I think I've put my fingerprint on Gentoo in quite a few important ways but lately I've come to the realization that I probably can't do any more for Gentoo. No matter how hard I try fighting for what I feel is right we seem to end up with petty fights, flamewars or what I consider even worse - people simply ignore what I'm working hard towards. So I think it's high time that I leave the project and start looking for another project where I can contribute something important and not just try to keep afloat in a project that I seem to be at odds with to an ever increasing degree. I'll try to reach all the projects I'm leaving over the next few days and see if I can pass on my work in a reasonable manner. I probably won't be around much on irc but if you really need to contact me you can do so at [EMAIL PROTECTED] Good luck to all of you and may Gentoo development be as much fun for you as it used to be for me. Best regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Ombudsman project ending
Hi all. The Ombudsman project have grown thinner with some members leaving Gentoo and others not having as much time for it as they used to. Ombudsman and Developer Relations have therefore made a joint decision to end the Ombudsman project and instead move conflict mediation to Developer Relations itself. It is our hope that the decision to close the Ombudsman project and incorporate the mediation function more directly in Developer Relations will help strengthen that part as more people will be able to help on any given case. We've made a few small changes to the Conflict Resolution policy to reflect these changes and make sure that mediation is still an important part of resolving conflicts. The updated policy is available at http://www.gentoo.org/proj/en/devrel/policy.xml. Finally I'd like to thank Grant (g2boojum), Seemant and Michael (marineam) for their great work as Ombudsman and welcome Michael as an official member of Developer Relations conflict resolution team. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Updated mail forwarding policy for retired developers.
Hi all. Just a quick note that I've updated our retirement policy so mail will now be forwarded for a number of months according to how many years you've been a developer. Mail be forwarded for a minimum of one month (unless the retiring developer opts out of it of course) and a maximum of 6 months which should be enough time to get a new email account set up and announce it to all your friends etc. Updated policy is available at http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap3 and should hit our webservers in the next 30-60 minutes. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?
On Sat, May 12, 2007 at 02:27:43PM +0200, Carsten Lohrke wrote: No. LICENSE=GPL-2 some-exception suffices. That said, we suck at our licensing information badly. E.g. every single ebuild linking against OpenSSL has (or at least needs to have) a linking exeption. We don't flag this anywhere. More important, what's with optional dependencies!? We don't support LICENSE=GPL-2 ssl? ( openssl-exception) style LICENSE content at all iirc. Similar for all the patent-encumbered multimedia libs, which can't be distributed as binaries, but are not blocked by some bindist feature flag or so. License follows the same syntax as DEPEND. See http://devmanual.gentoo.org/ebuild-writing/variables/index.html#license. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
On Tue, Apr 24, 2007 at 04:00:42PM -0400, Doug Goldstein wrote: Bryan Østergaard wrote: On Tue, Apr 24, 2007 at 03:49:44PM -0400, Doug Goldstein wrote: Bryan, You and Danny have clearly shown your bias towards paludis take over and support of Gentoo. It's fairly poor taste to FORCE this through during a non-regular meeting for something that paludis is lacking. It's AMAZING how fast you guys are to clamor and fix what you call a QA issue and other problems when we've had issues highlighted for years that the council can't move on. But once it's a possible issue with paludis you guys are quick to respond. Please stop the conspiracy theories. This has nothing to do with paludis and everything to do with what we consider sane in the tree - no matter which package manager you use. And as stated otherwise paludis already supports multiple suffixes even if it's not in a released version yet so it's not an issue for paludis either. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Resignation
On Thu, Apr 19, 2007 at 11:36:09AM +0100, Steve Long wrote: Ciaran McCreesh wrote: On Thu, 19 Apr 2007 10:29:29 +0200 Ioannis Aslanidis [EMAIL PROTECTED] wrote: The real point is that bug-wranglers has lost over 50% of it's effectiveness, again imo. jakub and spanky are the two main guys, and it's not just the loss of jakub's prodigious work-rate, which kept a lot bugs from even reaching devs, but the loss of his influence on QA which is a complete disaster for gentoo. Add +1 to that. snip examples of bad behaviour ...does anyone want another few pages of that kind of thing? Devrel has for once gotten something more or less right. Perhaps people should be thanking them instead. You're ignoring the point made about the amount of bugs Jakub kept away from devs, and the loss of his influence on QA. Quoting examples of his bad bahaviour doesn't change the fact that it is unacceptable for devrel to discuss his case without involving him. Devrel have warned him numerous times to behave properly and stop attacking other devs and users. How is that not involving him? Please note this is not the same as discussing a complaint with the complainant, prior to discussing a dev's behaviour as a team. And no, I don't want pages more; I agree Jakub can be difficult. But at least he is difficult in the cause of achieving something real and positive for gentoo. He's also difficult in marking several valid bugs INVALID, refusing to reopen them and refusing to assign them to the maintainers in several cases. Besides I'd like to remind everybody that spending a lot of time on Gentoo, getting lots of things done, having a tough job etc. doesn't in any way justify bad behaviour. If you're having a tough time and starting to react badly it's time to ask ombudsman, proctors or maybe even devrel to help solve the problem or maybe even take a vacation from Gentoo. Failing to do so is quite often just going to make things worse and ultimately result in suspensions or even forced retirement. And from the comments of others, *he gets the result*. Sure, he gets things done. And it would be much better if he worked together with other devs in a friendly way and stopped getting in the way of maintainers as he has done on many occasions. It's not just me that thinks there haven't been any major b0rkages for nearly a year. Could it be that maybe, just maybe, the development process has actually worked /better/ since you were forcibly retired? That's completely unrelated to the current discussion and there's absolutely no need for such attacks. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resignation
On Tue, Apr 17, 2007 at 09:04:39AM -0500, Jeffrey Gardner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Moc wrote: So Since devrel has been so kind and suspended me, based on our brand new CoC, I don't feel any need to stay on this project any more. I'm therefore resigning from this project. It was recently said that if you had been the 20th or 30th person to get sanctioned, you could have just relaxed and enjoyed the vacation time. But since the CoC is fairly new, and you're the first one (that I can remember) to get suspended, it stings more than it should. Anyway, what I'm trying to say is don't take it so hard...it's not that big a deal. Ok, I'm going to quote something I wrote on the -core mailing list that will hopefully help to clear up this misunderstanding about the decision being based on the new code of conduct. Maybe I shouldn't have mentioned CoC at all since it seems to confuse a few people. We're not suspending jakub based on CoC but based on a long string of bad behaviour. That behaviour certainly violates the code of conduct in many cases but the suspension isn't based on CoC as such but rather the numerous devrel complaints and warnings he's already received. In short, the suspension is based on repeated bad behaviour during a long period of time and despite warning him several times there's been no improvement in his behaviour. That's why we're calling for a timeout with this suspension and hoping that jakub will reconsider his behaviour. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy
On Tue, Apr 17, 2007 at 09:50:26PM +0200, Stefan Schweizer wrote: On 4/17/07, Doug Goldstein [EMAIL PROTECTED] wrote: Bugs that are created for the purpose of getting arches to keyword or stabilize a particular package should initially be assigned to the herd/maintainer of said package with all requested arches being CCed. As a maintainer I have to deal with many stable/keywording requests. Those are bugs that generally hang around in my bugzilla queries and fill my mailbox and I do not have any ability to help there or fix them. Those bugmails constitute spam for my mailbox. It would be cool to implement a [EMAIL PROTECTED] alias just to assign those bugs to so that we maintainers do not need to see them. Are you thereby saying you don't care enough whether the arch teams stable your packages to keep track of it? As a package maintainer I prefer to keep track of the status of any of my keywording bugs. Once the last remaining arch has completed the bug, it is up to them to close it. They know it's up to them to close it since the bug is assigned directly to them. That happens already unless there's still undecided questions on the bug (sometimes users add what might be important questions and it's up to the maintainer to decide how to handle that). In my opinion the last architecture should also remove the old ebuild they have just made obsolete by stabling/keywording the new version, since they commit to the directory anyway. I disagree very much with this sentiment. There's many good reasons for wanting to leave more than one stable version in the tree. If you want the last arch team to remove the ebuild when they're done you can usually just state so in the keywording bug and the arch team will follow the request. Regards, Bryan Østergaard -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals
On Tue, Apr 10, 2007 at 11:34:25PM +0300, Petteri R??ty wrote: As the recent thread showed there is a lot going on in Gentoo land although it doesn't always seem so. I propose we extend project xml to describe current stuff going on in the project in question and their estimated completion date. Then we require this file to be updated monthly. What do you think? I'd probably just cron my updates personally :) Alpha and IA64 would both read More keywording stuff done, yawn every month. Python, apache and mozilla would read something like fixed random bugs. Most other projects I'm involved in would be very much like that I think. The only projects that I'm a member of that it would be interesting to hear from imo is devrel and council and they already give status updates whenever something interesting or important happens. Please note that I'm not against these status updates at all. I just don't think forcing a pre-determined schedule makes much sense. Regards, Bryan Øtergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Wed, Apr 04, 2007 at 01:51:56AM -0400, Mike Frysinger wrote: some topics off the top of my head: - unaddressed CoC issues: - add a mission statement - fix wording to have a positive spin - what else ? We need quite a few more people on the CoC team. One reason being that we want to be sure to cover more timezzones and different cultures. Other reason being to make sure it's not just an old boys club where everybody on the team sees things exactly the same way which could easily undermine any consensus based decisions. - sync Social Contract with Gentoo Foundation statement (external entities) - documentation for mail servers still pending i believe (SPF / reply-to) Kingtaco or robbat2 said they would commit that documentation a good while ago iirc. - PMS: - status update from spb - moving it to Gentoo svn - schedule for getting remaining issues settled - splitting gentoo-dev mailing lists ? -mike Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On Wed, Mar 28, 2007 at 04:49:25PM +0200, Jakub Moc wrote: Daniel Drake napsal(a): Jakub Moc wrote: - The in-kernel drivers seriously are not an equivalent alternative, let alone the preferred one, for stuff like hda-intel or any similar drivers that are under permanent heavy development, at least for now. If hda-intel (or any other driver) from the kernel sources does not work on your system then you should file a bug. Yes, there are drivers under heavily development, this also applies to many other kernel subsystems too. We live with it. It's not as bad as it sounds. It not only doesn't work for me, it doesn't work for majority of people that have responded on this thread. So, something's wrong there I guess? :) Maybe because this thread is a lot more interesting for people that doesn't have working in-kernel drivers? For what it's worth I'm using in-kernel alsa drivers with hda-intel and it's always worked just fine for me. - This is not a duplicated maintenance effort, it's simply needed to have external alsa-drivers ebuilds, and it's needed to have them supported as ALSA upstream won't accept bugs about in-kernel drivers. That's not true. I have supported in-kernel ALSA drivers for a long time and have never seen this be the case. Hmmm, I'm not entirely sure what are you responding to here? What I said was that ALSA upstream won't accept bugs about in-kernel drivers - now how's that related to whether you (or kernel upstream) support them or not? Is it really important who supports it? I think most users would care about their drivers being supported or not instead of who supports them. Additionally - forcing people to upgrade kernel for their sound issues is not a solution for many of them. Kernel upgrades tend to break lots of stuff on every minor version bump (and it's not only external modules that upstream seems to plain hate and ignore mostly). Not exactly what users would like to see when all they are trying to get is working sound. Plus it's lot easier (and faster) to get patches into external drivers than get them accepted into kernel. I don't think anybody is trying to force anything. Daniel have stated that alsa-driver should be supported for a long time. Interestingly in this case, the in-kernel driver is a touch newer than the hda-intel one. It includes support for a few more hardware devices. Again these are only very small differences though. As said, it's not about code being newer or older, it's about having two different branches of the code. One works for someone, the other works for someone else. What's exactly the benefit from trying to kill support for upstream ALSA code and forcing people to use in-kernel drivers (beyond what you see as 'duplicated' maintenance effort)? Users honestly don't care much about 'duplicated' effort, they want a working sound on their boxes. I'll just repeat myself here as you've basically just repeated your claim about forcing people to use in-kernel drivers.. Nobody is forcing anybody to use in-kernel drivers. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On Wed, Mar 28, 2007 at 05:36:57PM +0200, Jakub Moc wrote: Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 Which isn't exactly the same as removing alsa-driver and forcing people to use in-kernel drivers.. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
On Sat, Mar 10, 2007 at 03:55:01PM -0600, Ryan Hill wrote: The people who get all bent out of shape about a simple joke like that are either homosexual themselves (not a bad thing) or homophobes (definitely a bad thing). Not only is this completely off-topic for a technical ml, but one of the most shockingly stupid things one could say in an international public forum. This would get you fired on the spot from any job. Please keep in mind you representing Gentoo here and keep your personal views on political issues to yourself. I'm speaking to everyone here. We have enough trouble getting along without this kind of shit. Actually, that's entirely dependent on (corporate?) culture. I don't think saying something like that would get you fired from any job in Denmark. The worst I could see would be a warning if anybody bothered to complain about it. I agree we have to respect each other but that includes not pushing your culture as a global culture. We most certainly come from vastly different cultures and need to keep that in mind. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] How others handle bad behaviour on mailinglists
On Thu, Mar 08, 2007 at 02:34:02PM +0100, [EMAIL PROTECTED] wrote: Dear List, as Gentoo is not the only project with large mailing lists, others suffer from similar problems. This is an overview on how other (well know) (community driven) projects handle flaming and similar things. Gentoo has an etiquette policy as well at http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=2 for interested people. One thing worth noting is that we've just decided that the policy needs to be updated so hopefully we'll see a new/expanded policy in a few weeks. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] How others handle bad behaviour on mailinglists
On Thu, Mar 08, 2007 at 10:24:29PM +0100, [EMAIL PROTECTED] wrote: One thing worth noting is that we've just decided that the policy needs to be updated so hopefully we'll see a new/expanded policy in a few weeks. Good. Maybe also a link to this netiquette on http://www.gentoo.org/main/en/lists.xml might also be helpfull? I'll try to remember that when updating etiquette policy. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Little respect towards Daniel please
On Mon, Mar 05, 2007 at 02:22:08AM +, Alex Tarkovsky wrote: Bryan Østergaard kloeri at gentoo.org writes: Bryan, instead of always addressing the symptoms by asking people to kindly be quiet or move things elsewhere, why don't you do something more substantive about what ails Gentoo developers? You're head of Developer Relations. That makes you partly responsible for allowing what should only be minor differences of opinion between developers (and ex-developers and users) to balloon out of control until the atmosphere around Gentoo becomes so unpleasant some developers decide it's better to quit than try to stick around and solve problems. Face it, every time that happens you've failed to do your job. By trying to silence parties involved in a disagreement you only force their differences to manifest in less desirble ways. And when that happens, things tend to get really ugly and it inevitably reflects back on Gentoo. I'm not trying to silence anybody. I'm asking people to stop making things worse than they already are. Also, brushing things over to private email and private blogs is not always the answer because the issues behind these disagreements often involve (and just as importantly, affect) more than 2 people. Just because Daniel Robbins might now be taking things over to his private blog doesn't mean you no longer have to deal with the issues he attempted to have a public discussion about. Uhh, I never said anything like that. The only thing I said related to his blog was that whatever he's going to do in the future is off-topic for a gentoo development list if it doesn't involve gentoo development. I think it was quite clear from the context that wasn't the case, so the proper place to tell the world about all the cool things Daniels going to do is his blog imo. Gentoo should provide an official venue where developers (and ex-developers and users) can talk out their disagreements, and under a few plainly spelled-out and easily enforceable guidelines designed to keep the discourse somewhat civil. Somehow a lot of people seems to think banning is the only possible solution. I tend to think that's a horrible idea myself and most of devrel backs me up on that. If people thinks devrel is doing a horrible job they can ask council to do something about it - replacing devrel or whatever they'd think would solve it. But as long as that hasn't happened devrel is going to work on solving conflicts the best possible way according to their experience and ideas. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Little respect towards Daniel please
On Mon, Mar 05, 2007 at 03:46:47AM +0100, Jakub Moc wrote: Bryan Østergaard napsal(a): On Sun, Mar 04, 2007 at 11:31:56PM +, Hubert Mercier wrote: What is more, even if Gentoo is always growing, why are people leaving ? Personal reasons ? No, in fact I read carefully each of the retire mails in the last year : very often people are just fed up with conflicts, tired of people just slacking around, etc.. Are these last counted in growing dev base ? IMHO, Gentoo need a large rethinking of its internal structure, and, what is more, a rethinking of its recruitement process. But I remember that this point has already been discussed ? Please don't base your entire opinion on those very few retirement announcements you've seen. Most devs that retire simply run out of time for gentoo due to real life commitments etc. or move on to other open source projects. Regards, Bryan Østergaard OK, let me get this straight... You are suggesting here that we are not losing enough developers for devrel/userrel to be bothered enough to start caring about WTH is going wrong here? Not at all. But don't bother to read what I actually said. I'm sure that would be way too much effort on your part. Sure, after Flameeyes left we have pam + alsa pretty much unmaintained, we've lost a key KDE + sound apps developer + BSD lead; next we've lost metalgod who was a member of already pretty understaffed Gnome herd, one of 3 members of media-optical herd and sounds apps maintainer as well. Then a developer and founder of this distribution who rejoined just about a week ago ran away, scared when seeing the state of things. That's just for the past month. And you come here to tell us that people shouldn't get confused by these 'very few' retirements, that the sun in still shining nicely and we are recruiting people as always? And that you will continue silently watching the trolls team associated around mips and ciaranm call people fuckheads, idiots and making a gutter of something that's supposed to be a development mailing list? Never said anything like that. Ugh... well done. And you grabbed the chance to completely distort what I'm saying once again. Well done indeed. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On Sun, Mar 04, 2007 at 10:32:40AM -0700, Daniel Robbins wrote: OK. If that's not possible, I'll push for the banned from gentoo development status as it obviously makes sense, will help Gentoo, and will not impact PMS. If Ciaran is sticking around on this list using PMS as a pretext to insult various people and projects, then this is more than acceptable grounds to be banned from gentoo development IMO and thus allow my suggestion to be put into action. Really, I don't see any reason for any party to fight my suggestion, as it would benefit everyone. If people are truly concerned about productivity, then I would expect them to support it. Banning Ciaran *is* going to hurt PMS as he's been asking many questions related to PMS lately on -dev ML and the discussions have generally been very good imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Little respect towards Daniel please
On Sun, Mar 04, 2007 at 01:46:38PM -0700, Daniel Robbins wrote: C'mon, I am not calling you a liar. I just don't always take everything you say at face value. Call it a trust issue. -Daniel On 3/4/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 4 Mar 2007 13:14:14 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: It was helpful to have some things confirmed by people other than Ciaran. So now you're calling me a liar too? If you meant something else by that remark, please explain, because I'm having a very hard time coming up with an interpretation that means anything else. Daniel, please stop top posting. It's a terribly bad habbit that I guess you picked up from the horrible MS Outlook client :P That said, could you both (Daniel + Ciaran) please stop this fight? It's not getting us anywhere at all and just adds to the frustrations many people currently feel. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] forwarding a video
On Sun, Mar 04, 2007 at 11:19:35PM +0100, Piotr Jaroszy??ski wrote: a video sent to out by a good mate http://video.google.com/videoplay?docid=-4216011961522818645 ++ I think recruiters should keep this link in mind. And do what? It's terribly hard to spot poisonous people in advance so recruiters would probably be the least likely devrel group to gain from this imo. Besides, you don't need to be an official developer at all to cause problems as the gentoo community (on purpose) is much wider than just the people with commit access. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Little respect towards Daniel please
On Sun, Mar 04, 2007 at 11:31:56PM +, Hubert Mercier wrote: What is more, even if Gentoo is always growing, why are people leaving ? Personal reasons ? No, in fact I read carefully each of the retire mails in the last year : very often people are just fed up with conflicts, tired of people just slacking around, etc.. Are these last counted in growing dev base ? IMHO, Gentoo need a large rethinking of its internal structure, and, what is more, a rethinking of its recruitement process. But I remember that this point has already been discussed ? Please don't base your entire opinion on those very few retirement announcements you've seen. Most devs that retire simply run out of time for gentoo due to real life commitments etc. or move on to other open source projects. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Wed, Feb 21, 2007 at 05:10:49AM +, George Prowse wrote: Bryan Østergaard wrote: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard if the shoes fit, wear them You're saying I should start kicking devs instead of just asking them to stop personal attacks? :) Policy doesn't really allow that currently unless devs *really* screw up badly in which case policy still disagrees but nobody objects when I kick somebody like that. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 01:00:12PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard mkay, but sometimes is _really_ difficult, missing flameeyes and keep geoman does not make it easyer. Might be dificult but maybe you could explain how it helps to bash geoman? A good advice before sending any mail like that is to take at least 10 minutes break to cool off and then read it again before sending it. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 02:29:32PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 01:00:12PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard mkay, but sometimes is _really_ difficult, missing flameeyes and keep geoman does not make it easyer. Might be dificult but maybe you could explain how it helps to bash geoman? A good advice before sending any mail like that is to take at least 10 minutes break to cool off and then read it again before sending it. Regards, Bryan Østergaard Bashing Stephen Becker for comments like the one you can found at http://bugs.gentoo.org/show_bug.cgi?id=163795#c6; may survive also the 10 minutes break, even a night of sleep, and bashing is not enough. FYI the offence has been reiterated in #c12 still from geoman, and enforced by ciaranm in c#16, same bug, same attitude. I honestly find it offensive to break archs likewise. But while we can all decide to continue to be dicks over this I still completely fail to see how it *helps* solve anything. And I guess we want to solve the problems instead of just continuing the flames, right? So please ignore previous flames and lets focus on the actual problems. Problems like MIPS being behind on some packages and latest stable or testing version getting dropped for archs quite often. That's something I'd like to see people spending their time on fixing instead of just adding fuel to the flames. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 10:54:55AM +0100, Stefan Schweizer wrote: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. That's lame for several different reasons that I'm going to outline below and frankly anybody blowing steam about ~arch keywording the latest version (which ended up as being the goal yesterday) is being extremely silly. Anyway, here's several reasons why it's lame - I'm sure there's even more good reasons but these should suffer: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. C. If (as Diego told me) portage is being too slow regenerating cache because of an extra 300 kde-meta ebuilds in the tree we have to sane options: - C1. Remove kde-meta completely as it's breaking our package manager. - C2. Fix portage immediately or switch to a package manager that works. Now, all of the above is insane as I think everybody can agree so please stop making a big fuss about this. An extra 300 kde-meta ebuilds shouldn't: D. Be in the tree at all unless KDE team thinks it's fun to drop all the ~arch keywords. E. Be a problem for the package manager (or we got bigger problems on our hand which would basically force us to stop adding new packages to the tree until resolved). Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 03:16:06PM +0100, Stefan Schweizer wrote: Alexander Færøy schrieb: It was discussed at the last council meeting... Proposed by jokey. Thanks. Sorry I did not know about it because there was no summary for the last council meeting. From the log that I read now I cannot clearly define an outcome. The (very clear imho) outcome was that it wasn't going to save any bandwidth at all and would increase used diskspace quite a bit. Bandwidth reduction was jokeys primary goal iirc. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 03:13:00PM +0100, Stefan Schweizer wrote: Bryan Østergaard wrote: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). right, we all agree :) B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. every arch team is allowed to keyword kde-meta, just they should not complain about their keywords not being on bumps when they are late. Of course they should complain about dropped keywords. Policy says to keep ~arch keywords when doing bumps unless there's a very good reason not to (like a complete rewrite or whatever). Keyword-ebuild separation allows to clearly show the arch teams that they are responsible and allows the developers not to get into conflict here. It clearly would have avoided the recent conflict. Arch teams already know what they're responsible for - moving metadata about isn't going to change that at all and it most certainly wouldn't fix flameeyes complaint about having an extra 300 ebuilds in the tree because some arch team are late regarding keywording. The ebuilds would *still* need to be in the tree no matter where we store keyword information so it wouldn't solve it at all. The problem is with ebuild developers like me having no means to get arch teams to keyword stuff yet we are responsible if something fails and we get bugs assigned. Many arch team members have repeatedly stated that ebuild maintainers are free to reassign bugs about old versions to them if you've given the arch team reasonable time to keyword a newer version first so I don't think that argument has much merit to it at all. [remove kde-meta talk] Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. yeah. A script for removing all ebuilds that are allowed to be removed by policy would be cool. Sadly I don't have one currently :( I'm all for removing old junk from the tree but I don't think that can be entirely automated - there's lots of reasons that we might want to keep an older package around even when a newer package is keyworded on all archs. Sometimes we need to test against the older version and sometimes we need to allow people a transition period for config changes for example. So I think a tool listing versions that could possibly be removed would be much better than an automated tool just removing it all without further concerns. We can for example also offer x86-only sync trees without all the ebuilds that are only relevant to the other arches. As an arch team member I think that's a horrible idea tbh. I don't want to waste any time on keeping all the changes from various arch trees in sync with my own arch tree. And from an ebuild maintainers point of view I'd like to know that when I fix a bug it's fixed on all archs. Both things would be broken if we seperate the tree imo and we would also drastically increase the space requirements for rsync mirrors which is quite bad. Having to keep 12 (or however many archs we support) portage trees instead of just one on rsync servers doesn't sound like a good idea imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New recruiters lead!
Hi all. Petteri Räty (betelgeuse) is replacing Mike Doty (kingtaco) as recruiters lead and will be leading the team in cooperation with myself. Petteri has been very active ever since he became a recruiter and is also actively trying to keep an eye on new recruits and keep them (and the portage tree) out of harms way. I'm sure many of you appreciate his work so far and I'm looking forward to working with Petteri on improving the recruitment processes. I'd also like to thank Mike for his work as a recruiter and in leading the team - I hope you'll still poke us with new ideas from time to time. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
On Sun, Jan 28, 2007 at 12:02:39PM +0100, Jakub Moc wrote: Alec Warner napsal(a): See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is also invalid'. Thats what we are trying to fix. There's absolutely no package that could be installed via this crappy eclass, already tried to explain about 4 times but you don't listen. Oh well, I give up; go fix the slot, never mind that it's utterly useless. Jakub, please stop making a fool of yourself with your endless rants. Quite a few experienced ebuild developers have already told you why it's not being removed. As such your rants are only wasting time. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Changing the new-dev quizzes
Hi all. Recruiters have been talking about changing our quizzes for a very long time as most of the questions are a bit outdated and the quizzes doesn't cover any new material from the last 2 years approximately. What we'd like to do is make a big pool of questions that we can randomly draw 20 questions from (or some other arbitrary number) and have each recruitee do slightly different quizzes that way. It's my hope that this will: - help cover more areas - avoid the copy/paste syndrom that we're sometimes seeing - help make sure that the mentor spends more than 30 minutes on mentoring (yes, some mentors are fairly bad in this regard) - make it more interesting for recruiters as well as devs mentoring several people (less repetition) But to do all this we need some help from interested parties to create a big pool of questions. To make this possible we've set up a [EMAIL PROTECTED] alias where we can discuss the form of the future quizzes as well as quiz questions. Mike Doty has a few ideas on the application side of things and will write those up later today. But for now interested people should add themselves to the alias (if you're a dev and have access to that) or contact me on irc or by email so I can possibly add you. I'm not only looking for current devs but a strong knowledge of ebuilds, eclasses etc. is required. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] misc/herds.xml file gone.
Hi all. I just killed the misc/herds.xml file in the gentoo CVS repository so that we only have one copy of herds.xml left now. The remaining copy is in xml/htdocs/proj/en/metastructure/herds. See bug 151324 for the discussion leading to this. I also left a misc/herds.old.xml file pointing to the new location. Hopefully there'll be no more confusion about which copy to update now. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Careful when punting old versions
Hi all. Just a quick reminder to be careful not to remove the last stable version of packages on any archs when cleaning out old ebuild. I'm getting rather tired of having to fix dependency issues on both Alpha and IA64 because developers don't pay (enough) attention when cleaning out ebuilds. Spare me the trouble of cleaning up your mess and spare yourself the trouble of me /msg'ing you in a not entirely polite way manner :) Regards, Bryan Oestergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Treecleaner meeting summary
On Sun, Dec 17, 2006 at 07:22:13PM +, Elfyn McBratney wrote: Ciao, The outcome of the meeting is, basically, that we need to be a lot more careful/cautious when it comes to punting packages from the tree. For example, in cases where packages work but the ebuilds themselves do not, we should fixing those up where possible. Same goes for packages that are widely used e.g., XMMS (that one just came into my head, honest!). In addition to this, we'll also be following a process similar to that used by the security team: file a bug (assigned to maintainer-needed with treecleaners on the CC) detailing why exactly package foo should be masked/removed; X yes votes from treecleaner members will result in the package getting package.mask-ed and/or removed from the tree. Thanks, I believe many users (and devs) will be happy to see improved policies regarding package removals. I'm also personally very much looking forward to an official Proxy Maintainers project -proxy maintaining is one of the things I've been advertising in my own small way for a long time now and I've been very happy working with several proxy maintainers the last couple of years. Finally, I hope this can lead to a good discussion about future policies and not concentrate on past package removals and possible mistakes in that regard. We want to look forward and improve the processes. Thanks for the summary and good luck on both projects. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Council meeting log + summary
Here's the log of tonights council meeting. Issues discussed: - Removal of icons from http://www.gentoo.org due to possible licensing issues. The issue ended up being refered to Trustees who decided to remove the icons. - Status of documentation on Reply-To and SPF. This isn't finished yet but is expected do be done soon. - Status on bugstest / bugs.gentoo.org. There's still a couple minor issues that needs to be fixed but Robin Johnson (robbat2) hope we can switch over to bugstest 23 dec. - Short discussion about what's happening in the QA project. Complete log attached. Regards, Bryan Østergaard 20:59 @robbat2 kloeri, Kugelfang, SpanKY, you here? 20:59 vapier moo 20:59 @FlameBook kingtaco? 20:59 vapier how do you rebind a channel in bx to a window ? 20:59 @kloeri yup 21:00 vapier ah here we go 21:00 @FlameBook somebody knows why kingtaco is not here? 21:00 vapier i may pop in and out 21:00 @wolf31o2|mobile nope 21:01 @Kugelfang heya there 21:02 * Kugelfang is now available, too -) 21:02 @FlameBook do we start? 21:02 @robbat2 just missing kingtaco 21:03 @FlameBook yeah pinged him in #-dev 21:03 @Kugelfang oh 21:03 @FlameBook he was around a few mins ago 21:03 @Kugelfang well, he'll pop up eventually i guess :-) 21:04 @FlameBook so let's start with an easy one 21:04 -!- mode/#gentoo-council [+m] by FlameBook 21:05 @FlameBook did you read my mail about icons we have on the site' 21:05 @robbat2 what all is on the agenda 21:05 @FlameBook ? 21:05 @wolf31o2|mobile I did... and I agree that we should probably unlink them from the site until it can be cleared up by the trustees 21:06 @FlameBook trustees never cleared it up in more than one year 21:07 @wolf31o2|mobile until you said something, I'd not heard a thing about it 21:07 @FlameBook the most clear statement we have is that we're not liable unless they demonstrate we broke copyright laws intentionally 21:07 @robbat2 yes, I saw the email. i don't think trustees are going to help - perhaps better to announce that unless the license issues are cleared up, they will be going away 21:07 @wolf31o2|mobile basically, anything that was tasked to the old trustees, the new ones likely know nothing about 21:07 @FlameBook wolf31o2|mobile, I mailed last year about that 21:07 @FlameBook sigh -_- 21:07 -!- mpagano [EMAIL PROTECTED] has quit [Client Quit] 21:07 @kloeri we have new trustees now so I think it'd be worth bringing it up with trustees again 21:08 @wolf31o2|mobile right 21:08 @Kugelfang remove until they have settled? 21:08 @wolf31o2|mobile I would say so 21:08 @Kugelfang nod 21:08 @FlameBook I'd remove them and ask for new artists 21:08 @kloeri they may or may not know about it but a reminder certainly won't hurt a bit 21:08 @wolf31o2|mobile better safe than sorry and all that jazz 21:08 @FlameBook it's impossible to clear them up anyway 21:08 @FlameBook most of them are copied from Windows software 21:08 @Kugelfang vote: remove the icons and let the trustees handle the situation afterwards 21:08 @wolf31o2|mobile right... unless we simply removed any offending ones 21:08 @FlameBook is anybody going to write Microsoft to ask permission to use them? :D 21:08 @wolf31o2|mobile Kugelfang: yes 21:08 @Kugelfang vote: yes 21:08 @kloeri yes 21:09 @robbat2 vote: yes 21:09 @FlameBook Kugelfang, yes, although I'd rather take a definitive approach 21:09 @Kugelfang phone 21:09 @wolf31o2|mobile FlameBook: the definitive approach is they're being removed... if the trustees don't do anything beyond that, they're still removed 21:09 @robbat2 there's voicemail for kingtaco (thanks to solar), so he should be here soon 21:10 @FlameBook wolf31o2|mobile, well, if we wait for trustees, we're waiting to clear up 21:10 @FlameBook if we're just scratching them we're asking new artists to contribute a true Gentoo icon set 21:10 @robbat2 with all of the license issues clear 21:10 @FlameBook right 21:11 @FlameBook a new icon set, either original or derived, with a proper license 21:11 @Kugelfang so your proposal is to remove them permanently? 21:11 @FlameBook I'm not sure how much lila is related to gentoo, but it might as well be asked to made official 21:11 @FlameBook Kugelfang, yes 21:11 @Kugelfang i can live with that :-) 21:13 @Kugelfang so new vote? 21:13 @wolf31o2|mobile on what? 21:13 @Kugelfang remove them permanently 21:13 @FlameBook The Lila theme is a community project, originally created by Daniel G. Taylor and members of the Gentoo Linux community. 21:13 @FlameBook http://www.lila-center.info/doku.php?id=about we might as well consider the idea of making these the suggested one or something 21:14 -!- mode/#gentoo-council [+o vapier] by ChanServ 21:14 @wolf31o2|mobile I would prefer that if we were to have an official icon theme that it at least attempt to match the other themes we have 21:15 @FlameBook wolf31o2|mobile, the current one does not really match anything 21:15 @FlameBook lila at least match the colour 21:15 @wolf31o2|mobile so
Re: [gentoo-dev] http://bugs.gentoo.org/
On Thu, Nov 30, 2006 at 03:34:39PM +0200, Sergey Borodich wrote: Hi, What with http://bugs.gentoo.org/ ? Can anyone fix it ? # date Thu Nov 30 15:31:42 EET 2006 http://bugs.gentoo.org/ Software error: Can't connect to the database. Error: Host 'nuthatch.gentoo.osuosl.org' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' Is your database installed and up and running? Do you havethe correct username and password selected in localconfig? For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. We're waiting for people with admin privs to fix it. It should be back up soon'ish. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] missing metadata.xml
On Thu, Nov 23, 2006 at 02:56:49AM -0800, David Shakaryan wrote: Bryan Østergaard wrote: On Wed, Nov 22, 2006 at 02:08:12PM -0700, Steve Dibb wrote: Hi guys, There are more than a few packages with missing metadata.xml in the portage tree. I've setup my funky little QA website to report on which ones fall in that category, and here is the list right here: http://spaceparanoids.org/gentoo/gpnl/qa.php?q=metadata I've spent the morning fixing up most of them, adding blank metadata.xml to them and assigning [EMAIL PROTECTED] as the main maintainer, which in hindsight was probably not the best approach (my apologies). Anyway, either way, it would be nice to get the few remaining packages cleaned up, and if one of your packages is on that list, please update or create the metadata. I'll still be going through the rest of them and sorting out which ones were last maintained by a dev that is now retired and continue assigning them to maintainer-needed. I think the most important thing about adding empty metadata.xml files with maintainer-needed as maintainer is that it _changes_ the package to be unmaintained by definition (that's what maintainer-needed means after all) and that we can't be sure that's actually true unless we spend a lot of time examining each package and asking potential maintainers if it's unmaintained. I see what you mean here, but asking potential maintainers doesn't seem like too much of a solution, as it would take a lot of time and energy. In my opinion, if the package is actually maintained, then it shouldn't be hard for the maintainer to fix the metadata, adding himself as the maintainer or at least assigning it to a herd. I completely agree that adding metadata.xml files is easy for the maintainers and should be done. What I'm objecting to is randomly adding metadata.xml files to packages without any idea if the added files are actually correct. If you can't solve the problem properly you should probably stop to think about a proper solution instead of just taking the easy (but quite possible wrong) solution. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] missing metadata.xml
On Thu, Nov 23, 2006 at 11:20:16AM +0100, Jakub Moc wrote: Bryan Østergaard napsal(a): I think the most important thing about adding empty metadata.xml files with maintainer-needed as maintainer is that it _changes_ the package to be unmaintained by definition (that's what maintainer-needed means after all) and that we can't be sure that's actually true unless we spend a lot of time examining each package and asking potential maintainers if it's unmaintained. Actually, I don't mind much. There's a developers or two who keep on adding packages without metadata.xml all the time (won't name anyone, I'm pretty sure they'll find themselves here :P). This will either force them to reclaim their packages via fixing the metadata.xml thing or will leave the ebuilds orphaned to m-needed - and then they shouldn't have been added in the first place. Above, I'm not talking about legacy stuff maintained in an ad-hoc manner for ages, but about fairly recent additions to the tree (~1 year or even less). However, even for legacy stuff, nothing is preventing the people from claiming their ebuilds the right way and adding themselves to metadata.xml - will make assigning bugs much easier for me. ;) I not quite as concerned whether your job is easy or not as I am that we don't lie about maintainers in metadata.xml. Wrong metadata.xml files affects a lot more people (devs as well as users) than just bug-wranglers. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] missing metadata.xml
On Wed, Nov 22, 2006 at 02:08:12PM -0700, Steve Dibb wrote: Hi guys, There are more than a few packages with missing metadata.xml in the portage tree. I've setup my funky little QA website to report on which ones fall in that category, and here is the list right here: http://spaceparanoids.org/gentoo/gpnl/qa.php?q=metadata I've spent the morning fixing up most of them, adding blank metadata.xml to them and assigning [EMAIL PROTECTED] as the main maintainer, which in hindsight was probably not the best approach (my apologies). Anyway, either way, it would be nice to get the few remaining packages cleaned up, and if one of your packages is on that list, please update or create the metadata. I'll still be going through the rest of them and sorting out which ones were last maintained by a dev that is now retired and continue assigning them to maintainer-needed. I think the most important thing about adding empty metadata.xml files with maintainer-needed as maintainer is that it _changes_ the package to be unmaintained by definition (that's what maintainer-needed means after all) and that we can't be sure that's actually true unless we spend a lot of time examining each package and asking potential maintainers if it's unmaintained. So while I enjoy getting metadata cleaned up etc. I think it's important to think about exactly what we're doing before fixing up a lot of packages - in this case 300+ packages. You (all devs!) might even want to ask on -dev ML if it's a good idea before touching up a huge number of packages to make sure you don't change things in subtle, unintentional ways. Anyway, I appreciate you spending time on cleaning up the metadata.xml files even if it might not have been the best idea in hindsight. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Council meeting summary for meeting on 20060914
Hi all, here's the complete log from the Council Meeting + a short summary. Summary: All council members was present (Andrew Gaffney (agaffney) proxied for Chris Gianello (wolf31o2)). Agenda was: 1. Reply-to-list 2. SPF 3. QA update / plans 4. Bugzilla status 1. Council decided that there were no need to change mailinglist behaviour regarding reply-to-list. Bryan Østergaard (kloeri) mentioned that a replytolist plugin for thunderbird-2 had just been committed the day before. Bryan will update the handbook to include information on procmail recipes to change reply-to behaviour on an individual basis. Bug 154595 tracks progress of this update. 2. Council decided that Infra needs to document use of third party smtp servers and usage of dev.gentoo.org SMTP server. Bug 154594 tracks this issue. 3. Bryan Østergaard gave a short update on QA team on behalf of Stephen Bennett (spb). Plans currently include: - Documenting EAPI-0 and PMS (Package Manager Standard) - Doing more automated QA checks. - Implementing GLEP 48 (see http://glep.gentoo.org/glep-0048.html) - Working out what each QA team member wants to work on. 4. Robin Johnson (robbat2) gave a quick status update on bugzilla. The load-balanced mysql is working very well now but there's still some webserver tuning that needs to be done. There's no timeframe as such as there might still be unexpected issues cropping up. Open floor discussion: Torsten Veller asked if there was any news on portage tree signing. Robin Johnson said there was no news as he'd spend all his time working on new bugzilla setup and anonymous cvs. Regards, Bryan Østergaard 21:01 @kingtaco|laptop ok, we starting this shindig? 21:01 -!- mode/#gentoo-council [+m] by kingtaco|laptop 21:01 @Kugelfang sure 21:01 @Flameeyes ready to rumble 21:01 @kingtaco|laptop ok, whos the logger this month? 21:01 @kloeri me? 21:01 @Kugelfang i propose kloeri 21:01 @kingtaco|laptop ok 21:01 @kingtaco|laptop done 21:01 @robbat2 ok 21:01 @kingtaco|laptop who's here 21:01 * Kugelfang 21:01 * robbat2 robbat2 21:02 * agaffney raises his hand with his wolf31o2 mask on 21:02 * kingtaco|laptop kingtaco 21:02 * Flameeyes is here and is logging as usual 21:02 @Kugelfang vapier: stop hiding 21:02 * kingtaco|laptop pokes spanky with a stick 21:02 @kloeri heh 21:02 @SpanKY reading books 21:02 @agaffney he was just here :P 21:02 * agaffney throw his copy of Dune at SpanKY 21:02 @kingtaco|laptop ok 21:02 @kingtaco|laptop topics for today 21:03 @Kugelfang so, let's discuss Reply-To and SPF first please 21:03 @kingtaco|laptop 1. spf 21:03 @kingtaco|laptop 2. reply-to 21:03 @kingtaco|laptop 3. QA 21:03 @Kugelfang i'd like to have reply-to first 21:03 @Kugelfang if nobody objects 21:03 @kingtaco|laptop 4. bugs 21:03 @kingtaco|laptop anytthing else? 21:03 @kingtaco|laptop Kugelfang, sure 21:03 @Flameeyes Kugelfang, start then 21:03 @kingtaco|laptop aight 21:04 @kingtaco|laptop Kugelfang, go for it 21:04 @Kugelfang ok, Reply-TO: 21:04 @Kugelfang some people want to switch -core ML to add a reply-to filed to the mail header 21:04 @Kugelfang others just want to make all mailing lists show the same behaviour 21:04 @Kugelfang i say: get a new mail client or use the procmail recipes that wolf posted to gentoo-dev ML 21:04 @kingtaco|laptop my position is that it's been posted for both procmail and maildrop the way for a person to configure it to either preference 21:05 @Kugelfang exactly 21:05 @kingtaco|laptop I don't see any reason to change 21:05 @Kugelfang this is why i want to immediately vote on this 21:05 @kingtaco|laptop anyone else? 21:05 @kloeri I just committed a reply-to-list plugin for thunderbird-2 yesterday 21:05 @kingtaco|laptop and there you go 21:05 @Kugelfang excellent 21:05 @kingtaco|laptop yet another way 21:05 @agaffney it would be nice for all the lists to behave the same, but the behavior can be changed with procmail 21:05 @Flameeyes for me it's fine as it is, if the mail clients aren't good enough, just improve them 21:05 @Kugelfang vote: DonÄ't change reply-to for gentoo-core or any other mailing list 21:05 @agaffney so it's really a non-issue 21:05 @kloeri so we're not touching thunderbird itself but still fixing the client :) 21:05 * Kugelfang votes yes 21:06 * kingtaco|laptop yes 21:06 * kloeri votes yes 21:06 * robbat2 yes 21:06 * Flameeyes yes 21:06 * agaffney yes 21:06 @SpanKY umm clarify dont change 21:06 @Kugelfang SpanKY: you'r elagging 21:06 @Flameeyes SpanKY? 21:06 @kingtaco|laptop SpanKY, no change 21:06 @Kugelfang SpanKY: don't change from what it's currently doing 21:06 @SpanKY dont change existing behavior for any lists 21:06 @kloeri no header munging 21:06 -!- Falco [EMAIL PROTECTED]/developer/falco] has joined #gentoo-council 21:06 @kingtaco|laptop yea 21:06 @Kugelfang precisely 21:06 @SpanKY we're doing header munging now 21:06 @SpanKY for all non-core lists 21:06 @kloeri not on -core 21:07 @kloeri yes 21:07 @Kugelfang correct... 21:07 @Kugelfang i think
[gentoo-dev] Re: [gentoo-core] Council meeting summary for meeting on 20061109
On Thu, Nov 09, 2006 at 10:32:43PM +0100, Bryan Østergaard wrote: Hi all, here's the complete log from the Council Meeting + a short summary. Of course I had to screw up the subject.. It's of course the nov. 9 meeting. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Alexander Færø y (eroyf)
Hi all. This announcement is slightly late but Alex never the less deserves a warm welcome for all the good work I'm sure he'll be doing in the future. Alex have a mysterious norwegian background but lives in Denmark (some people are a bit concerned about that fact as well..). Adding to his dubious background is the facts that he's a teenager and works for User Relations and the Alpha and Mips teams :) Please give Alex a warm welcome. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 08:42:54PM +0100, Jakub Moc wrote: Fernando J. Pereda napsal(a): On Tue, Oct 31, 2006 at 07:12:58PM +0100, Jakub Moc wrote: Oh well, this apparently doesn't go anywhere, slacking is just wonderful, maintainers should just STFU and obey the almighty slacking arches, security is the least of a concern and no priority, not answering a on bug for half a year makes lots of sense and all is fine and dandy. More cruft in the tree for t3h win. Yeah, we are so slackers that we are able to maintain a whole tree of keywords with less than 10 persons and less than 10 machines (alpha example). You probably want a shell account on a mips/alpha/... machine so you can start helping, right? This whole frickin' debate started when vivo mentioned a bug where noone from the concerned arches gave a damn for half a year. Not even uttering a simple we don't care, punt it or we have still an issue with this and are working on it. Then ciaranm came w/ his priorities junk, spb joined to fuel the flame (as always) and then you came horribly offended (for whatever weird reason) about how I'm daring to dictate some arches how they should do their job. OMG how hard is it to post one sentence on such bugs instead of playing a dead horse? Really, stop this nonsense. Yes please stop your friggin nonsense when you have absolutely no idea wtf you're talking about. Arch teams are doing everything they can to keep up with bugs but have to take care of things according to how important they are to the team in question. Please go back to bug-wrangling and let the arch teams do their job without throwing all that garbage at us all the time. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 and ia64 keywords
On Sat, Oct 21, 2006 at 11:04:03AM +0300, Alin Nastac wrote: Please correct me if I'm wrong, but isn't amd64 and ia64 architectures nearly the same? Beside 3dnow/sse instruction sets of course. If so, shouldn't we have the same kewords (amd64 ia64, ~amd64 ~ia64 or none) on every package that don't use 3dnow/sse instructions? I only ask this because I think the arch teams' could be better spent than double-checking the packages. No, they are wildly different architectures. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Leave of Absence
On Sun, Oct 08, 2006 at 12:33:30AM -0400, Alec Warner wrote: I killed my dev box somehow and due to recent meandering thoughts in my head I've decided not to buy replacement parts. This in turn affects my ability to do Gentoo work; so I have decided to take a leave of absence. It's kind of been in my mind for while. Treecleaners, I will talk to you a bit about some thoughts I had. Devrel, this is your notice of my leave greater than 60 days. I will be reading e-mail, but prolly won't be present on IRC often. I'm hoping to finish strong in my last semester at school, the choices for post-graduation are looking like a full time job or JET; if the latter I will probably resign at that point since I know I won't have time to contribute much here anymore. Thanks for the notice, I hope to see you around from time to time. And good luck with graduation and post-graduation. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Proxy maintainers
On Thu, Oct 05, 2006 at 05:08:29PM +0200, Natanael Copa wrote: On Thu, 2006-10-05 at 15:47 +0100, Ciaran McCreesh wrote: On Thu, 05 Oct 2006 16:39:50 +0200 Natanael Copa [EMAIL PROTECTED] wrote: | I'm initially only interested in maintaining packages where I'm the | upstream maintainer as well. Ick. Rarely a good idea. That removes a layer of QA. ok. whatever... so, I have learned alot today. * I can't become a proxy maintainer. (you guys will continue your fight if its a good or bad idea having proxy maintainers and meanwhile nothing will happen) Yes you can. I'm a fan of proxy maintaining and would be happy to proxy commits for you. Please poke me on irc.freenode.net (nick kloeri). * It's a bad idea for me to become a dev since I only want to maintain stuff I know I will be able to maintain. (I cant start small and take more and more packages over time, when/if I feel I'm able to do more) Devs only maintaining one or two packages rarely get the needed experience to maintain a high QA imo. I think proxy maintaining in those cases are a much better idea. That leaves me with the conclution that its best to just continue to run my own local portage tree and submit bugreports once in a while and hope for the best, just like I have always been doing. See above. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Changes in Developer Relations and log of devrel meeting
Hi all. Jon Portnoy (avenj) recently resigned from Developer Relations. In that regard we had a meeting yesterday discussing the various issues from that. The (very) short summary is: 1. We've decided that I'm going to remain as the single devrel lead and that I will appoint assistants if and when needed. 2. There's been some concern that things said in private has been leaked. There's no proof of this happening but everybody was reminded that things said in private really needs to remain private - no matter how innocent it might seem. Entire meeting log is attached to this mail. Regards, Bryan Østergaard 20:07 @kloeri k, everybody seen the agenda? otherwise I've linked to it in /topic 20:08 @fmccor got it 20:08 @kloeri I've called the meeting mostly because of avenj stepping down as devrel lead and the reasons behind that 20:09 * kingtaco|laptop gets popcorn 20:09 @kingtaco|laptop kloeri, btw, when will you retire him? 20:09 @kloeri so the first item is whether we should elect a new lead or just let me stay as the only lead 20:09 @kloeri kingtaco|laptop: who? 20:09 @kingtaco|laptop avenj 20:10 @kloeri when he's been inactive long enough according to policy or if he announces his retirement himself.. 20:11 @christel to my knowledge he's not resigning from gentoo, just stepping down as devrel lead no? 20:11 @kloeri he's stepping down as devrel lead, not retiring :) 20:11 @kloeri right 20:11 @kloeri so no plans to retire him unless one of the above conditions suddenly happens 20:11 @kloeri anyway, back to item 1. 20:12 @kingtaco|laptop he does something else? 20:12 @kloeri yes, he's maintaining some packages 20:12 @fmccor What are your preferences --- how are you most comfortable working? 20:12 @kingtaco|laptop oh 20:12 @kingtaco|laptop didn't know that 20:13 @kloeri actually, I've been doing most of the 'leading' and will quite likely continue to do so no matter what we decide to do 20:13 @ribosome I'm back. 20:14 @hparker kloeri: And a mighty fine job of it you do 20:14 @kloeri I don't think it's going to change anything appointing another lead besides me tbh 20:15 @kingtaco|laptop I don't think we need another lead 20:15 @kloeri there's some areas we need to do a better job in (recruiting and being proactive about conflict resolution comes to mind) but none of that is going to be any better from having two leads imo 20:15 @kloeri the simplest solution is just having one lead imo 20:15 @kloeri then you guys always know who to blame for sure :) 20:16 @fmccor Well, it's more effective if we want to get anything done. 20:16 @amne mo 20:16 @amne just to let you guys know i'm here, and reading up on the backlog 20:16 @kloeri not really - I'm always trying to involve people in decisions and I don't think I've ever held anything back unless there was a good reason to do so 20:17 @kloeri and if I'm gone for some days and there's some kind of emergency I'd expect the rest of you to act on it anyway 20:17 @kingtaco|laptop make this easy, anyone feel having another lead is a good thing? 20:17 @fmccor No, I mean there has to be someone actually to make the decision. 20:17 @fmccor Not I 20:18 @hparker Not I 20:18 @kloeri well, looking back to when anarchy blew up decisions was made even though I was sleeping at the time 20:18 @ribosome kloeri: The only positive point I can think of would be if one lead is MIA. 20:18 @kloeri so devrel is perfectly capable of at least containing situations like that without me around 20:19 @kingtaco|laptop sure it is 20:19 @kloeri ribosome: right, but if I'm not around I'd expect whoevers around to make a reasonable decision 20:19 @kingtaco|laptop someone just has to do it 20:19 @fmccor Rather than selecting a second lead, I'd prefer to leave it that kloeri appoint assistants when and if he sees the need. 20:20 @kloeri I don't think that's a problem at all and we could just as easily have that problem with two leads 20:20 @kloeri fmccor: yeah, I think that's going to work better 20:21 @kloeri k, that makes the decision pretty easy I think as nobody seems to object 20:21 @kloeri so what we're going to do is: 20:22 @kloeri 1. I stay as sole lead 20:22 @kloeri 2. I'll appoint assistants whenever I need them 20:22 @kloeri 3. we agree that devrel needs to be agile and act quickly when needed - even if I'm not around 20:23 @amne 1++ 2++ 3++ 20:23 @kloeri that should cover it I think and matches the way things have worked fairly well 20:23 @fmccor There are issues --- the proactiveness you mentioned, but as someone --- christel? , seemant? --- noted, that is something of a communications problem. 20:23 * hparker likes it 20:24 @kloeri and I'm still serious about devrel being able to overrule my decisions in case I go completely insane 20:24 @fmccor We know that can be done. :) 20:24 @kloeri proactiveness is something the council have been discussing a bit lately 20:24 @kloeri we'll officially discuss it on next council meeting 19th oct. 20:25 @kloeri
Re: [gentoo-dev] Changes in Developer Relations and log of devrel meeting
On Wed, Oct 04, 2006 at 04:30:15PM +, Ferris McCormick wrote: A very few discussions must be private: Consider that except for some documentation and policy, our only product is developers and the interactions among them, really. Now, if we were of one mind, there would be no problem, but we are not --- we are individuals with individual approaches and philosophies (even the log which triggered this thread might give some indications of that). Like it or not, this means that some discussions can include references to people which usually are not intended (the references; we can't speak to the history of the people), but in public might be injurious. Obviously I am not going to elaborate, but you can probably imagine situations which can set off such discussions. Now, that said, we (devrel) agree that we do too much in private, and believe it or not, we try to avoid it (I think the log contains some mention of this, too). So with the one (small, actually) exception outlined at length above, I think devrel pretty much agrees with ciaranm's observation; I believe it is our (informal) policy to work in public with -private as the exception. This doesn't mean we always observe said policy, but we are aware of the issues. For example, I refer you to ribosome's observation in the log at 20:57 and kloeri's followup at 20:57 -- 58. Agreed, we should try to keep as much as possible public and ensure as much transparency as possible. That doesn't mean that there can't be things we should keep confidential however. I should emphasize that I am speaking as an individual member of devrel, I am giving my own spin on things, and I do NOT speak here for devrel as a whole. I'm speaking on behalf of devrel because I can :) Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, Oct 04, 2006 at 10:36:37AM -0400, Chris Gianelloni wrote: On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote: What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. I really want to see another checking of the CVS logs (without names, of course) to see just how much work how many developers do. I'd be interested to know if it really is a very few doing most of the work. I would venture to say that it is, and CIA stats seem to agree. I've just blogged about this including a fancy graph of commit activity versus devs. See http://kloeri.livejournal.com for the glory details or wait for it to show up on http://planet.gentoo.org. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sunrise trusted committers with bugzilla access
On Wed, Sep 13, 2006 at 11:39:16PM +0200, Stefan Schweizer wrote: To my fellow Gentoo developers, in the Sunrise project we have some users who are ambitious and cotribute more than a few ebuilds. Those regulars have the possibility to take the ebuild quiz and acquire the title Sunrise trusted committer. Those sunrise committers can use extended bugzilla permissions to edit keywords EBUILD and REQUEST for example in the maintainer-wanted@ and maintainer-needed@ bugzilla region where usually developers clean up litle or have no interest in spending time on. Now I tried to get this done with the [GLEP] Bugzilla access for contributors and I was told it is to undefined and misses out the point of removing access levels again. Also I was told that a GLEP for this is overkill. All this is addressed and working with the current arch testers procedure. The plan is to just treat Sunrise trusted committers the same as arch or herd testers. The difference is that they operate on ebuilds of all flavours that interest themself in the sunrise overlay and not on a certain herd of packages. Neither do they focus on testing for a specific architecture. Just coding is their work, not testing - which explains the difference in the name. Now how do people feel about this approach? As there's been very little, if any, interest from anybody besides Stefan and Recruiters / Developer Relations I'm going to deny the contributor access idea. Recruiters and Developer Relations feels that this is a bad idea, especially seeing how hard it has been to reach any kind of resolution regarding who should get access and how we should solve the problems that I've outlined earlier. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [EMAIL PROTECTED]: New developer William L. Thomson Jr (wltjr)]
Hi all. I'm Slightly late but proud to present another addition to the hard working java team. William has been helping the java team with bug fixes and user support for quite a while and was finally made official a month ago. William hails from CA, USA and also participated in the recent Linux World Conference in San Francisco. Welcome to the team William and good luck with all that evil java stuff :) Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Bugzilla access for contributors
On Tue, Sep 05, 2006 at 10:17:54AM -0700, Joshua Jackson wrote: This is one of those times where I think we all need to take a step back and really look at what we are doing. Gleps were designed for a purpose, and this is not one of them. This is an issue of common sense. We all know or at least I hope so that most users should not be given access to modify bugs. ArchTesters should as they've taken the ebuild quiz and its one of the few things they get as an added benefit for having committed time and effort to earn the trust of the Developer community. As well it might be considered common sense that someone who only works on java as a contributor but helps with patches and advice commonly should be able to do things with java only bugs...as it allows them to further help out as the productive member of the community they are. Not possible for reasons I've described in other replies to the thread. Bugzie privs includes all bugs, not just a subset. As such I really feel that we've gone overboard on what should be considered an enhancement proposal. I would think that for the council as well as the developers would bring common sense to this as well. How exactly does a glep such as this enhance Gentoo as a whole? That should be something we all ask ourselves before we tell someone to draft a glep or consider writing one. Genstef, I'm not poking at you directly, please don't feel assaulted. One thing about this is that genstef won't take a no for an answer. Seeing that we couldn't come to an agreement on this (recruiters/devrel on one side / genstef on the other) and that I still believe this affects all devs I thought it was best for genstef to glep it. That way we could all have our say and it could be publically decided whether it's a good idea or not. You could argue that a normal gentoo-dev discussion could easily serve the same purpose but I fear that genstefs initial mail would have been even more vague than his proprosed glep. Adding a bit of structure to it seemed like a good thing and I'd argue that the small bit of structure have helped keep the discussion on track. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Bugzilla access for contributors
On Tue, Sep 05, 2006 at 07:45:39PM +0200, Jakub Moc wrote: Joshua Jackson wrote: This is one of those times where I think we all need to take a step back and really look at what we are doing. Gleps were designed for a purpose, and this is not one of them. This is an issue of common sense. +1 - this just doesn't make sense. And damn, bugzilla folks don't need ebuild quiz, they need to read bugzilla docs and learn how to effectively search 95% of time (ditto for users filing duplicate/invalid bugs over and over again). If they are not sure, they just assign the bug or leave it to someone else to handle it. And even if they screw up, the user who filed the bug can reopen it anytime. And no, we are *not* opening bugzilla to the whole world plus their dogs - we *always* have an option to deny people those privs - since those are privs, not rights. They are not entitled to them, granting them those privs is solely up to the discretion of Gentoo devs responsible for this. Well, if people don't want to discuss issues such as this I'm quite happy to just deny them in the future. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Bugzilla access for contributors
On Mon, Sep 04, 2006 at 02:59:43PM -0400, Alec Warner wrote: Bryan Ãstergaard wrote: If people are randomly given bugzie privs (or any other privs) this is something we need to fix. And just to make this clear to all - handing out privs is only half the equation and it's already hard enough for recruiters to keep track of devs even though we have well defined procedures etc. for that. Then you better get to patching bugs, since I can hand out gentoo-dev and portage-dev privs on bugs without any problem (I tried it on ferringb to check even; and i took them away right after). This is being fixed now. Gentoo-dev gives access to (some) restricted bugs but doesn't give editbugs privs and portage-dev was somebody hitting a wrong checkbox. Likely a long time ago but a simple mistake never the less and not something that should be considered normal. B. Double bonus is that I don't even see why a GLEP is required? This is a small subset of users using one resource (bugzilla) so perhaps Infra and devrel and you can work out the requisite groups? Why is there all this red tape? Because it's going to affect all devs if people don't need to pass quizzes (or we lower the threshhold substantially) before they can reassign, close, reopen etc. the maintainers bugs. And in this case I'm saying a subset. I'll use Java as an example. Caster is like an awesome Java dude. Lets say I want to give him access to bugs assigned to [EMAIL PROTECTED] Either I (as a member of that herd/project) already have bugs perms to java bugs, or the group doesn't exist and I need to ask JForman to make a java-bugs group and make it so they can do stuff to bugs assigned to [EMAIL PROTECTED] If I'm already in the group I can just delegate the java perms to Caster and be done. Aside from the java bugs, no one else is affected. No other permissions on bugs are granted. The user can only mess with java bugs. This is going to be a maintainence nightmare for several reasons. 1. Very few people can create new bugzilla groups and they'd have to take time out to do that instead of (what I'd consider) more important bugzilla maintainence. 2. You can't delete groups easily (probably can't delete groups at all) as lots of bugzilla data might be related to these groups. End result would be an enormous amounts of groups in a relatively short time if we were to micromanage privs that way. 3. Who's going to clean up all these privs when people turn inactive? Recruiters are already overloaded as is and certainly don't need the extra management burden from this. I'd much rather spend time recruiting new devs and making sure we do a good job at that than trying to keep bugzilla privs somewhat clean. Create a group; come up with a subset of bugs that they can access, add user to group - done. As long as they can't access my bugs; I really shouldn't (and trust me I don't) care. Who's going to admin that? We already have the Arch Tester / Herd Tester projects that defines a proper way of achieving the goal as I see it. Only problem with Herd Testers / Arch Testers compared to genstefs goal is that HTs/ATs deal with packages in the tree while sunrise contributors deal with packages outside the tree. And personally I'd very much like to draw the line somewhere. Genstef made the GLEP extremely vague regarding contributors (on purpose) but guess what? Everybody who files a new bug, submits a fixed ebuild etc. are contributors. So should we just remove all the restrictions now? This is definitely something we need to define before moving on, no matter if the GLEP is eventually denied or accepted. I liked my definition in my earlier mail ;) Generally contributing requires you know someone rather well, such that they proxy your changes into the tree. That's not adequate imo. Lots of people seem genuinely interested in helping only to disappear a few days/weeks later. Part of what the ebuild quiz does is that it tries to make sure people are going to stick around for a while. It doesn't always succeed and neither does recruiters but I still think it's important that he have some defined bar (level?) that you need to pass. C. No real standard on any other fora. I don't need a GLEP to add someone to my project overlay, or grant them voice or ops in my project's IRC channel. I don't need a GLEP to get them subscribed to my mailing list and I don't need a GLEP to add them to (most) project aliases. Why does this require one? Because this is about the entire Gentoo project and affects us all in a very direct way as opposed to random projects. I tried to make it clear above that it doesn't. I hope I succeeded. I still very much believe this affects all of gentoo, especially seen in light of the problems micromanaging bugzie privs would imply. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 05:01:20PM -0500, Daniel Goller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Østergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort wait till you have your required months at gentoo, then you mentor him, if you truly like his work, tell him you have to wait before you can mentor him, iirc 6 months from joining? Yup, 6 months as an ebuild developer is required before you can mentor new ebuild developers. In this case you might consider asking for a mentor on the gentoo-dev mailinglist seeing as [EMAIL PROTECTED] and [EMAIL PROTECTED] have't been able to find a mentor. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
if it should be svn or [insertfavoritescmhere] is another point (that could quickly be solved with a better voting structure, give the power back to the people, simplify things, and then get this issue resolved with a vote) __Problem: QA Policies__ Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. This sounds romantic. However, Gentoo to me isn't 300 people who are all my friends, all working on a common goal. Gentoo, to me, is a bunch of very nice people that share a goal with me, some big mailing lists with flames every now and then and a big mass of people whose work I use and appreciate but who I don't have a f*cking clue about. I don't know what they are like, they work on other things than I do. But that's not a problem at all. rather than having a QA policy that deals with punishment of devs, we should focus on a system where an accidental commit has less impact, if someone makes a commit in another branch, another set of eyes will have a chance to catch it instead of things being in everyone's --sync in ~2 hours, a QA team could still scan the tree for things, but since they find problems in the branches rather than the live tree will not have to worry about what they do until the issue with the unruly dev is resolved, and if the issues are indeed of magnitude, they can go and ask for a developer removal vote, if someone seconds that proposal, all developers can vote, and if the devs who vote think the problem is big and sizable enough, they can vote +1 for his removal, 0 to abstain or -1 if they disagree with the measure asked for by QA Conflict resolution should not be a subproject. It should *not* exist at all. You mean conflicts or conflict solution shouldn't exist at all? If the former, that's unrealistic. If the latter, why not? we shouldn't have an underappreciated overworked entity (not intending to upset the members of said entity, i know there are people behind the alias) that makes the decisions we ask them to make to hear that they did it wrong again (i am sure it gets tiring to hear us say that over and over), instead the developers bring up the issue, if someone seconds that, people vote and the issue gets resolved, one way or another now if the technical issue is brought up by a project lead and does not affect gentoo as a whole, then that project should vote, not all of us who are not affected, if we like it or not I strongly disagree with voting, be it by all developers or just the affected project(s). In the first case the only thing we'll gain is (relatively) quick, random decisions with no strong base in the complaint(s). In the second case, we'll have quick decisions made by obviously biased people - in effect a popularity contest set up to be unfair in advance. Now, as developer relations lead I'm obviously biased but I were of the same opinion even before joining devrel. After devrel have handled a few conflicts I think the current conflict resolution policy leaves a lot to be desired. But moving conflict resolution from devrel to more general voting is the wrong direction. snip rest of mail Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
(this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Why should conflict resolution be a popularity contest? It isn't. It is how a job works. If someone isn't getting along with the team, they are fired. Same principle. You know, I could probably swing a few votes if I wanted to and so could many other devs.. I'd call that a popularity contest as opposed to the currently proposed (see gentoo-devrel ML) conflict resolution policy that have developers interested in conflict resolution working out the solution (as opposed to a large but random selection of developers who could probably care less). Gentoo should be a fun environment. The previous paragraph should be taken as a last resort. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. A new idea proposal should be mailed to a mailinglist (-innovation?) with details of timeline to completion, impact, and who is doing the implementation. If it sounds like a good one, then there is a vote and things proceed. I like progress. Well, I think we all like progress. The council votes on GLEPs; I don't see how extending voting to include _all of Gentoo_ would speed things up or contribute to progress... this is why we elect representatives. Overall I think this would be a regression. The council should not vote on gleps are provide policy. They should be there to handle the money and world-wide problems. The developers should drive innovation; not the council. As in all democracies things get done slowly. We don't need a democracy within Gentoo, just a clear way of creating progress. -Ryan The developers (and many users) *are* driving innovation but we still need some kind of checks and balances in a 300+ group of developers. If we were only 20 developers this would probably come naturally from irc discussions but we're no longer a small, tightly nit group of developers. As part of growing up we (naturally) need more communication between developers before running off with the newest, crazy idea. Gentoo is no longer a playground - we have some 10k+ packages in the tree and 100k+ users at least afaik. We *need* to take our responsibility seriously and not play hazard with all those users/system. So.. What can we do to improve things? There's lots of things that can be improved in my opinion. Developer relations is currently pushing out a new proposed conflict resolution policy for public discussion on the gentoo-devrel ML. It's been out for a couple days already and I have yet to see a single comment on it. Likewise, we're trying to come up with a proposal for improving recruitment / quizzes. I'd love to see people (both users and developers) get involved in these discussions instead of posting general rants on the current state of gentoo. Working on small corners of gentoo can make a big difference (in a short amount of time) and I'm sure I'm not the only one who'd love to see that :) Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 08:35:40PM +0100, Stephen Bennett wrote: On Fri, 28 Apr 2006 12:03:29 -0700 Chris White [EMAIL PROTECTED] wrote: Ok, but most active contributors are people that submit ebuilds to devs and know nothing about the structure/policy/whatever about ebuilds. If you're not a dev, you're probably not going to worry about revision bumps. If you're a dev without alternate arches, you're probably not going to know about how other arches can get screwed by improper pic handling. To conclude, active contributors are generally in a focused environment. The quiz is there to help show them the global way of handling things. That problem can be solved by giving new developers access to a 'sandbox' branch of the tree, and have a more experienced dev merge their changes into the live tree having checked them for sanity. Once they've proved themselves there, they can be given access to the main tree if appropriate. Of course, this relies upon using a VCS for the tree that handles branches and merging sanely, which should be doable with Subversion if the issues it had last time this was tested have been or can be resolved. -- This solution also needs experienced developers with lots of free time on their hands.. And try as I might, I can't think of many people that fits that description. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Gentoo doc developer: Josh Saddler (nightmorph)
Hi all. Another slightly *cough* late announcement from me :) Josh Saddler i(nightmorph) has joined the GDP team to help with our (surprise!) documentation. He's already been an invaluable help updating the Installation Handbook for the 2006.0 release. Josh writes: I'm from San Diego, California, USA, and have lived here all my life. Graduated in May 2005 from Point Loma Nazarene University with a Bachelor of Arts degree in Theatre. I've played piano for more than 16 years, and have been acting and singing for about the same amount of time. I work at Borders, a book/music/video/cafe shop. My wonderful girlfriend and I recently got engaged. I read constantly: mostly sci-fi/fantasy, but also read about art, literature, theatre, string theory, quantum gravitation, astrophysics, Linux, rollercoasters, web technologies, history, kernel operating system internals, etc. You name it. Firm believer in Gnome and Xfce4. Firm believer in rainy days, starry nights, and beaches. I tinker with anything and everything in my spare time. I write poetry, fiction and bits of plays, in about that order. Music follows me wherever I go. Josh should feel right at home in the developer lounge bar with those qualifications :) Please give Josh a hearty welcome to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, Feb 28, 2006 at 12:47:33PM -0500, solar wrote: I forget where I read it but I thought that unicode lead to overflows and was considered a general security risk. I wish I knew where I read that but I'm unable to find it. Any list readers know anything relating to that? It's true that many overflows have been found in unicode aware applications, like the zillion unicode overflows in Internet Explorer for example. But that shouldn't lead to considering unicode a general security risk in my mind even though the apache team uses ascii in the default configuration to protect against bugs in poorly written applications. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] current portage rsnapshot can eat your backups
On Thu, Feb 09, 2006 at 07:08:45AM -0600, Harry Putnam wrote: From: Harry Putnam [EMAIL PROTECTED] Subject: rsnapshot and cp bug Newsgroups: gmane.linux.gentoo.devel Date: Mon, 06 Feb 2006 08:54:02 -0600 Message-ID: [EMAIL PROTECTED] [This message was posted some time ago but failed to show on the list I've resubscribed so hope it goes thru now] === The portage version of rsnapshot 1.2.1 (most recent) has a problem with the newest gnu cp. It can cause rsnapshot to eat all your carefully saved backups. This was discussed on rsnapshot list some time ago: http://sourceforge.net/mailarchive/forum.php?thread_id=8988105forum_id=41320 And more recently when rsnapshot ate all my backups. The newer version 1.2.2 does not have this problem. Maybe it should be hustled into portage. Or certain lines in the exiting version can be edited (explained the cited messages). Look for this message and subject on gmane.comp.sysutils.backup.rsnapshot.general, for some of the discussion From: [EMAIL PROTECTED] Subject: rsnap failure in cp -al leads to deletion of all but one Hourly* Newsgroups: gmane.comp.sysutils.backup.rsnapshot.general, gmane.linux.gentoo.user Cc: gentoo-user@gentoo.org Date: Mon, 19 Dec 2005 08:47:05 -0600 Message-ID: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list Please file a bug on https://bugs.gentoo.org so I can fix this. No, I don't accept bug reports on gentoo-dev ML :) Regards, Bryan Ãstergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: current portage rsnapshot can eat your backups
On Thu, Feb 09, 2006 at 07:23:27AM -0600, Harry Putnam wrote: Please file a bug on https://bugs.gentoo.org so I can fix this. No, I don't accept bug reports on gentoo-dev ML :) Will do but I wanted this to be posted because anyone running rsnapshot might lose some backups. What happens is the cp fails but the rotation still occurs so after a few rotations all the hourlys are deleted. Do you think this should be posted on the `user' list too? Up to you really. I'm too busy atm to bother with anything outside of fixing the issue which I hope to do later today. Regards, Bryan Ãstergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: current portage rsnapshot can eat your backups
On Thu, Feb 09, 2006 at 07:44:06AM -0600, Harry Putnam wrote: Bryan =?utf8?Q?=C3=98stergaard?= [EMAIL PROTECTED] writes: Please file a bug on https://bugs.gentoo.org so I can fix this. No, I don't accept bug reports on gentoo-dev ML :) I'd do this for sure but the bugzilla setup won't let me login. I had to create an account since I've never used bugzilla, the process sent me a password but won't either passwd or uid when I attempt to login with it. The proces never asked me for a uid when creating account. It just asked for my real name and email. So after receiving the passwd I'm not sure what it wants for uid but guessing the `real' name it asked for is it... it was not so stated though. At any rate attempting to log in with the supplied passwd and real name fails ... Bugzilla logins uses your email address + password you specified. Regards, Bryan Ãstergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: hd_brummy
Hi all. Jörg Bornkessel (hd_brummy) hails from Berlin, Germany and joined the Gentoo team about two weeks ago to help with Video Disk Recorder related ebuilds. Outside Gentoo Jörg is self-employed, doing webdesign and fixing computers. Jörg also enjoys spending time with his Harley motorcycle. Please welcome Jörg to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozextension.eclass
On Sun, Dec 25, 2005 at 02:00:19PM -0600, Jory A. Pratt wrote: Once thunderbird 1.5 comes out same will be done for locales support in ebuilds. I am gonna push this eclass rather fast as it benefits so many users/devs. Any objections should be made immediately, 1200 CST Monday Dec. 26, 2005 this will be pushed into the tree. Don't push new eclasses this fast please and especially not during christmas when many people are taking a few days off. Why is it so important that it can't wait a few days so other devs/users gets a chance to look at it? Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New x86 developer: Joshua Jackson
Hi all. Joshua Jackson (tsunam) just joined the x86 arch team and will be helping with stabling packages on x86 and solving x86 related bugs. Joshua have been participating in Bugday for a long time and it's nice to finally see him become a developer. Here's how Joshua introduces himself: Lets see, I have 3 girls. Misha, who is a shih tzu. Nitters, who is a Lhasa Apso. Lastly, is bitzy who is a miniature poodle. Added to the menagerie are 3 fish, 2 bird and a hamster. As far as hobbies, I enjoy reading books about the environment, as its where my interests lie. Yes I'm a tree hugger ;). I also have done some jewelery work with chain mail links. Basically I'm a jack of all trades. Welcome to the team Joshua :) Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
