Re: [gentoo-dev] ML changes

2007-07-12 Thread Bryan Østergaard

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

2007-07-03 Thread Bryan Østergaard

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!

2007-05-30 Thread Bryan Østergaard

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

2007-05-23 Thread Bryan Østergaard
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.

2007-05-22 Thread Bryan Østergaard
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?

2007-05-12 Thread Bryan Østergaard
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

2007-04-24 Thread Bryan Østergaard
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

2007-04-19 Thread Bryan Østergaard
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

2007-04-17 Thread Bryan Østergaard
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

2007-04-17 Thread Bryan Østergaard
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

2007-04-10 Thread Bryan Østergaard
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

2007-04-04 Thread Bryan Østergaard
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

2007-03-28 Thread Bryan Østergaard
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

2007-03-28 Thread Bryan Østergaard
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 ;))

2007-03-10 Thread Bryan Østergaard
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

2007-03-08 Thread Bryan Østergaard
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

2007-03-08 Thread Bryan Østergaard
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

2007-03-05 Thread Bryan Østergaard
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

2007-03-05 Thread Bryan Østergaard
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

2007-03-04 Thread Bryan Østergaard
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

2007-03-04 Thread Bryan Østergaard
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

2007-03-04 Thread Bryan Østergaard
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

2007-03-04 Thread Bryan Østergaard
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

2007-02-21 Thread Bryan Østergaard
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

2007-02-20 Thread Bryan Østergaard
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

2007-02-20 Thread Bryan Østergaard
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

2007-02-20 Thread Bryan Østergaard
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

2007-02-19 Thread Bryan Østergaard
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

2007-02-19 Thread Bryan Østergaard
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

2007-02-19 Thread Bryan Østergaard
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!

2007-02-10 Thread Bryan Østergaard

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

2007-01-28 Thread Bryan Østergaard
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

2007-01-23 Thread Bryan Østergaard
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.

2007-01-09 Thread Bryan Østergaard
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



Re: [gentoo-dev] Through the looking glass: Reflections on Gentoo

2007-01-07 Thread Bryan Østergaard
On Sun, Jan 07, 2007 at 10:14:26PM +0100, Ivan Sakhalin wrote:
 Dear friends and fellow Gentooists,
 
snip lots of text

   While the politics around these cases make rational discussion quite 
   difficult
   it is obvious even to outsiders that this is not in the spirit of the
 original Gentoo Metadistribution - it even violates many of those so-called
 rules that were created to help the interaction between people from wildly
 divergent backgrounds.
   Devrel, as it stands, has always been controversial as everyone saw a
 different use for the rather unneeded concentration of power in the hands of
 a few people. But when people are denied an appeal and devrel unilaterally
 decides, ignoring policies and common sense, what is one supposed to think?

Developer Relations haven't denied any appeals at all. You'll have to
back this statement up with facts if you want to change any developers
mind about this I'm afraid.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Careful when punting old versions

2006-12-30 Thread Bryan Østergaard
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

2006-12-17 Thread Bryan Østergaard
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

2006-12-14 Thread Bryan Østergaard
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/

2006-11-30 Thread Bryan Østergaard
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

2006-11-23 Thread Bryan Østergaard
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

2006-11-23 Thread Bryan Østergaard
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

2006-11-22 Thread Bryan Østergaard
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

2006-11-09 Thread Bryan Østergaard
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

2006-11-09 Thread Bryan Østergaard
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)

2006-11-06 Thread Bryan Østergaard
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

2006-10-31 Thread Bryan Østergaard
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

2006-10-21 Thread Bryan Østergaard
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

2006-10-08 Thread Bryan Østergaard
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

2006-10-05 Thread Bryan Østergaard
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

2006-10-04 Thread Bryan Østergaard
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

2006-10-04 Thread Bryan Østergaard
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

2006-10-04 Thread Bryan Østergaard
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

2006-09-14 Thread Bryan Østergaard
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)]

2006-09-09 Thread Bryan Østergaard
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

2006-09-05 Thread Bryan Østergaard
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

2006-09-05 Thread Bryan Østergaard
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

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

2006-04-29 Thread Bryan Østergaard
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

2006-04-29 Thread Bryan Østergaard
 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

2006-04-28 Thread Bryan Østergaard
 (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

2006-04-28 Thread Bryan Østergaard
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)

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

2006-02-28 Thread Bryan Østergaard
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

2006-02-09 Thread Bryan Østergaard
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

2006-02-09 Thread Bryan Østergaard
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

2006-02-09 Thread Bryan Østergaard
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

2005-12-26 Thread Bryan Østergaard
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

2005-12-25 Thread Bryan Østergaard
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

2005-12-10 Thread Bryan Østergaard
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