Re: [gentoo-dev] [GLEP] Bugzilla access for contributors

2006-09-04 Thread Bryan Ãstergaard
On Sun, Sep 03, 2006 at 08:38:19PM -0400, Alec Warner wrote:
 Stefan Schweizer wrote:
  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,
 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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Bryan Ãstergaard
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 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.

Bryan Østergaard
-- mailing list

[gentoo-dev] New Developer: Mart Raudseep (leio)

2006-08-08 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] New Developer: Mart Raudsepp (leio)

2006-08-08 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Resignation

2006-08-03 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

2006-08-03 Thread Bryan Ãstergaard
On Thu, Aug 03, 2006 at 10:46:22AM +0100, Roy Bamford wrote:
 On 2006.08.03 04:27, Lance Albertson wrote:
 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.
 Anyways, I've been trying to keep quiet on this issue and decided I
 could interject here :)
 Lance Albertson [EMAIL PROTECTED]
 Gentoo Infrastructure | Operations Manager
 GPG Public Key:
 Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742
 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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)

2006-07-31 Thread Bryan Ãstergaard
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]
  | 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
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.

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.

-- mailing list

Re: [gentoo-dev] Resignation

2006-07-31 Thread Bryan Ãstergaard
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
See above. I'd love for more users to end up at 5).

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007

2006-07-31 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

[gentoo-dev] New developer: joslwah

2006-07-22 Thread Bryan Ãstergaard
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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-15 Thread Bryan Ãstergaard
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. ;-)
 Wernfried Haas (amne) - amne at gentoo dot org
 Gentoo Forums:
 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.

Bryan Østergaard
-- mailing list

[gentoo-dev] Beware of the portage cache!

2006-07-12 Thread Bryan Ãstergaard
Hi all.

Just a quick reminder that you can only rely on static things in most
top-level variables in ebuilds. See
for details.

For a real world example on how to break the cache see (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.

Bryan Østergaard
-- mailing list

[gentoo-dev] Looking for mozilla maintainers

2006-07-11 Thread Bryan Ãstergaard
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

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).

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July

2006-07-03 Thread Bryan Ãstergaard
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 

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.

Bryan Østergaard

-- mailing list

Re: [gentoo-dev] evolution of x86 stabling procedures

2006-06-05 Thread Bryan Ãstergaard
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 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.

Bryan Østergaard
-- mailing list

Re: [gentoo-dev] New eclass db-use

2006-05-18 Thread Bryan Ãstergaard
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 
 These functions are:
 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.

Bryan Østergaard
-- mailing list