Re: [gentoo-dev] [GLEP] Bugzilla access for contributors
On Sun, Sep 03, 2006 at 08:38:19PM -0400, Alec Warner wrote: Stefan Schweizer wrote: Hi, as requested by multiple devrel members I have written a GLEP to standardize bugzilla access for contributors. It has already been discussed on the devrel mailing list before but I am looking for a wider opinion now. This is also a submission for the new council when it meets. Best regards, Stefan Errr. on -devrel you noted you would just make people take the ebuild quiz and now devrel wants a GLEP again? I'll state the same thing I stated on that list. A. This already happens. I had bugs access for MONTHS before becoming a dev; I got assigned to the portage buggroup and I could edit portage bugs. Anyone already on the portage team could add me, so no nastiness for recruiters (or anyone else). 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. 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. 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. 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. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [GLEP] Bugzilla access for contributors
On Mon, Sep 04, 2006 at 08:35:54AM +0200, Stefan Schweizer wrote: Alec Warner wrote: 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? devrel, plasmaroo, asked me to send this here. And hparker wanted me to send it in, too. Cannot really answer that myself, but obviously there is no working solution without a GLEP. I have two users on queue with their ebuild quiz ready. Show me a way to get access for them if you think that this is unneeded! It's very much needed imo. See other reply where I explain exactly why it's needed. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Bugzilla access for contributors
On Mon, Sep 04, 2006 at 01:54:02PM +0200, Stefan Schweizer wrote: Josh Saddler wrote: Because as much as possible, we need to see something concrete, not maybe an arch tester. We need to have a better definition of what when needed is and who these some people are -- think about it. Do we want a system that works like devship, but only halfway -- like you suggested, just passing the ebuild quiz -- or is something more needed? If it needs to be extended a new GLEP like this one can be written or this one extended. This is only about bugzilla access, nothing more. So no, it is meant to be as non-concrete as possible to allow usage in as many cases as possible. This practically means opening up bugzie to world + dog. Maybe not right now but being so non-concrete as you call it means we can never tell anybody no. All they have to do is calling themselves a contributor. Personally I think this is only going to lead to chaos and I'm not at all frilled by the idea. If this is to go forward it needs to be well-defined - handwaving simply isn't cutting it imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
On Sun, Sep 03, 2006 at 01:57:10PM +0200, Stefan Schweizer wrote: Kevin F. Quinn wrote: I don't think it's a good idea for devs to be putting stuff into the tree without taking responsibility for it. sure I can put myself in there but it will help no one because I cannot test the thing. Furthermore I am actually part of maintainer-needed and commit fixes there. I am also on the maintainer-needed email alias. Also maintainer-needed makes obvious to everyone that they do not have to ask me to fix sth. or take over the package - less communication overhead. Ok, let me see if I can get this straight.. You're saying that maintainer-needed requires less communication overhead compared to ebuilds with maintainers assigned? And that maintainer-needed is therefore better than ebuilds having maintainers. I don't even want to comment on how insane I find that line of thought.. I would expect that either the herd is set appropriately (which means either the committer be a member of the herd, or the herd explicitly agree to be proxy), which is the case here. Maintainer-needed being the waste basket for unmaintained packages in the portage tree that doesn't give me a lot of confidence tbh. or the committer be listed as a maintainer email address along with whoever is being proxied. the committer in this case has no interest in maintaining the thing. And for proxying it does not matter who is proxying. Of course it matters. There's a big difference between a proxy maintainer having to ask a *specific* dev that's proxying his ebuild updates/changes or trying to find a random dev willing to help. Further I believe bugs against such packages should be assigned to the @gentoo.org address (proxy maintainer if there is one, herd otherwise), and CC'ed to the proxied maintainer address. this does not allow the actual maintainer to close the bug and causes a lot of bugspam for a person who does not care about it and should be only contacted in the end to commit fixes/patches/bumps. Shouldn't matter too much as a gentoo dev is still responsible for the package? Nobody shoud be adding stuff to portage without taking responsibility for it. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Mart Raudseep (leio)
Hi all. Mart hails from Estonia and recently joined the Gentoo team to take care of all the wx* stuff. Mart is also working on wx* stuff upstream so all this stuff should be in very good hands now :) Besides traditional Estonian stuff (wikipedia talks about Polka, movies like All my Lenins and Revolutions of Pigs - I gave up researching before it got even weirder :), Mart enjoys playing bridge and optimizing applications. Please welcome Mart to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Mart Raudsepp (leio)
On Wed, Aug 09, 2006 at 12:19:31AM +0300, Mart Raudsepp wrote: I'm a coward... or just find estonian language in computer terminology a bit weird to read. I'd find it weird too :) And my family name is Raudsepp, not Raudseep, where seep in the typo means soap in estonian. Bad bad Bryan. At least I'm clean now :) Heh, sorry about the typo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
On Thu, Aug 03, 2006 at 08:49:31AM +0200, Paul de Vrieze wrote: On Monday 31 July 2006 14:53, Bryan Ãstergaard wrote: On Mon, Jul 31, 2006 at 01:01:20PM +0200, Christian Andreetta wrote: Many users (and I'm both a dev *and* a user) just could do much for Gentoo, but when you're interested in a niche sector package, you *don't have other choices* but 1) an endless wait for an open bug 2) becoming dev for the good of all :-) 3) just use your personal overlay, without sharing the results of your efforts. If the bug in 1) is still open, why updating it with your latest patches/revision bumps? 4) Bash devs to add your ebuild Which one exactly. The point is that it is not on a dev's turf. Many ebuilds sitting in bugzie naturally falls under one herd or another. And if you can't find any developer that should (likely) be maintaining the ebuild you can always ask in the irc channels geared towards users (#gentoo-bugs, #gentoo-dev-help, even #gentoo) or ask on gentoo-dev ML. Lots of ways to get developers attentions imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)
On Thu, Aug 03, 2006 at 10:46:22AM +0100, Roy Bamford wrote: On 2006.08.03 04:27, Lance Albertson wrote: [snip] There's a good chance that a package in the regular tree will link against a package from sunrise, the user will have no idea or forget that they installed that app from sunrise (and the dep exists), and a bug arises. [snip] Anyways, I've been trying to keep quiet on this issue and decided I could interject here :) Cheers- -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net How can that happen ? Devs working on the regular tree should not have any third party overlays installed in the test environment so their ebuild should fail testing because it can't resolve the dependancy lurking in the overlay. What an I missing ? Automatic dependencies. Eg. configure picking up fooapp being installed and enabling support for it without the ebuild explicitly enabling/disabling it. Of course, this would be a bug in the ebuild and should be fixed. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Sun, Jul 30, 2006 at 10:50:31PM -0400, Seemant Kulleen wrote: On Mon, 2006-07-31 at 03:35 +0100, Ciaran McCreesh wrote: On Sun, 30 Jul 2006 22:19:56 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: | we take a risk with this project (like every single other | project) ... if sunrise turns out to suck and cause problems, then we | kill it, no big deal How many more users and developers will have to be lost before it's considered to suck and cause problems? I don't recall users having been lost to the Sunrise. I know of only one developer who left. He left in a huff, in an emotional I'm taking toys, because I don't like them way, without actually raising any issues that he was against, other than a nebulous concern about QA. Show me at least that concern being concrete and we have a starting place. Left in a huff? I'm sorry but I don't think you fully understand the reasons for Brix leaving. After Sunrise was suspended by the council there was a meeting [1] between brix, the sunrise leads (genstef and jokey), christel (representing user relations), myself and one or two other people that showed an interest in the meeting (primarily antarus). At that meeting we tried to figure out what the outstanding issues were and how they could be solved. The outcome of the meeting was that sunrise was to stay as an unofficial project until those issues were solved - I'd like to remind everybody that genstef and jokey agreed on this. Furthermore Brix was to write up his proposal on how to reach the goals of sunrise in a more acceptable way (to him and other people uneasy with the current sunrise project). Before this could even happen genstef took upon himself to tell the council that all outstanding problems have been solved although I haven't seen *any* progress regarding the issues raised on that meeting. I don't know if genstefs memory is just extremely bad or if he purposefully misled the council or something entirely different. That's not really my point either. *This is my point* - Brix sees sunrise in it's current form as a project with great potential to harm Gentoo. He agrees with the goals but not the implementation. And no matter how hard he works at solving the problems he sees genstef, jokey and the council have mostly ignored him by unsuspending the project. I certainly don't blame Brix if he sees no further possibility for correcting those problems and instead chooses to leave the project. Regards, Bryan Østergaard PS. Sorry genstef about picking at you but I don't know how you managed to forget everything that was agreed upon on our meeting. 21:56 @Koon Have all the reasonable objections been addressed ? 21:56 @Koon because you'll never satisfy those who want it dead anyway 21:56 +genstef I hope so. If you can point something more out to me I would love to hear it - our meeting ended up with some concerns that you even agreed to yourself by keeping sunrise unofficial. [1] http://article.gmane.org/gmane.linux.gentoo.devel/39764 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
On Mon, Jul 31, 2006 at 01:01:20PM +0200, Christian Andreetta wrote: Many users (and I'm both a dev *and* a user) just could do much for Gentoo, but when you're interested in a niche sector package, you *don't have other choices* but 1) an endless wait for an open bug 2) becoming dev for the good of all :-) 3) just use your personal overlay, without sharing the results of your efforts. If the bug in 1) is still open, why updating it with your latest patches/revision bumps? 4) Bash devs to add your ebuild 5) Use proxy maintaining (as been suggested several times) Proxy maintaining already happens but some people claims not enough users and devs use this. Personally I'd love to see proxy maintaining advertised which would probably help proxy maintaining take off and offer a way for users to (fairly easy) contribute to the tree and be sure their ebuilds ends up in the tree. Statistically you end up to 3). We just need something to reduce this statistically. See above. I'd love for more users to end up at 5). Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, Jul 31, 2006 at 04:48:42PM -0400, Ned Ludd wrote: kloeri (nice guy but dunno if the council is a proper match) Guess I could do a lot worse than nice guy :) I haven't been part of the council before so it's a bit difficult saying if it's a good fit or not. But I'd certainly do my best to improve Gentoo if I'm elected. I think just about everybody knows my work by now and know that I care deeply about Gentoo. Who knows, maybe I care too much? Or care about the wrong things? Fortunately, that's up to the general developer community to decide just as it should be. Let's hope we get the best possible council and that we'll continue to see Gentoo improving. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: joslwah
Hi all. Joshua Ross (joslway) joined the Gentoo/PPC64 team a couple weeks ago. He'll be helping with release engineering among other things. Joshua has an extensive background in programming and different OSes going all the way back to a hex based machine. We finally managed to convince Joss to leave that machine behind and spend his time working on Gentoo instead :) Besides that Ross gives us this introduction: I'm a research mathematician with interests in linguistics. I'm a Brit., living in China, so am used to utf-8 and CJK issues. I have interests in fonts, from the usage side, as well as displaying multiple languages. I'm currently working on some projection software designed for controlling multiple projectors of differing resolution, potentially with different information. I'm married with two kids, and enjoy playing table-tennis. Welcome to the team Ross. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Tue, Jul 11, 2006 at 06:07:11PM +0200, Wernfried Haas wrote: On Tue, Jul 11, 2006 at 12:50:12PM +0200, Jose Luis Rivero (YosWinK) wrote: I would like to nominate kloeri (Bryan Østergaard) to the council if he has enough free time and if his devrel lead position (where his work is priceless) doesn't block the nomination. Damn, i wanted to do that for a few days already and now you beat me to it. ;-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org I'll be happy to accept the nomination, noting that I can't participate in any kind of appeals board if any devrel decision is ever appealed to the council. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Beware of the portage cache!
Hi all. Just a quick reminder that you can only rely on static things in most top-level variables in ebuilds. See http://devmanual.gentoo.org/general-concepts/portage-cache/index.html for details. For a real world example on how to break the cache see http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/xmltv/ (every version = 0.5.39 relies on XMLTV_OPTS from the environment). The issue is fixed in newer versions and there should already be a bug to stable those newer versions and get rid of the broken versions. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Looking for mozilla maintainers
Hi all. As our old mozilla maintainer was retired a few days ago, we're urgently looking for new maintainers to help with all the mozilla related ebuilds. Stuart Longland (redhatter) kindly offered his assistance with mozilla but to avoid quick burnout we need a couple more persons. Depending on feedback from existing developers I'm probably also going to recruit some new developers for this but I'd like to cover any immediate issues asap. This means that existing ebuild developers are my first priority. Please poke me on irc if you're interested in this (nick is kloeri). Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Mon, Jul 03, 2006 at 08:30:42AM -0400, Mike Frysinger wrote: On Monday 03 July 2006 08:06, Chris Gianelloni wrote: On Sun, 2006-07-02 at 15:26 -0400, Mike Frysinger wrote: What has the existence of Sunrise done for Gentoo? What new packages are now in the tree because of it? What new developers have been recruited because of it? What packages that were previously without maintainers in the tree have found maintainers due to Sunrise? why do any of these matter at this point of time ? you cant kill a project for failing to accomplish any of its goals when it hasnt been given real time yet to actually accomplish them Nor was I trying to in any way. Instead, I don't see any point in discussing something that still needs time to mature. The project hasn't been around long enough to accomplish anything, so again, what is there to discuss? the project was suspended because developers were severely unhappy with it the issues are whether said developers feel all of their grievances have been addressed ... so far it would appear so debating whether the project has/is will accomplish things is out of scope/off topic -mike No, brix is certainly not happy with a overlay like sunrise in any official capacity. This should be clear from the meeting [1] that was held between sunrise (jokey and genstef), userrel (represented by christel), brix and myself. Instead brix suggested a different solution to the problem, namely a proxy maintainer project that everybody seemed to be happy about at the meeting. However, while brix sees the proxy maintainer project as a replacement for the current sunrise project jokey and genstef sees it as a welcome addition. In any case it's not true that everybody is happy with sunrise yet. Regards, Bryan Østergaard 1. http://article.gmane.org/gmane.linux.gentoo.devel/39764 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] evolution of x86 stabling procedures
On Mon, Jun 05, 2006 at 03:00:57PM -0500, Grant Goodyear wrote: I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? The Alpha team does the exact same thing. Requiring devs to file stable bugs even if they can test on alpha hardware themselves or in some cases devs outside the team are allowed to keyword a few packages. I've never put this into system the way the x86 team has, mostly because it's never been much of a problem with few devs having alpha hardware. It's more been a case of me (or other devs from the alpha team) randomly catching other devs in touching our keywords and asking them to abide by our keywording policy. Also, looking at http://devmanual.gentoo.org/archs/index.html you see similar policies for almost all the archs described there. The big difference I think, being how big a hammer arch teams apply and how much attention they pay to the tree regarding their keywords. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thu, May 18, 2006 at 11:48:50AM +0200, Paul de Vrieze wrote:
Hi all,
I have just committed a new eclass to the tree. This eclass has as purpose
to make it easier to use berkeley db. Currently the eclass has two
interesting functions (and some helpers that may or may not be
interesting).
These functions are:
db_includedir
db_libname
Both functions can be used with and without arguments. Without arguments
they will give the best bdb version. With arguments they will loop
through the arguments which are version prefixes (they will be matched
with =sys-libs/db-${1}*
The includedir function returns the include dir of the best matched db
version. The libname function returns the libraryname of the best matched
db. This libraryname has the form db-${ver}, and as such could be just
appended to -l. This means it is not the filename.
Was this discussed on gentoo-dev mailinglist before committing to the
tree? Eclasses are supposed to be discussed on -dev prior to adding them
to the tree to catch any (obvious) mistakes etc.
This is particularly important for eclasses as they can't be removed or
changed in incompatible ways later due to the way portage handles them.
I don't have time to look at it myself right now but I'd still
appreciate posting the code to gentoo-dev and have other devs/users
comment on it.
Regards,
Bryan Østergaard
--
gentoo-dev@gentoo.org mailing list
