Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Denis Dupeyron]

On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman  wrote:
>
> When in the last 16 years was this 2 year period of running stable?
> The general state of QA has varied quite a bit over that time.
>

I would say 3 or 4 years ago, roughly.


> running unstable systemd has been


Running unstable doesn't mean being stupid.


> If unstable never breaks chances are we aren't actually using it for its
> intended purpose, not that we
> should be deliberately breaking things.


There's this idea that unstable should break. But the initial idea was that
unstable is what should be sent straight to stable, barring the occasional
mistake. Unstable was never meant for ebuilds in development and very much
in flux because of that. That's what package masks are for.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Denis Dupeyron]

On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich 
wrote:

> TL;DR;TL;DR:
>
[...]

Here's a data point you may, or may not, find relevant. in 16 years of
using Gentoo exclusively, the only one time I used stable on one machine
for about 2 years it ended up being much more of a pain than unstable.
Actually, I can't say I have anything to complain about unstable. On my
critical machines I snapshot the system subvolume before I update. I can't
remember the last time I had to roll back.

I'm sure most will disagree with me but since you're indirectly asking for
my opinion here it is: I think people working on stable are wasting their
time. But who am I to stop them...

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Denis Dupeyron]

On Mon, Oct 24, 2016 at 5:21 PM, Matthias Maier  wrote:
> And I see absolutely no harm in explicitly annotating the actual
> copyright in gentoo ebuilds.

It seems like a simple and practical enough way to go. However, one of
the arguments going for assigning copyright to the Gentoo foundation
at the time we discussed it is that it offers some level of legal
protection to the developer or external contributor. I have first hand
experience of how abusive lawyers can sue you for totally invalid
IP-related reasons and ruin your life. I've been fighting exactly that
for almost 10 years now. So I certainly appreciate the comfort that
assigning copyright of my Gentoo work to the foundation provides me.
Having grown up in Europe I can see why people would think this could
never happen to them, but living in the US has taught me differently.

That said, we could always make it possible for the developer to
voluntarily assign copyright to the foundation if (s)he so desires.
And I would certainly do that for myself.

Calchan.

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 11:38 AM, Michał Górny  wrote:
>
> Well, maybe it's because you can talk to Python team, discuss and not
> get ignored by them.


We've already established the same is true for the games team. I'm a living
example of it and I can't imagine I'm the only one.


> Unlike games team members who believe it's best to
> ignore certain developers.


I certainly hope we can still ignore abrasive developers since it's been
proven many times that it's the best way to deal with them.

So, you don't answer my question. Or rather, you answer with a specious
statement. Since you're being unusually shy I will say what you're trying
hard not so say. There are actually first-class projects catered for by
first-class developers, and those can set rules like the mandatory use of
an eclass and actually enforce them. Then there are second-class projects
and developers who can do the same as long as it doesn't bother the
first-class people. Second-class developers, often working quietly and
steadily, not wasting their time on mailing-lists like I just did, can see
their projects trampled over at any time for the mere reason that they were
trying to keep their business in order, just like first-class developers do.

Thank you for the clarification.

Denis.

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 10:33 AM, Michał Górny  wrote:

> I was stating the apparent state of facts. If people are told they're
> supposed to go with games team, use their eclass, follow their
> policies, that's how it looks to people.


That's an entirely different point from the one I was making. But I'll
entertain you anyway. All teams have rules and enforce them. If I commit,
say, a python package and I don't use the python eclass, I'm sure to get a
bug filed telling me to do so, a python team-member forcing the change on
me if I refuse, this escalating to comrel if I complain or reverse the
change, etc... So why would it be OK for the python team to coerce and not
OK for the games team? In other words, why would the games team have less
right to good housekeeping than the python team? Here python is just an
example, I could have picked any other team.

Denis.

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 9:22 AM, Michał Górny <mgo...@gentoo.org> wrote:

> On Wed, 17 Feb 2016 08:32:53 -0700
> Denis Dupeyron <calc...@gentoo.org> wrote:
> >  Not true. I've been maintaining games for a decade and have never been
> on
> > the team.
>
> Quoting the previous documentation of games.eclass [...]
>

I'm not seeing the connection you make between the documentation of an
eclass and the fact that I have been maintaining games for ten years
without being part of the games team. From here it looks like you're typing
faster than you can read.

Denis.

Re: [gentoo-dev] games.eclass policy

[Denis Dupeyron]

On Wed, Feb 17, 2016 at 12:39 AM, Michał Górny  wrote:

> developers who did what they cared about and ignored everything and
> everyone else.
>

I don't know if I'm an exception to the rule, but I've always had fruitful
interactions with the games team. I never felt they ignored me.


> games team sole claim to games in gentoo.
>

 Not true. I've been maintaining games for a decade and have never been on
the team.

Denis.

[gentoo-dev] It is GSoC season again

[Denis Dupeyron]

Google Summer of Code 2016 is starting.

If you are a student please be patient. Your time will come soon, at which
point we'll be able to answer all your questions. In this initial phase the
audience is project mentors. Note that you do not need to be a Gentoo
developer to be a mentor.

While we are finalizing the application, we need all of you to submit your
project ideas before the end of next week (February 19th). To do so you
should go to [1] and follow the instructions in the "Ideas" section. If you
proposed an idea last year and would like to propose it again for this
year, you can look it up at [2] and add it to [1]. Or you can just tell us
and we will do it for you. Don't hesitate to add an idea even it isn't
totally fleshed out; we will help you fill in the blanks. A project
represents 3 months of full-time work for a student. A good rule of thumb
is that it should take you between 2 and 4 weeks to complete depending on
how expert you are in the field. You can also have a look at [2] for
examples.

If you would like to be a mentor for this year please tell us sooner rather
than later. You can be a mentor following up with students while they're
working on their project, or you can be an expert-mentor in a specific
field who will be called in to advise on an as-needed basis (or maybe
never). We will also need people to help us review project proposals. In
case you can help in any capacity don't hesitate to contact us. GSoC is
seriously fun!

If you want to reach us or have any questions about any of the above, the
easiest way is to ping Calchan or rafaelmartins in the #gentoo-soc channel
on Freenode.

Thanks,
Calchan.

[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas
[2] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2015/Ideas

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Denis Dupeyron]

On Mon, Jul 28, 2014 at 6:49 PM, Alex Xu alex_y...@yahoo.ca wrote:
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9

Thanks, Alex. This makes more sense now.

Denis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Denis Dupeyron]

On Mon, Jul 28, 2014 at 8:41 PM, Duncan 1i5t5.dun...@cox.net wrote:
 AFAIK, gentoo policy is that live ebuilds should always be masked so as
 never to be automatically pulled in without a deliberate unmasking of the
 live ebuild, but whether that's masked due to lack of keywords (ebuild),
 or due to hard-mask (package.mask) is I believe up to the maintainer.

The policy apparently disappeared in the shuffling of documentation
which occurred over the years. But here is what I was instructed to
teach recruits back when I became a recruiter in 2006 or 2007, and
what competent developers have been doing since even before I was a
developer:

The package.mask file is only for temporary masking, even if more or
less long term. Anything that should be permanently masked has no
place in the tree. Live ebuilds should not be keyworded, reflecting
the fact that the code they're pulling has not be tested for any
architecture due to it being live. Moreover, live ebuilds should not
be masked as this results in unnecessary cruft in the package.mask
file.

Denis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Denis Dupeyron]

On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild

Wait, what? Live ebuilds are keyworded now?

Denis.

[gentoo-dev] Re: [gentoo-dev-announce] last rites: games-fps/postal2mp-demo

[Denis Dupeyron]

On Tue, Jul 8, 2014 at 9:48 AM, Ian Stakenvicius a...@gentoo.org wrote:
 Last rites cancelled; found a version bump'ed distfile via icculus, so
 this one can live a little longer.

I have once asked Robin to archive the distfiles for a commercial
package which has RESTRICT=mirror. My reasoning at the time was that
if upstream disappears there's a good chance, depending on why that
happens, we can qualify the software as abandonware and the no mirror
restriction may become moot. At that point we could push the distfiles
to our mirrors. Note that this particular software still requires
original installation media (on top of the 1GB+ distfiles) and a
minimum of 1 but up to 3 valid license keys to install and then run.

My point here is we could do this preemptively and more or less
systematically in order to avoid being in the situation above. This
could even be easily automated. The worst that can happen is we
archive a few distfiles for nothing, which isn't a big price to pay.

Denis.

Re: [gentoo-dev] The request to abolish games team policy

[Denis Dupeyron]

On Mon, Jul 14, 2014 at 12:11 PM, hasufell hasuf...@gentoo.org wrote:
 a) I'm not sure if I want to be in a team where vapier is lead.

The only position you don't want vapier in is behind you. He humps.

Denis.

Re: [gentoo-dev] Re: The request to abolish games team policy

[Denis Dupeyron]

On Mon, Jul 14, 2014 at 12:10 PM, hasufell hasuf...@gentoo.org wrote:
 People often reply aggressively to unrequested reviews

People often replay aggressively when they feel aggressed. Food for thought?

Denis.

Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo

[Denis Dupeyron]

On Wed, Jul 16, 2014 at 12:22 PM, Alexander Berntsen
berna...@gentoo.org wrote:
 Ulrich is right. Abandonware just means orphaned works -- i.e. the
 copyright holder hasn't sued anyone yet. Gentoo should not have
 anything to do with this.

I agree with you and Ulrich. That was a very poor choice of word from
my part and not what I wanted to say. I didn't mean we should
distribute distfiles without consent, but back them up to a hidden
place while it is possible to do so. Obtaining consent to mirror
updates or linux specific files of a commercial game which is not
distributed anymore when asking politely isn't unseen, because often
the editor or publisher doesn't care any longer. If you don't backup
the files first there is little chance you will get them from the
editor exactly because they don't care.

Denis.

Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo

[Denis Dupeyron]

On Wed, Jul 16, 2014 at 1:28 PM, Ian Stakenvicius a...@gentoo.org wrote:
 So, RESTRICT=mirror would turn into
 RESTRICT=officially-dont-mirror-but-actually-do-just-in-case-distfiles-are-dropped-upstream-but-after-we-still-cant-officially-mirror-them-due-to-license-and-copyright-infringement-anyway
  ?

 Pretty sure, no matter what, we aren't going to be allowed to host
 these distfiles, even if the upstream host disappears, even if the
 company goes under.  If we can't get permission to officially mirror
 the files then the company is active and alive, i don't see how it's
 likely to get permission after the distfiles/server/company goes away.

Either you're trying very hard to not get it or you haven't read my
previous email carefully enough.

Let me try and be clearer. The packages I'm concerned with have had
their distfiles backed up. We're not yet in that situation but the day
the publisher stops distributing these distfiles, I'll be ready to
send the right email to the (hopefully) right person and hope for the
best. I was suggesting we did that more often. And with that I'll stop
here, because these childish arguments are not worth any more of my
time.

Denis.

Re: [gentoo-dev] The request to abolish games team policy

[Denis Dupeyron]

Please do not take this personally.

I honestly wonder what all the fuss is about. There are a few games
I've helped with over the years and I've never had any trouble at all
having my stuff reviewed and accepted. And I'm a lousy ebuild writer.
Every time I'd suggest a fix, bump, or new package, and I came with an
ebuild, I would get constructive criticism and I could then commit it
myself. Not one single time did I get a no. Not once.

You had a fix and it was refused? Have you ever considered you may
have been doing it wrong? I understand having to have your code
reviewed and accepted sounds like an insult to a rock star like you,
but that's the way it is in the real world. It is still beyond my
understanding that code reviews are not mandatory for anything that is
committed in Gentoo.

Rich, if I may have a suggestion, it would be that instead of meddling
with projects that have been doing their best with what they have for
years, and which need praise rather than hindrance, you instead start
a project to get people to think positively and accept criticism. The
amount of energy that was spent in this thread and many others in pure
loss could have gone a long way.

Denis.

Re: [gentoo-dev] Thank you

[Denis Dupeyron]

On Wed, Feb 5, 2014 at 11:30 PM, Canek Peláez Valdés can...@gmail.com wrote:
 Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs

This is totally unacceptable. I demand you take your thank-yous back.
Who do you think you are to thank us like this, even with valid
reasons? Good manners will not be tolerated on this mailing-list.

We have been trying very hard all these years to slack as much as
possible. Your public insinuations that any work gets done in Gentoo
are outright insulting. Since you have been using Gentoo for such a
long time, I dare you to try and become a developer to see if you can
compare to us.

A good day to you nonetheless, sir.

Denis.

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Denis Dupeyron]

On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs willi...@gentoo.org wrote:
 This is nothing new; the qa team has requested that commit rights be
 suspended before. I am just proposing that we actually add the parts of
 the old patch to the glep that spell out when and how this can happen.

 Thoughts?

Yes, thoughts, absolutely. Asking for QA to be at the same time judge,
party and executioner. Need I say more?

Denis.

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Denis Dupeyron]

On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman tom...@gentoo.org wrote:
 It is more of a Do we want QA to delegate this through ComRel or not?.

Actually, no. What it is is a Subject was thoroughly discussed in the
past, and a decision was made. More than once, in fact. What basis do
you have that would warrant more bilkeshedding on this subject?

It may sound crazy, but it isn't entirely impossible that decisions
made in the past were not made lightly. It's also not entirely
impossible that one of the reasons such decisions are made is so that
people can stop rehashing the same topics over and over again and
focus on more useful and fun topics.

Denis.

Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

[Denis Dupeyron]

On Wed, Feb 13, 2013 at 8:31 AM, Aaron W. Swenson titanof...@gentoo.org wrote:
 This information, by the way, has been blogged about thousands of
 times.

There is a reason people write documentation. Contrary to blog posts,
documentation is thought out, reviewed, maintained and corrected when
necessary. Blogs are written out of our collective ass in order to
generate page hits or satisfy our ego, and forgotten right away. Ain't
this handy.

If you want people to handle security properly you have to tell them
how to. In details. If not everybody will figure it out in his or her
own way, all of them wrong. Get off your high horse and write
documentation if you know how things work. That's more productive than
this blabbering.

Denis.

Re: [gentoo-dev] Recruitment process is moving back to quizzes

[Denis Dupeyron]

On Sun, Jul 15, 2012 at 9:08 AM, Ben de Groot yng...@gentoo.org wrote:
 Certainly. But it is likely much more interesting work and has
 considerably more impact.

The mentoring period and the review have considerable impact too.
Whether you think one is more important than the other depends on you
thinking short or long term. The quizzes are no more than a tool, and
us arguing over them shows we're focusing on the wrong things.

Denis.

[gentoo-dev] Re: [gentoo-dev-announce] Gentoo's plan to remove .la files

[Denis Dupeyron]

On Sat, Oct 30, 2010 at 10:25 PM, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
 As decided in the last council's meeting, following the recent
 discussions about .la files removal, I'm sending an email to this list
 with a proposal for a plan to address this issue.

1- Why is a proposal sent to gentoo-dev-announce? Shouldn't that
rather be worked out before being announced? Or is there some context
that the ordinary user or developer is missing?

2- Sending to both gentoo-dev and gentoo-council makes sure that this
splits into twice as many threads as it would have. Good luck with
merging them after that.

Denis.

Re: [gentoo-dev] Tone in Gentoo

[Denis Dupeyron]

On Sat, Jun 19, 2010 at 8:37 AM, Sebastian Pipping sp...@gentoo.org wrote:
 I was more or less told to fuck off if I don't like the tone.

Please watch your language, this is a public mailing-list.

Denis.

Re: [gentoo-dev] Re: Gentoo Council 2010/2011 - Nominations are now open

[Denis Dupeyron]

On Sat, Jun 5, 2010 at 8:36 PM, Ryan Hill dirtye...@gentoo.org wrote:
 I'd like to nominate betelgeuse, calchan, and ssuominen (no way you're getting
 out of here that easy).

Thanks a lot for your confidence but I'll pass.

Denis.

Re: [gentoo-dev] RFC: virtual/icon-theme

[Denis Dupeyron]

On Tue, Apr 13, 2010 at 12:47 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 I think that the packages that currently depend on one icon theme, could
 instead just depend on that virtual. For example, xfce works fine
 without the xfce theme, provided some other theme (like gnome or tango)
 is there.

 Is it a requirement that more than one package should depend on it until
 we can extract a virtual? I think it would simplify managing the
 dependencies anyway.

This is very similar to when you want to add a global USE flag. In
that case we usually require 5 packages and a general non-specific
purpose. It can easily be translated to the present situation.

More practically I would say: use your brain. If you think it makes
sense then go for it.

Denis.

[gentoo-dev] Re: [gentoo-council] Policy regarding the inactive members

[Denis Dupeyron]

On Sun, Apr 11, 2010 at 7:16 AM, Markos Chandras hwoar...@gentoo.org wrote:
 Hello folks,

Hi Markos. A small detail first. You shouldn't cross post as it makes
things confusing and often results in threads splitting. I have no
problem with that because my email client merges threads but it's not
the case for everybody.

 Looking through the Council project page, the policy regarding the inactive
 council members doesn't look optimal to me

If you look at the summary of the last council meeting you will see
that I was tasked to start discussions on rewriting GLEP 39. I have
gathered input from various sources and will start posting the
discussion topics real soon now. One of them is about voting by email
which impacts the slacker rule. Your email will be particularly useful
for the discussion of that topic.

 1) He is inactive in critical discussions ( such as the whole Phoenix
 discussion ) for a certain period of time

This is an interesting concept but finding a metric to gauge activity
based on mailing list discussion is very difficult for two reasons.
You use the example of the Phoenix discussion as one where council
members should have posted to show their activity. However, although
you consider me active you may have noted that I haven't publicly
participated to it. This doesn't mean I don't care or don't have an
opinion on it. But, and this is the other reason, much of the work I
do is done in private. Not that I want to hide anything but I read
threads and based on what developers and users say I ask questions,
advise, (re-)motivate, or connect people, etc... And I do that in
private because it doesn't make much sense to have those conversations
on mailing lists, and also because you guys already see enough of me
there.

 2) Fails to accomplish his role by supervising the Gentoo projects. Remember
 we have plenty of Gentoo projects nearly dead and there is no way for us to
 participate since contacting the project leaders is a no-go. Indirect
 question: Is the council aware of the status of all projects? Shouldn't it
 be since he is responsible for them?

Another hard one to find a metric for. Beyond that, when I wrote my
manifesto for last year's elections I talked with other developers
about the possibility for the council to audit projects on a
volunteer basis. By audit I meant and explained that the council would
closely look at a project at their request and offer advice on short
and long term operation. This wasn't well received at all, to the
point that I didn't even bother adding it to my manifesto.

It seems that project leads like to consider their project as their
own little corner of Gentoo, and don't like too much to be interfered
with. I'm personally OK with that. One of the reasons is that we rely
on volunteer manpower and you can't force a volunteer to do anything
(s)he doesn't want or like or (s)he'll leave. You have to be very
careful when interfering with their work and find the right balance
which will change from one situation to the other.

One example I remember is when last year the kde project was
considering going forward without a lead. It isn't technically a
top-level project so it isn't required to have a lead. I thought that
in the case of such a large project it was a bad idea to not have one
though. I wanted to force an election but decided I would wait for the
right opportunity to make it happen as smoothly as possible. Jorge
will probably confirm that there was no arm wrestling involved. Making
such things happen without hurting anybody and stepping on anybody's
toes requires a lot of thinking and planning. From the opinion of a
lot of devs it's about as far as one should go. By the way this is
probably the kind of leadership Ben was referring to in his recent
thread, although I didn't mention it there as I don't like bragging
about these things.

 I feel sorry to admit that the current council failed to become a good
 leader for Gentoo and his inactivity demotivates both users and
 developers

I partly agree with you. I considered resigning last year when I saw
the disaster from the inside. Ferris convinced me that the right thing
to do was to stay on and do my best to keep things working and change
them when necessary. Which I'm still trying to do, but right now I'm
not sure I'll run next time.

Denis.

Re: [gentoo-dev] Who is willing to be lead?

[Denis Dupeyron]

Ben,

Petteri was proposing an idea. He is being creative and is trying to
help. The only way of knowing if his idea is good is to discuss it and
later try it if people are interested.

You, on the other hand, have lately been increasingly critical (which
is good) but not constructively. You obviously have a lot of energy
but at no point have you offered your contribution. You haven't
offered to help the teams you've been criticizing and you haven't
proposed any real idea (website redesign, recruiters). Also you're
criticizing without knowing what is happening when the information is
publicly available (you're asking for a discussion on the metadata
idea and it was a topic last month, the devrel issue is being tackled
and it started before your rant).

On Sat, Apr 10, 2010 at 8:38 AM, Ben de Groot yng...@gentoo.org wrote:
 I am willing to follow real leaders

Willing to follow? Wow, that's ballsy. Now I understand why you needed
to tell the world about it.

 who inspire and lead by example,

There are lots of good role models to follow in Gentoo. All those who
work their ass off trying to make this distribution better, and use
the mailing lists as a tool to share ideas but not for immature
political rantings.

 You've just shown a striking lack of such leadership.

 No cheers this time,

And you've shown a striking lack of respect for somebody who's been so
dedicated to Gentoo for more time than you've been a developer, and
without whom you wouldn't even be a developer as he was your
recruiter. This is so wrong.

Credibility is among these things which take a long and hard work to
build up and can completely blow up at any time. Don't waste yours.

Denis.

Re: [gentoo-dev] Who is willing to be lead?

[Denis Dupeyron]

On Sat, Apr 10, 2010 at 3:43 PM, Petteri Räty betelge...@gentoo.org wrote:
 On 04/11/2010 12:37 AM, Ben de Groot wrote:
 How about:

 You have lately been increasingly critical but not constructively

 at no point have you offered your contribution

 You haven't offered to help

 you haven't proposed any real idea


 As I read it he was referring to specific things like recruiters not
 your contributions as a whole.

Exactly.

 use the mailing lists for immature political rantings


 As for this I said he could have refrained from mud slinging, didn't I?

No mud slinging there but a fact. You can either ignore this kind of
behavior and let them pollute our mailing lists, or you can point at
them and say they won't be tolerated. I chose the latter.

Denis.

Re: [gentoo-dev] Who is willing to be lead?

[Denis Dupeyron]

On Sat, Apr 10, 2010 at 4:10 PM, Petteri Räty betelge...@gentoo.org wrote:
 I mean things like immature political rantings are not likely to evoke
 the wanted response and it didn't happen here either.

I know it hurts the eyes a bit, but calling problems by their name is
part of fixing them.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot yng...@gentoo.org wrote:
 1. reconsider metadata changepolicies proposal
 ==
[...]
 Can council please decide to honor
 the wish from developers to implement this?

The council will be glad to vote on a GLEP when ready. From GLEP 1,
GLEPs are the primary mechanisms for proposing significant new
features, for collecting community input on an issue, and for
documenting the design decisions. So use them.

Also, you might want to check the log and summary of the last meeting
to find out why the council may end up voting no to such a GLEP.

 2. website redesign
 ===
[...]
 Can council assure that a team will be assembled that can
 effectively tackle this issue?

You want the council to aim their collective gun at volunteer
developers and force them to assemble in a team and work on something
they might not want to work on?

In other words, if you want it then work on it and make it happen.
This is and has always been the Gentoo way.

 3. manpower and recruitment issues
 ==

 Another recurring theme is the lack of manpower in certain areas, the
 recruitment bottleneck and the quizzes. There are some initiatives but
 more decisive leadership is needed. Can council decide to actively
 pursue solutions for these structural problems?

The only way to solve this is to address these issues where they are.
That means joining the recruiters team and helping them with that.
Another thing you might want to do is properly mentor recruits.
Because one reason recruiting takes so long, and thus why there is a
backlog, is (to put is simply) that mentors suck at mentoring.

 4. devrel ineffectiveness
 =

In case you haven't noticed there was a recent change of devrel lead.
This means it is urgent to wait for the results of the change. Because
you never know, it might just be that the change of lead was intended
to solve such things at a perceived devrel ineffectiveness.

 5. centralize developer documentation
 =

This is an interesting idea which I believe I have seen discussed on
irc at some point. Feel free to work on a GLEP to address that.

Before we go any further, let me make the following PA announcement:

 1 - If you want to improve a project or subproject the best (and
often only) thing to do is to join it.

 2 - The council isn't a super-nanny metaproject with enough magical
powers to solve each and every of your oh-so-annoying problems. We do
have magic wands but you don't want to see them.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote:
 So all I'm asking is to do your job and make decisions on issues that
 affect all of Gentoo. The issues I brought up are wider than a single
 individual project.

And almost 100% of the time this needs to run through a GLEP, which is
the case here. Then the council will do all the things you've pasted
from GLEP 39.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 4:30 PM, Richard Freeman ri...@gentoo.org wrote:
 Sure, it is the best way to make big changes

Why then use anything else than the best tool when you can use the
best tool? I didn't say that he should work on a GLEP though, but that
he should feel free to do so, which is different. That meant that if
he thought there was a point to it, was willing to do it, etc...

Just a note about this. The council could for example make the
decision to centralize all the documentation in a wiki, force the doc
team to use tools they haven't chosen or even take that responsibility
out of their hands. Basically step on their toes. Nice way to show
respect for all the hard work they've done for years. Or this could be
discussed on the relevant mailing-list(s) by everybody who feels
concerned, input from the whole community (including the doc team)
could be gathered, council members could chime in (I usually do),
dissenting opinions could be documented, a consensus could be reached
and then design decisions could be documented. See GLEP 1 for more
information on that work flow.

Gentoo has been driven by consensus since Daniel left, for better or
for worse. You might not like this way to work, but that's OK. I
didn't say I thought it was optimal either. All I know is I'm going by
the book, but it allows me to rewrite some pages when I don't like
them. The good news is that during the last meeting the council has
decided to initiate an overhaul of GLEP 39. I'm still gathering
material from various sources to start the discussions open to all
users and developers. At that point you'll have the opportunity to
suggest anything you think may improve the way the council works.

 However, the council can
 still show leadership in affirming their agreement on issues even if it
 isn't a formal affair.

We don't need a meeting for that. We can show leadership on the
mailing-lists everyday. What do you think I'm doing right now for
example? And by the way I don't believe that issuing a statement along
the lines of Yep, we agree shows any leadership at all.
Additionally, leadership is not about doing your job. You may want to
peruse the council meeting logs and summaries for examples of
leadership, and vote for real leaders next time if you think we suck.

 I'm sure every other town government in the Western
 World has taken a vote in support of their troops or something like that
 without going through the official lawmaking process and all that - it is
 just a gesture.

We've been down that road many times before, but let me say it again:
Gentoo is not a government, so any comparison to one is pointless.

 I don't have the time to create such a website although I would agree that
 it is sorely needed.  Hence, I will try to be careful in throwing around
 criticism - it is much easier to bring problems to the table than
 solutions...

Wise words, although constructive criticism is always welcome. In
order to be really constructive however, criticism needs among other
things to take into account goals, resources, history and rules.

Denis.

Re: [gentoo-dev] Re: [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Tue, Apr 6, 2010 at 7:28 AM, Duncan 1i5t5.dun...@cox.net wrote:
 But while I don't do IRC, from various hints I've seen here, that hasn't
 necessarily been the case there.  I'm not making a judgement of whether
 that's good or bad and am only going on various asides I've seen here
 because as I said, I don't do IRC, but that's the impression I've gotten.

There's something to be said about not trusting hearsay, and also
about not talking about something you haven't witnessed yourself. In
other words it looks like you might have wasted an opportunity to shut
up.

Denis.

Re: [gentoo-dev] Is Gentoo a Phoenix?

[Denis Dupeyron]

On Mon, Apr 5, 2010 at 9:33 AM, Richard Freeman ri...@gentoo.org wrote:
 What I was getting at is trying to identify what aspects of the whole
 recruitment process added the most value and which added the least, and
 adjusting accordingly.  I think that assessing attitude and maturity, and
 providing the tools and education needed are the most critical aspects of
 recruitment.

Agreed. Although the education part should come from the mentor.
Recruiters are only supposed to fill in the gaps because there's only
so much they can do. Nowadays most mentors only really care about
making sure their mentee gets the quiz answers right. That's a big
mistake. I've been mentoring somebody to help me with sci-electronics
for months now (hi Rafael!), and the quizzes are less than 5% of what
we spend time on. So what is it then? English and how to communicate
was the big thing at first but he's doing much better now, then
working on a lot of ebuilds in and outside of bugzilla, but also how
to efficiently deal with people, why things happen in a volunteer
project and most importantly why they don't, how to not get
discouraged by many little annoying things, etc... That's the kind of
things a mentor and thus every gentoo developer should invest time in
because it pays back big time.

I've been toying with a project about training mentors but can't find
the time to set it up. The idea was to have interactive sessions on
irc with a few interested devs.

 That's why I'm all for changing the approach to quizzes - from my experience
 it wasn't the quizzes themselves that really added the most value for me.
  The interaction that they triggered and getting me to consider some of the
 more critical issues that come up in ebuild maintenance added far more value
 than getting every detail of the answers 100% correct.

I do make sure that answers are 100% correct since I consider that
part of the necessary paperwork to be recruited. However during the
review I use the quizzes mostly as a way to engage conversation on a
lot of topics, not only technical. That's the reason a review with me
lasts anywhere from 5 to 12 hours.

So in a sense what you're thinking of is already happening.

Denis.

Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?

[Denis Dupeyron]

On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote:

 I see no reason whatsoever to keep it open.

How about this one: preventing users from filing dupes.

 If we
 start doing that, we'll end up with tons of extra bugs on our hands.

What's the big deal? You know you'll be adding/bumping the package at
some point. Just close the bug when you do so. It's certainly less
work than marking it RESOLVED FIXED once and then DUPLICATE many times
after that.

The point of bugzilla is tracking bugs, not a tool to arbitrate a
pissing contest about who has the least bugs open. If you can't/don't
want to fix a bug that's OK, but it's not a good enough reason to
pretend it never existed.

Denis.

Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?

[Denis Dupeyron]

On Sat, Apr 3, 2010 at 9:25 AM, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
 I disagree. Resolved LATER is useful to some maintainers that want to
 fix that bug, but don't have time or don't find the issue to be a
 priority at the moment. By marking it LATER they're acknowledging the
 bug exists and needs to be taken care of.

Reassigning the bug to yourself (or the herd) if necessary, accepting
it, and then explaining what/who/why/etc in a comment is the way to go
in that case. No system, however good it is,  will replace proper
communication.

Denis.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Mon, Apr 5, 2010 at 11:57 AM, Jon Portnoy av...@eris.oppresses.us wrote:
 Which is all well and good -- the you wrote some ebuilds so here's
 your commit privs and @gentoo.org approach to recruitment worked great
 when Gentoo had a few dozen developers.

 Today QA is a bit more important, and development is often rather more
 complex than new version, bump the ebuild -- it's important that new
 developers have a firm understanding of ebuild complexities.

That's a very important point. On one side there are developers and
would-be developers who want an easier way to recruit people. Most
ideas revolve around lowering the technical/social barriers. On the
other side there's QA and a bunch of other developers who want fewer
people screwing up the tree. Those are proponents of being stricter
during the recruiting process (i.e. in the end recruiting fewer
people) and firing more devs.

None of them though help the poor guys in the middle. Those are the
recruiters who could swing completely one way or the other for
simplicity, or be more subtle and try and make the best out of the
situation and resources.

When you're all done barking, and in case you really consider helping
here are two things you can do:
 - join the recruiters
 - actually *mentor* people to become developers. And by that I don't
mean passing them your quiz answers, but really training them and
preparing them to become good and well behaved developers. When people
ask me how to go about that my usual answer is do as you were teaching
your son/little brother how to fly fish (or replace fly fishing with
what you do best). Start from the start, progress from there, don't
overlook any aspect of the art (there's more to being a dev than
writing ebuilds), and be ready to spend hours explaining and
re-explaining. If your recruit doesn't get it then it can only be your
fault, so try harder.

Before you replace/change a system you should first try and make it work.

 II don't even like resurfacing to post to -dev.
 Just here to offer some insight on why we originally kept the quiz system.

Hi Jon, long time no see. Thanks for doing that.

Denis.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Mon, Apr 5, 2010 at 12:51 PM, Nathan Zachary
nathanzach...@gentoo.org wrote:
 [...] but it
 would be much more enlightening to me to work on creating ebuilds while
 working one-on-one with a mentor.

The whole purpose of the training period between the ebuild quiz and
the end quiz (see [1]) is exactly this. If your mentor isn't doing
that with you then look for another one who will mentor your properly.
Don't blame the system when it's not used.

Denis.

[1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

Re: [gentoo-dev] Is Gentoo a Phoenix?

[Denis Dupeyron]

On Sat, Apr 3, 2010 at 5:33 AM, Richard Freeman ri...@gentoo.org wrote:
 I think the problem is that our recruitment process uses the ability to
 answer complex technical and organizational questions as a way to assess
 maturity.  I think that maturity is far more important than technical skill
 in a distro - a mature person will recognize their own limitations and
 exercise due diligence when stepping outside of them.  Instead of playing 20
 questions and going back and forth with recruits, maybe a better approach
 would be to cut down the questions dramatically (or more clearly put their
 answers in the documentation), and then use other approaches like references
 and interviews.  A new recruit might be given the names of 5 devs that they
 will need to interview with for 30-60 minutes by phone or IRC (preference on
 phone), and they will need to submit references, who will be contacted.
  When we hire people at work we don't play trivial pursuit with them, we use
 an interview to get a feel for what they're like and how they handle
 situations, and we screen resumes and references to determine experience.
  I'm sure any of the professional linux distros would work in the same way,
 but perhaps somebody should ask around and see how it is done elsewhere.

All ideas regarding improving recruitment are welcome, thanks. However
if, during your review, you were not given the impression that your
maturity and other social skills were being assessed then you were
being blissfully naive. :o) I use tricks like pretending I don't
understand that crystal-clear thing you're explaining to gauge your
patience and politeness, I drift off to real-life topics to find out
who the recruit really is, and lots of others like background searches
(also outside of gentoo) and talks with the mentor.

On the other hand, in your particular case, I clearly remember the
assessment was easy and thus I didn't insist too much. Which is what
probably made it more difficult for you to notice.

Denis.

Re: [gentoo-dev] Qt3 mask breaks significant science packages

[Denis Dupeyron]

On Fri, Mar 12, 2010 at 6:18 AM, Robert Bradbury
robert.bradb...@gmail.com wrote:
 It would appear that the pending (0321) mask of Qt3 will break
 sci-misc/qcad, sci-chemistry/xdrawchem and x11-misc/glunarclock.

I'm not concerned but I feel sympathy for those who use these packages
and many others. The decision from the qt project to remove qt3 and
all its dependencies from the tree is suboptimal to say the least. A
library project should be at the service of those using the library,
not dictating to those using it.

That said they were perfectly entitled to make the decision of not
wanting to maintain qt3 any longer. The only advice I can give is that
all disgruntled users and developers create a qt3 project and
adopt/unmask/re-commit the qt3 libraries for maintainers of packages
who need it. I doubt this will happen as this could have been done a
long time ago, but it's never too late.

Denis.

Re: [gentoo-dev] sudo vs su

[Denis Dupeyron]

On Sun, Feb 28, 2010 at 12:20 PM, William Hubbs willi...@gentoo.org wrote:
 I am starting this thread because I don't understand why people are
 using sudo and su together.  They are completely separate utilities that
 do the same thing.  AFAIK, it should be either sudo -i or su -, but
 not sudo su - which I have seen quite often.  sudo su - is redundant
 because su - does the same thing as sudo -i.

 sudo -s, afaik, gives you a root shell but does not clear
 out the environment first.

 Am I completely missing something?

Some systems are configured with a random root password. After a while
you get tired of doing 'sudo command' all the time and would like to
become root but you can't because you don't know the root password.
One way around that is 'sudo su -' which allows to become root using
your user password.

Denis.

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

[Denis Dupeyron]

On Mon, Feb 1, 2010 at 4:30 PM, Mike Frysinger vap...@gentoo.org wrote:
 This is your monthly friendly reminder !  Same bat time (typically
 the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel
 (#gentoo-council @ irc.freenode.net) !

Uh... no. The meeting is actually next Monday (January 8th) at 2000UTC
/ 2100CET / 1500 EST. We now adapt the date and time to suit our
schedules and maximize everybody's chance to be available. Mike, could
you please stop your cron job? It's now useless as I have to send the
reminder email manually, which I do more or less two weeks in advance.

Thanks,
Denis.

Re: [gentoo-dev] GLEP58 - MetaManifest

[Denis Dupeyron]

You'll find below an email from solar to Robin about MetaManifest. I'm
adding it to this thread (with solar's authorization) as it seems
pertinent.

Denis.

On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd so...@gentoo.org wrote:
 Robin,

 I recall you wanted me to mail you what we talked about last nite in
 #gentoo-portage and I'll CC: the council so they have an idea what to
 maybe expect.

 So in our talking last night we discussed the fact that if the Manifest
 format has to change why not just get rid of it all together, and save
 some serious in tree space with the new MetaManifest's taking over all
 together. This would include MetaManifest's at the 2-level.
 You said the MetaManifest would need about 4 fields in them to describe
 the distfiles etc. Devs would still push normal Manifest's to the cvs
 tree so DIST can be obtained by the backend infra scripts. But those
 Manifest's could be dropped from the mirroring. if [ -e CVS ] then
 portage would need to use the existing Manifest's

 This method would hands down win my vote. As you know I'm not a fan of
 format changes in general as they can make the Gentoo experience suck,
 but if we are going to change formats. Lets do it right.

 The only downside I can see in this method is for people like drobbins
 who mirror our tree but overlay right on top of it then provide it back
 out.  In such cases we should provide our backend scripts to the public
 so they can re MetaManifest.

 I'm probably forgetting all sorts of details from the chat. But
 hopefully this is enough to remind you, as well as giving the other
 council ppl an idea of what to maybe expect.

Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay

[Denis Dupeyron]

(I'm resending this email as the original apparently did not make it
to the list, although Thomas probably received it)

Hi Thomas,

I'm replying to the original thread below to allow those who have
missed it to have the full context.

On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau to...@gentoo.org wrote:
 Let me introduce a nice project, which was started by some users:

 Since the emul-linux-x86-* packages for 32bit libs for amd64 users are 
 neither easy to maintain nor
 up-to-date, some users started to implement an eclass, which allows to build 
 requested libs with
 additional 32bit support. Later i joined them and helped them improving it a 
 bit, but it was and
 still is mainly their project, they do the main work keeping this overlay 
 up-to-date.

 Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either 
 requires continual
 work or modification of many ebuilds in main tree to support this in long 
 term. To avoid this, i
 took the original multilib portage patch from kanaka, adjusted it to the 
 current portage code and
 added the ideas and code from the eclass version. The result is now a 
 portage, which is able to
 build any ebuild with additional 32bit lib support.

 The current main regression are ebuilds and eclasses, which do not support 
 this (e.g. perl modules
 and mysql).

 If anyone is interested:

 -for the eclass version, which is mainly maintained by users and is mainly 
 intended to only replace
 the emul-linux-x86-* package: just add it via layman -a multilib (it should 
 be pretty stable and
 mostly working).

 -for the portage version: It is also in the multilib overlay, but in a 
 different branch called
 portage-multilib. To use this, you should read the instructions at [1]
 (doc/portage-multilib-instructions). This one should also mainly work, but 
 there is probably a good
 amount of packages in the main tree, which may refuse to work with it.

 Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, 
 but we also have an
 alias, where you can contact us: multi...@g.o

 [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib
 --
 Thomas Sachau

 Gentoo Linux Developer

I have already explained that I think it's a wonderful project and I
definitely would like to see it in the tree sooner rather than later.
There was a discussion on the council alias where everybody who
participated seemed to like it too.

However the consensus was that the project wasn't mature enough (I
will let the other, more technical, council members comment on that).
There are still open questions on this here thread, there is a request
for low-level documentation and a high-level doc is also required
(make it a request from me if you want), a preliminary PMS patch is
needed, possibly a devmanual patch too, etc... I'm not saying we're
asking you to do all this alone because this isn't how a collaborative
project like Gentoo should work. We have resources and they are at
everybody's disposition. We (I) will help you coordinate that effort
if you need/want it.

I have noted somewhere that you are concerned about having to do an
EAPI bump and were trying to work around that. I understand your
concerns and would tend to agree with you since in the past these
things were not addressed smoothly and timely enough. This council
showed however that we were ready to change plans and create EAPI
bumps when needed [1]. If multilib is ready before or at the same time
as prefix we can add multilib to EAPI3. If not, well, we will bump as
needed by multilib or any worthy project/enhancement anyway. There is
no point carving (the former) EAPI3 into stone and having it block
everything else due to its implementation taking longer than
anticipated.

Also, there is no good reason for doing things the wrong way. If an
EAPI bump is needed for multilib then let's just do it. I will
personally see to putting this EAPI bump on the agenda when multilib
is ready. And I'm convinced that at that time my fellow council
members will simply vote yes.

As you have noticed on the portage irc channel I discussed the
maintenance of your branch with Zac. He has agreed to help you with
that, and I understand that's your main concern at the moment. It
appears that the portage repo is in the process of being converted to
git [2] and this should make it a lot easier. I suggest you talk to
Zac directly about this. Still on this subject, I will put the
question of whether we should add this new multilib to the portage 2.2
branch or something more experimental on the agenda for the next
meeting. I will also add multilib as a topic for the open floor
discussion.

Feel free to contact me in private if you have any question or need
help with the above requests. I will do my best to assist you.

Denis.

[1] http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt
[2] https://bugs.gentoo.org/show_bug.cgi?id=196025#c34 and further

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

[Denis Dupeyron]

2010/1/12 Tomáš Chvátal scarab...@gentoo.org:
 Dont be joking,
[...]

Mmmh? Take a deep breath, a long walk, a large beer, or whatever
works. Because you need it.

Denis.

Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)

[Denis Dupeyron]

Brian,

On Sun, Oct 25, 2009 at 6:50 PM, Brian Harring ferri...@gmail.com wrote:
 The proposal is pretty simple; if code modifies the vdb in any
 fashion, it needs to update the mtime on a file named
 '.modification_time' in the root of the vdb.

 For example-

 1) ${PACKAGE_MANAGER} fires ups, builds a pkg.  it's now ready to
 install it.
 2) this step isn't strictly required, but is a zero cost safety
 measure- prior to modifying the vdb, it updates the timestamp.  The
 reason for doing this is to protect against the manager blowing up in
 some fashion and now updating the timestamp- there still is a window
 if the manager breaks down during merging but it's far reduced.
 3) manager does it's thing to the livefs, and to the vdb.
 4) once finished, again, updates the timestamp.

 This isn't an incredibly complex change.  What it enables however is
 package managers to get serious about optimizing access to the vdb.
 For example for the 3 managers:

 paludis:
  installed-cache currently needs to be manually ran by the user;
 specifically, the user is responsible for regenerating this cache if
 they use a non paludis manager to modify the VDB.  This can be
 automated via checking the vdb timestamp against a stored copy of the
 the vdb timestamp at the time of the cache generation.

 portage:
  portage maintains a set of denormalized caches of the vdb- it however
 has to do validation of those caches on each access, meaning quite a
 few stats.  Same thing, can compare timestamp from current vdb to when
 it was generated to identify if it is no longer authorative.

 pkgcore:
  pkgcore maintains a denormalized old style virtuals cache- same thing
 w/ portage, it has to do validation (stat'ing) whenever it uses that
 cache to ensure the data is accurate.  Same thing, can compare
 timestamp from current vdb to whenit was generated to identify if it
 is no longer authorative.

 The existing vdb caching could all be modified to use this timestamp.
 One stat in the best (common) case, instead of having to either scan
 the whole vdb each time or doing a subset of stats.

 This change enables further caching/denormalization of the vdb data
 while maintaining the old format- basically, it allows the manager to
 build out a helluva lot faster access to the vdb while keeping on
 disk compatibility in /var/db/pkg.


 Now unfortunately since the vdb is not format versioned in any
 fashion, to get this timestamp we have to do the following-

 1) nudge everyone who has code poking into the vdb to update their
 code to update the timestamp
 2) sit on our hands for N months until such time we've deemed
 everyone we care about has upgraded
 3) push out a new release, and start pushing out versions of the
 managers/vdb consumers that use this timestamp instead of just
 updating it.

 For anyone who has been around gentoo for a couple of years, this is a
 pretty familiar pattern- eapi, profile changes, etc, all go through
 this unfortunately.


 That's the core of the proposal; there is a ticket open
 ( http://bugs.gentoo.org/290428 ) regarding this although there is
 some debate from ciaran which I'll try to now summarize, along w/ the
 counterarguments.

 1) do a new vdb.
 Counter: this mechanism provides a way to synchronize the new vdb
 while maintaining the old during it's transition period, so this is
 needed anyways.  Further, pinning all of our optimization hopes on a
 new vdb is daft- it's been discussed for 5+ years now and still
 hasn't materialized (pkgcore has been able to have a new vdb for
 several years, but without a synchronization mechanism it would
 require locking users into the new format and locking out old
 consumers of the vdb- an unfriendly choice to push on users, hence
 never being implemented).

 2) code that hasn't been updated to adjust the timestamp, but is still
 in use after the transition period will break things.
  Counter: nature of any modification of this sort, frankly the gains
 outweight the costs of users being rediculously out of date.  Not
 saying it's perfect, but until someone comes up with a proposal that
 versions every PMS component (meaning PMS has to start documenting
 the VDB), it's what we have if we wish to move forward in
 refactoring.

 3) the correct approach is to require users to tell each manager that
 changes have occured outside it's purview (run paludis
 --regenerate-installed-cache after every time you invoke pmerge or
 emerge).
  Counter: that's rather unfriendly to users, and isn't what
 pkgcore/portage do.  Further, it's historically the opposite of the
 norm- consider the ebuild cache (we do validation as we go there,
 instead of expecting users to do a emerge --regen everytime they
 modify an ebuild).


 That's roughly the three points raised; there is some minor quibbling
 that mtime cannot be trusted, but that's mostly a variation of #2.

This looks to me like a good idea. I see some of it at least has been
implemented in portage and I would suspect in 

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

[Denis Dupeyron]

2010/1/2 Pacho Ramos pa...@condmat1.ciencias.uniovi.es:
 [...] I failed to see if, finally, an approval
 from the council is needed for merging [multilib] to portage-2.2 or not

The only approval that's required to merge anything to an official
portage branch is Zac's (zmedico). He may have to follow some rules
and wait for some vote from the council when for example EAPIs are
concerned but whether to merge code or not is his decision and
responsibility. That said I've never seen him refusing to merge
anything that was worth it.

 if [multilib] will be discussed finally on this meeting.

Technically we don't need to (I'll explain that in another email) but
we may. I'm just starting to work on the agenda for the 18th and I
don't have everything in place yet.

Denis.

[gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

[Denis Dupeyron]

On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau to...@gentoo.org wrote:
 I will make it short, since i already requested it 3 times, did create a 
 thread at gentoo-dev ML:

 agenda topic: Discussion and approval for following item:

 Adding real multilib features from current multilib-portage to currently 
 hardmasked and testing
 portage-2.2* for wider testing, more eyes looking at it and hopefully more 
 people helping improving
 it, so we can get a version, which most can accept for PMS and maybe next 
 EAPI.

Sorry, I forgot to send an email explaining what happened on the
council alias as promised. The consensus was that the project wasn't
mature enough to go ahead. Also more generally the council's job isn't
discussing but deciding, approving, etc... Discussing is what should
happen on mailing lists. Before you can bring that to the council we
need to see an as-much-as-possible finalized solution with any of the
following if applicable: portage branch with an implementation that
people can try, documentation, PMS patch, devmanual patches, and a
team. By team I mean: who is going to maintain this in the long run if
necessary? A one man team is a dead team, it's only a matter of time.
If the amd64 team is going to be the one doing this job, and this is
just an example buy the way, then we need them to tell us they're OK
with it.

Now don't get me wrong. I love your project and the last thing I want
is to shoot it down. Look at what happened with prefix. They wanted
the council to approve it immediately or else... We didn't cede to
pressure and worked with them to make it good enough for approval.
Right now I don't hear anybody arguing about prefix going forward. And
that's exactly what I want for your project, i.e. helping you making
it better instead of it fading and failing in the (not so) long run.

I will stop now because I'm at a bus stop near Mount Fuji and I need
to go. I hope the other council members, especially the more
technically competent ones than me, will get back to you on this and
offer help and advice. As soon as I have a better internet connection
I will contact you about this.

Denis.

[gentoo-dev] Re: mtime preservation

[Denis Dupeyron]

A quick note to tell you that I have tried to look for examples of
breakage due to how mtime preservation is currently implemented in
portage. Unfortunately I didn't find anything, maybe because I'm not
knowledgeable enough or because I can't afford to spend any more time
on this. If any of you can provide an example then please do so.

In case nobody could show any sign of such breakage I would have to
add to the list of two propositions to vote on:
3- Do nothing.

We can always point to code that shows the implementation is
suboptimal but we have to understand that some of us who are less
proactive at fixing issues may want to procrastinate until breakage
actually happens.

Denis.

[gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC

[Denis Dupeyron]

The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
us to discuss things please let us know in reply to this email. What
is already known is we'll talk about mtime preservation and prefix.
You can find threads about those at:
http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml

Denis.

Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds

[Denis Dupeyron]

Things seem to be progressing nicely on this front. We have answers to
the questions people had and they look satisfactory to me.

One thing that I think would be valuable is a document that explains
the average dev how to make his/her ebuilds prefix compliant with
links to more details when necessary. I understand that there's the
trivial situations and the less trivial ones. In the latter case it
would be nice to explain why the case isn't trivial and how to fix it.
Using python as an example could be one way to do it. I'm thinking of
something practical that could possibly be patched into devmanual. If
such a document already exists then please just point us to it.

On Fri, Nov 20, 2009 at 2:03 AM, Fabian Groffen grob...@gentoo.org wrote:
 I thought I asked Fabian to work on that at the end of the meeting. In
 case I didn't then consider this as me officially asking him if he can
 take care of it. Fabian is this OK with you?

 Yes, I agreed coming up with some patch.  I admit I haven't yet even
 looked into it.

Great, thanks. If you can have it ready some time before the meeting
so that all devs can get a chance to review it before the council
members vote on it that will be even better. If you need help don't
hesitate to contact me. I'll try and look for the right people to help
you depending on what you need.

 Technically, Portage trunk already contains the most important bits that
 allow us to continue since yesterday.  The rest is waiting for a formal
 approval of the council, and then it will most probably be me and Zac
 fighting to get the prefix branch merged into trunk.

Good.

 Next to that, it is part of the Prefix team's job to make sure that
 whatever is installed, does not reference the host system when this is
 not absolutely necessary.

Could you give some examples of when it is absolutely necessary?

Denis.

Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds

[Denis Dupeyron]

It looks like this question is still unanswered:

On Thu, Nov 19, 2009 at 5:26 PM, Denis Dupeyron calc...@gentoo.org wrote:
 How are dynamically linked set*id programs going to work?

Denis.

Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds

[Denis Dupeyron]

On Sun, Oct 18, 2009 at 2:11 AM, Fabian Groffen grob...@gentoo.org wrote:
 This is a formal apology for springing that onto you.

Thanks a lot. Not everybody can do such a thing as a public apology. I
will nonetheless ask the council to vote on the following during next
meeting:
Ask Fabian to change his signature from:
Gentoo on a different level
To:
Failure in a different level
;o)

2009/10/18 Tomáš Chvátal scarab...@gentoo.org:
 Why on earth portage simply does not detect the prefix enviroment is being run
 and then INTERNALY switch D-ED and other variables.

If that means we can get away without touching ebuilds, apart from
changing their EAPI variable, then that's absolutely what we have to
do. I'd like things to be done the right way though (see below).

On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller u...@gentoo.org wrote:
 However, there is need for additional discussion. From the council
 meeting log I could extract the following open questions:

It would be preferable for the discussion to happen on this list
before the meeting or we'll end up postponing again due to having more
questions coming up at that time.

  2. Should the Prefix team be allowed to do the necessary changes to
 ebuilds themselves, or should it be done by the respective
 maintainers?

I think here it's obvious that anybody who is an ebuild dev and sees
anything to fix (prefix or else) is encouraged to go ahead and do it,
as we've always done. The recommendation is and will always be to talk
to the current maintainers out of politeness and to be extra careful
(i.e. usually letting the maintainers do it) in case of
system/tricky/exotic package. We don't give full cvs access to the
whole tree to all ebuild devs for nothing.

  4. EAPI numbering: Would this simply be added as an additional
 feature to EAPI 3? Or should we have an intermediate EAPI slot,
 e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter
 case)?

Here I'd add to the choices: why not release an intermediate EAPI with
the prefix stuff and whatever that has already been done for EAPI3?
The exact name of a potential intermediate EAPI is a non-problem.
However I would prefer if it were a number like 2.1 or 2.5 or even 3,
because although we currently treat the EAPI variable as a simple
string we may change our mind later and find it handy someday to use
operators on them such as =2.1.

  5. Who is going to write the exact specification (PMS patch) for
 this EAPI feature?

I thought I asked Fabian to work on that at the end of the meeting. In
case I didn't then consider this as me officially asking him if he can
take care of it. Fabian is this OK with you?

Also I think it would be nice if somebody took care of a portage
patch, since I hear it is rather simple. Fabian again? Or Zac? Any
other volunteers?

I would prefer to have all the pieces in places before the next
meeting so that we can vote on the real thing and have prefix
implemented the right way before the end of the year.

  6. (Any question that I've missed?)

Here are a few that I gathered from others (my comments are between
parentheses):

 How are dynamically linked set*id programs going to work?

 How are scripts using #!shebangs going to work?
 You write an ebuild, and you DEPEND upon =foo-3, because the build
 process includes some foo code. The foo code is executed via
 scripts using #!/usr/bin/foo. Normally, this is fine.
 But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2
 that's no good. So even though you've got the foo-3 dep met, it'll be
 met in /opt/Gentoo/blah, so your package will fail.

 How are ebuilds to be marked as supporting prefix or not?
(Here I'm guessing that changing the EAPI variable will do)

 Why is there only a single permitted installation path?
(I'm under the impression this is a limitation of the windows
installer but not of prefix itself. So patching the installer would
fix that)

 What exactly is expected from a prefix-compliant package manager to
 support full prefix installs, as opposed to just supporting installs
 to / with prefix-aware ebuilds?
(The PMS patch should answer that)

Denis.

Re: [gentoo-dev] Removing kde-base/arts from tree.

[Denis Dupeyron]

On Tue, Nov 10, 2009 at 3:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 I'm tempted to say otherwise it will be hardmasked with kde-base/arts
 by the end of this week, but that might be too intimidating for some.

And completely unreasonable. Some of us have a life.

Denis, wondering why the hurry.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild

[Denis Dupeyron]

On Sat, Nov 7, 2009 at 5:43 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 I'm seconds away from masking KDE 3.5.10, only fixing gentoo-x86 in a
 shape it's possible.

 So sorry everyone for not stopping on every single package and metadata.xml.

 Just getting this done.

Quantity isn't a replacement for quality. Nobody's pressuring you, so
you can take all the time you need to do things properly.

You're a volunteer so you can do whatever you want, including a lousy
job and not respecting rules. Just don't expect everybody to be happy
with that.

Denis.

Re: [gentoo-dev] KDE Team Meeting - October 2009

[Denis Dupeyron]

2009/10/21 Maciej Mrozowski reave...@gmail.com:
 1. Proposition to split desktop profile to: KDE, Gnome, (and maybe some
 others).

How about making a desktop profile with everything common and being
the parent of Gnome, KDE, XFCE, etc... sub-profiles with the specific
stuff?

Denis.

Re: [gentoo-dev] QA last rites for dev-tinyos/ncc; dev-tinyos/tos-make; dev-tinyos/tos-scripts; dev-tinyos/tos-uisp; dev-tinyos/tos-apps

[Denis Dupeyron]

On Sun, Aug 9, 2009 at 3:31 PM, Diego E. Pettenòflamee...@gmail.com wrote:
 # The rest are dependencies. The rest
 # of dev-tinyos might be added if it doesn't make sense
 # without these.

Please last rite the whole thing if you feel like it. All my attempts
at proxy-maintaining this have failed.

Denis.

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

[Denis Dupeyron]

On Sat, Aug 1, 2009 at 7:10 AM, Sebastian Pippingwebmas...@hartwork.org wrote:
 I would love to see the GLEP on CPE names in metadata.xml discussed,
 http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35155.html

 Any guidance on what I need to do to make it happen is very welcome.

Please read GLEP 1 [1], and more specifically the GLEP work flow. Your
GLEP needs to be submitted to and then accepted by the GLEP editors.
Once it is accepted it will be assigned a number and you can discuss
it on gento-...@gentoo.org (announce it on
gentoo-dev-annou...@gentoo.org with reply-to set to
gentoo-...@gentoo.org). Once that is done and a consensus has been
reached you can submit your GLEP to the council for vote.

In your particular case I'd like to know what are the plans of the
other distributions. I would even think that they should be involved
in the discussion process. And what happens when packages don't
exactly overlap? Binary distros often use many sub-packages to work
around their lack of something like our USE flags, and also to avoid
forcing users to download a whole bunch of non-executable stuff when
the binaries were patched. This thing isn't as easy as your (short)
GLEP draft makes it look like.

Denis.

[1] http://www.gentoo.org/proj/en/glep/glep-0001.html

Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?

[Denis Dupeyron]

On Tue, Jul 7, 2009 at 7:45 AM, Ciaran
McCreeshciaran.mccre...@googlemail.com wrote:
 Perhaps you should consider that it's your behaviour that's the issue here.

It's both your behaviors, because they're extremely similar. Except
that you seem to have more time available than slong to express your
defensive personality on our various media.

I'm going to have to ask the two of you to stop arguing in public,
because very frankly we don't care. Plus it's completely off-topic and
an abuse of our mailing-list system.

Thanks,
Denis.

Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?

[Denis Dupeyron]

On Tue, Jul 7, 2009 at 10:20 AM, Ciaran
McCreeshciaran.mccre...@googlemail.com wrote:
 I contribute productively and usefully

This should have gone in private but I want it to be public because
you and others apparently do not get it. The fact that you're
contributing or not does not give you or anybody else the right to
behave improperly on our mailing lists, forums, or else. There is no
amount of contribution that would compensate for even the slightest
inadequate behavior. Please everybody, print that and pin it above
your monitor.

 repeated pot-shots from the peanut gallery.

Thanks for the good example. Please, you and everybody else, note that
this above is considered abrasive by most of us. If you do this, not
only do you pollute our mailing-lists, but you also attract more
abrasive behavior from others. You only get what you deserve, so if
you need to cry on somebody's shoulder then go see your mom. Do not
express your hurt feelings on this list, we don't care. Not talking
about making an ass of yourself for being so childish.

 Steve pops up every now and again and tries to disrupt things.

You do the exact same in you own way. Please allow me to take that
beam from your eye.

Now, I suggest you do not reply to this mail in public as this would,
again, be off-topic. Feel free to contact me in private though, I'll
be happy to discuss that with you in case you need to.

Denis.

Re: [gentoo-dev] Bug #250853

[Denis Dupeyron]

Hello Robson,

On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza
Peixotorobsonpeix...@gmail.com wrote:
 http://bugs.gentoo.org/show_bug.cgi?id=250853
 On bugzilla has the patch to solve the problem

The people concerned by this already know about the bug and patch,
there is no need to remind us here. They will get to it soon as they
can. They're volunteers and do as much as possible in the free time
they have.

In addition, this mailing list isn't for specific issues such as this
one, please use bugzilla instead.

Thanks,
Denis.

Re: [gentoo-dev] Manifesto archive

[Denis Dupeyron]

2009/7/3 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org:
 Yes, that is another thing I was planning to do. The only reason I
 haven't done it yet, is that older manifestos were stored as txt files
 and this year the candidates mostly opted for html/xml files.
 I'll probably just go ahead, ignore the looks and copy their
 manifestos to txt files. If any of the nominees would be kind enough to
 do it for us and send us the file, it would be greatly appreciated.

I have made an html manifesto out of rst and a few others have copied
it along with the makefile. So those of us who used rst have the
source available, and I suggest you copy that instead of converting
the html to text. You could also trim down my manifesto and turn it
into an example and archive it with the makefile as a template for
future use.

Denis

[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?

[Denis Dupeyron]

I'll have things to say about this but I'm still in the woods with
dialup until monday. So either I can get close to a fatter pipe later
today or tomorrow, or I'll do it on monday night from home.

Denis.

Re: [gentoo-dev] 2009 Council Elections

[Denis Dupeyron]

On Fri, Jun 26, 2009 at 6:46 AM, Ben de Grootyng...@gentoo.org wrote:
 To appoint as proxy for a council meeting someone who has been booted
 from Gentoo is a clear lapse of judgement, and would in my eyes
 disqualify the involved council member from functioning in that position.

As Petteri noted it's not obvious that GLEP39 disallows choosing a
non-dev as proxy for a council meeting. I haven't talked to Tiziano,
and I don't know what he had in mind when he chose ciaranm as his
proxy, but I'd be ready to believe part of it was that he wanted to
experiment. And experiments sometimes succeed, or sometimes they fail,
but they often teach you something. I wouldn't be as fast as you to
remove Tiziano from the list of people I'd vote for.

Denis.

Re: [gentoo-dev] 2009 Council Elections

[Denis Dupeyron]

Thanks for the reminder, Doug.

Make sure to also check everybody's manifesto here:
http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml

Denis.

Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009

[Denis Dupeyron]

[...]

This list is for technical discussions only. Also, public mailing-lists are
not for discussing your personal issues.

Denis.

Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009

[Denis Dupeyron]

 probably belongs in -project.

Not even in -project, it simply wasn't public mailing-list material.
For those who haven't understood yet, the -dev and -project mailing
lists are not for keeping us informed of your random thought of the
day or lamenting about
why-oh-why-is-the-whole-world-so-unfair-to-me-when-I'm-being-so-nice-to-everybody-no-kidding.
Keep tweeting it though.

Denis.

Re: [gentoo-dev] Bug 244436

[Denis Dupeyron]

Hi Jean-Marc,

On Tue, Jun 9, 2009 at 3:46 PM, Jean-Marc Beaunejm.bea...@gmail.com wrote:
 Sorry to be a pain but I just wonder if I filled this bug correctly because
 nothing happens: http://bugs.gentoo.org/show_bug.cgi?id=244436

 I'm not putting any pressure in any way, I just want to know if I did it
 right.

This already high traffic list is definitely not the right place for
such a request, and neither is the bug you filed. Thank you though for
filing this bug and offering your help. I have the feeling you haven't
found all our documentation on how to contribute, so I will send you a
list of links and some additional information.

Denis.

Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format

[Denis Dupeyron]

On Thu, Jun 4, 2009 at 8:20 AM, Doug Goldstein car...@gentoo.org wrote:
 This is not a debate nor is this thread meant to be a launching point
 for people to promote their own campaign for being on the council and
 I chide you for taking it as such.

I was just trying to contribute to the debate, no more. Since I had
already written about this elsewhere I figured it was better to point
readers there than just repeating it here. And for your info I'm not
promoting any campaign. Where and when have you seen me doing this
before ? I suggest you cool down a bit, and accept help and ideas from
wherever they come.

Denis.

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Denis Dupeyron]

2009/6/1 Dawid Węgliński c...@gentoo.org:
 I nominate:
[...]
 Calchan

Thanks Dawid, and also Ferris. I accept. You can find my manifesto at
http://dev.gentoo.org/~calchan/manifesto09/manifesto.html

Denis.

Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format

[Denis Dupeyron]

Hi Doug,

I just got to this thread, so sorry for entering the debate a bit
late. I find your propositions very interesting. In my manifesto [1] I
have proposed something significantly different which simply consists
in spinning the long discussions off the council meetings using more
focused groups (see the GLEP process and Experts paragraphs). I
personally think our two ideas are complementary and not competing
against each others.

Denis.

[1] http://dev.gentoo.org/~calchan/manifesto09/manifesto.html

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Denis Dupeyron]

On Mon, Jun 1, 2009 at 6:14 AM, Wernfried Haas a...@gentoo.org wrote:
 I'd like to counter-nominate you

Aww... That must hurt.

Denis.

Re: [gentoo-dev] GLEP 55 updated

[Denis Dupeyron]

2009/5/17 Piotr Jaroszyński pe...@gentoo.org:
 I have just updated GLEP 55 [1], hopefully making it a bit clearer.

Thanks a lot Piotr.

 Just FYI, my order of preference of solutions is:

 1. EAPI-suffixed ebuilds (obviously)
 2. EAPI in the filename with one-time extension change
 3. Easily fetchable EAPI inside the ebuild and one-time extension change

My preference goes to 3 with a .eb extension and EAPI on the first line.

 P.S. I know gentoo has other problems too, but it's the new and
 innovative stuff that makes working on Gentoo fun.

We need all the problem solving people we can get. And since we're all
volunteers there's no way we can force anybody to do anything. So,
sure, there may be a need for prioritizing problems, but one problem
solved is one less on the pile whatever it was.

Denis.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Joe !

How are you doing ? I've been meaning to call you but I've been busy
as hell due to the move. Do you want to have a beer or lunch sometime
?

Denis.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Oops, that was supposed to be sent to him directly. Sorry about that.

Denis.

On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron calc...@gentoo.org wrote:
 Joe !

 How are you doing ? I've been meaning to call you but I've been busy
 as hell due to the move. Do you want to have a beer or lunch sometime
 ?

 Denis.

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Denis Dupeyron]

On Sat, May 16, 2009 at 8:19 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 Because the way Gentoo works, any objection to a proposal, valid or not,
 whether or not it's already been addressed, has to be answered before a
 proposal gets anywhere. Thus, every time people post nonsense about
 GLEP 55, every post has to be answered or the Council goes there are
 unanswered objection, so we'll postpone it.

As usual you are extrapolating, but you're at least partly right.

If the author had documented these objections and the answers in the
glep then it would have made it possible to avoid most of what you
call the nonsense.  Anything buried on the lists, especially in such
threads as those discussing this glep, can't even remotely be
considered documented or addressed. The answers need to explain
everything, even what seems obvious or stupid, in a way that all devs
can understand. There is an attempt at doing this in the glep but it's
long on asserting and short on explaining, and does not cover it all
by far. As it is today the glep is a good draft but definitely not
voting material, which is certainly one of the reasons why voting it
is taking so long.

Piotr, the author, is currently away and has been mostly inactive for
more than a year now. I just talked to him on irc and reminded him
that as per glep 1 the GLEP author is responsible for building
consensus within the community and documenting dissenting opinions.
Which he is clearly not doing, at least anymore. Whatever the reasons
of his inactivity, the glep should be currently considered without a
champion and its ownership should be transferred as stipulated in glep
1.

Thus, I'm asking council to transfer the ownership of this glep, as
well as glep 54, and restrain from voting on them until the dissenting
opinions have been properly documented in each of them. Any new
champion will be fine with me, but I'm proposing, if you agree, that
you become the new champion as glep 1 doesn't require the champion to
be a developer. I do not doubt that the practical issues due to you
not being a developer will be worked around.

Denis.

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Denis Dupeyron]

On Sat, May 16, 2009 at 3:18 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 Except that at the last Council meeting, there were complaints that
 objections *had* been included and discussed in the GLEP, and claims
 that including such material made the GLEP less clear.

As unfortunate as it is, council members have the right to forget
about some of the details of some of our rules. And we have the right
to remind them about them.

 This is another of those issues where whichever way it's done, some
 people complain.

As long as you go by the rules those who complain about you doing so
are wrong. I've been told you were not the kind who was afraid of
being right.

So, what do you think about my proposition ?

Denis.

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Denis Dupeyron]

2009/5/4 Sérgio Almeida meph...@gmail.com:
 Please drop me a line here or at freenode if you have anything to add

All I have to add is thanks a lot. I wished other SoC students would
also introduce themselves and their project on their list.

Denis.

Re: [gentoo-dev] sandbox-1.3.x testing for stable

[Denis Dupeyron]

On Thu, Feb 12, 2009 at 7:56 AM, Mike Frysinger vap...@gentoo.org wrote:
 i'm feelin pretty good about the latest sandbox-1.3.x (little stiffy even).

little stiffy only ? That's OK, you're just getting old. Please come
see me for your free prescription and directions for use of the blue
pills.

 i'd like to have
 it so that when i meet my bus, the next sucker can pick up the project and run
 with it w/out making too much of a mess.

Your mom told me last night that she won't be taking you back. You're
stuck with us.

Denis.

Re: [gentoo-dev] new categories:

[Denis Dupeyron]

On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov geo...@gentoo.org wrote:
 Besides, in my opinion, the ability to see what's there in at least
 minimally categorized way without having to resort to using some special
 tools or going to some website is worht something. In this vain I was
 proposing going the opposite direction - to allow arbitrary nesting of
 categories, like going sci-math - sci/math and deeper (then packages would
 naturally be specified by FQEN - fully qualified ebuild names). Its not
 like tree walker would be the most complex part of code in portage..

Actually we'd want both tags and nesting. They don't address the same issue.

Arbitrary nesting of categories allows better management and storing
of ebuilds. It could also allow a meta-ebuild to depend on a whole
subcategory to ease maintenance of said meta-ebuild. It's more a
developer's feature.

Tags allow ebuilds to appear as being pertinent to more
(sub-)categories than just the one they're stored into. It may help
some of us locate packages they need in a better and/or faster way.
It's more of a user's feature.

Denis.

Re: [gentoo-dev] The Plethora of Patches

[Denis Dupeyron]

On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote:
[...]

Looks like you counted the number of files in the files/
subdirectories. Not all of these are patches. Also, you probably
forgot to count seds, as some of us use sed more than patches.

Oh, and like Jeremy was hinting, please contact QA. They need somebody like you.

Denis.

Re: [gentoo-dev] Re: Retirement

[Denis Dupeyron]

On Mon, Aug 11, 2008 at 1:18 AM, Nikos Chantziaras [EMAIL PROTECTED] wrote:
 They always say that stuff but never bother explaining what the direction
 they wish for actually is.  As a user I get the impression that there's some
 kind of evil Cabal.

Most of the Gentoo developer population is made of young males with a
natural tendency to overreaction and suboptimal communication skills
(and I'm not implying it's the case of the original poster). So, if I
were you, I wouldn't bother too much to read in between the lines of
these retirement messages.

Denis.

[gentoo-dev] Interesting article from the Times Magazine

[Denis Dupeyron]

From the Times Magazine :

http://www.nytimes.com/2008/08/03/magazine/03trolls-t.html

It mostly doesn't apply to us as a community (hopefully), but one
paragraph is especially interesting.

 In 1981, [Jon Postel] formulated what's known as Postel's Law: Be
conservative in what you do; be liberal in what you accept from
others. Originally intended to foster interoperability, the ability
of multiple computer systems to understand one another, Postel's Law
is now recognized as having wider applications. To build a robust
global network with no central authority, engineers were encouraged to
write code that could speak as clearly as possible yet listen to
the widest possible range of other speakers, including those who do
not conform perfectly to the rules of the road. The human equivalent
of this robustness is a combination of eloquence and tolerance — the
spirit of good conversation. Trolls embody the opposite principle.
They are liberal in what they do and conservative in what they
construe as acceptable behavior from others. You, the troll says, are
not worthy of my understanding; I, therefore, will do everything I can
to confound you. 

I'd add that trolling isn't always conscious, so everyone of us is
potentially somebody else's troll. My personal trick is that I always
re-read my posts as if they were addressed to myself on a bad hair
day.

Denis.

Re: [gentoo-dev] GLEP 55 - The Long Thread

[Denis Dupeyron]

On Tue, Jun 10, 2008 at 4:51 PM, Doug Goldstein [EMAIL PROTECTED] wrote:
 There's a lot to be said about being stuck in the grand design mindset.  I
 know many Gentoo, Portage, Exherbo, and Paludis developers are clearly
 coming to that point in their programming careers based on the comments on
 this thread and other threads. I would just like to caution everyone that
 they really need to get past this plateau in their programming careers and
 get on to the real mindset that matters in the future. The use case
 mindset.

Georges Clemenceau once said : War is too serious a matter to entrust
to military men. There surely is something to be said along these
lines about software design and programmers.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

[Denis Dupeyron]

On Thu, Jun 12, 2008 at 10:16 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 Are you seriously suggesting that the portage and pkgcore developers
 think that they should be able to release a package manager that claims
 to support an EAPI when it in fact doesn't?

Please stop your incessant and gratuitous insinuations.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Denis Dupeyron]

On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Mon, 09 Jun 2008 09:58:40 +0200
 Luca Barbato [EMAIL PROTECTED] wrote:
 Usually in this category you put everybody that disagrees with you,
 no matter the topic.

 And what does that tell you about the average level of response?

And what does that tell you about how well you fit this community ?

 So how, specifically, is PMS wrongly written, and why hasn't anyone
 who thinks so bothered to provide details?

See above.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Denis Dupeyron]

On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford [EMAIL PROTECTED] wrote:
 Before the flames start lets consider the Package Manager Specification
 (PMS) as an example. For this (very black and white) illustration,
 forget the council discussions to date and imagine that representatives
 of all three package managers went to council and said in unison
 We have agreed this specification.
 Are council really going to start picking holes in it and say no?

The council being our global technical lead, I can't see why they
wouldn't be allowed to reject an agreed package manager specification
or parts of it. If not, why bother electing them at all ? Not that I
think that would be a smart move, but that's a different discussion.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Nominations for council

[Denis Dupeyron]

On Tue, Jun 3, 2008 at 7:52 AM, Ferris McCormick [EMAIL PROTECTED] wrote:
 I think nominations are open.  I nominate
 rane
 welp
 zlin

Alright. Then I'll nominate all members of the current council. In
alphabetical order:
amne
betelgeuse
dberkholz
flameeyes
jokey
lu_zero
vapier

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] LaTeX documentation

[Denis Dupeyron]

On Tue, May 13, 2008 at 12:31 AM, Alexis Ballier [EMAIL PROTECTED] wrote:
  Yeah or maybe they dont need any unusual fonts; its probably sane to
  set VARTEXFONTS regardless. Probably it'd be worth adding a latex
  eclass that would just contain:
  VARTEXFONTS=${T}/fonts
  and inherit it from any package calling latex to avoid code duplication
  (like e.g. the mono eclass do).
  What do you think ?

As long as we can't easily remove eclasses I'd rather we don't make a
new one for such trivial needs. Unless I've missed something and they
can easily be removed nowadays.

Also, overloading the environment with global variables should be
avoided when possible. In that case I'd recommend the VARTEXFONTS
variable be passed with the emake command or whatever needs latex in
the ebuild.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Bug wrangling

[Denis Dupeyron]

On Mon, May 12, 2008 at 2:10 PM, Ferris McCormick [EMAIL PROTECTED] wrote:
  This only occured since we have no full-time
   bug-wrangler anymore.  Was anyone successful to contact him, yet?
  I am told he should be back sometime soon, like today.  Apparently
  someone is in contact with him.

That he comes back or not is of no importance to bug wrangling. Or at
least it should be. It is a mistake to solely rely on a developer for
such a task. Developers come and go without warning, he just proved
it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also,
one single developer handling this puts him/her in such a prominent
position that it is bad for him/her, our users, other developers and
the entire project. We had too many examples of this.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] New developer : Markus Duft (mduft)

[Denis Dupeyron]

It's my pleasure to introduce Markus Duft (mduft) as a new developer.
He will go among us under the name of mduft, and will work in the
Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that
means Gentoo on Win32.

Markus lives with his wife and daughter in Graz, Austria. He seems to
have many hobbies like reading fantasy novels, building
remote-controlled model planes, crashing remote-controlled model
planes, and last but not least, playing good old board games with
his wife. Err... Markus, we are a mature audience here, so no need to
call that good old board games, OK ?

He shares an office at work with Michael Haubenwallner (haubi), who is
strangely also a member of the Gentoo/alt project.

Please everybody, give a very warm welcome to mduft.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] New developer : Chris Henhawke (bunder)

[Denis Dupeyron]

It's my pleasure to introduce Chris Henhawke as a new developer among
us. He is a forums veteran where he goes under the name of bunder, and
has been a moderator there for about 9 months.

Chris lives in Hamilton, Ontario, and is a computer operator who does
maintenance and support. During the interrogation^Wreview, he wasn't
very talkative but did confess an addiction to the Gentoo forums and
smoking. His insistence to deny any other type of addiction or even
alien rape was at the very least suspicious. Unfortunately I was out
of pentothal (SpankY drank it all this morning for breakfast) so I
couldn't investigate any further.

Please everybody, give a very warm welcome to bunder.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Return of a developer : Josh Glover (jmglov)

[Denis Dupeyron]

It's my pleasure to announce the return of Josh Glover (jmglov) as a
Gentoo developer. Josh will resume his work on CJK and miscellaneous
packages.

Josh works as a Software Development Engineer for Amazon, developing
the mobile phone version of the retail website. He also serves as
Listmaster for the Tokyo Linux Users Group.

Josh is married and has a son. He comes from this promising new world
which knows of no borders. He is originally a USian, lives in Japan
and his wife is Bulgarian. He enjoys sports of all kinds, and is
especially addicted to football (that's soccer to you guys on the
other side of the pond). He likes being outdoors, reading, writing
(both fiction and essays), and traveling with his wife and son. All is
not lost though as he also enjoys drinking beer.

So please everybody give a warm re-welcome to Josh.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: gentoo-x86 commit in app-office/homebank: metadata.xml ChangeLog homebank-3.7.ebuild Manifest

[Denis Dupeyron]

On Tue, Apr 1, 2008 at 3:37 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
  eautoconf is enough.

Sorry about that. Fixed.

Denis.
���^�X�����(��j)b�b�

[gentoo-dev] Last rites: sci-libs/libgdgeda

[Denis Dupeyron]

# Denis Dupeyron [EMAIL PROTECTED] (22 Mar 2008)
# Not needed anymore. Was only used by old versions of
# sci-libs/libgeda which were just punted. Will be removed
# in 30 days.
sci-libs/libgdgeda
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Last rites: sci-electronics/lard

[Denis Dupeyron]

It finally happened. Last version was 5 years ago or so. From package.mask:

# Denis Dupeyron [EMAIL PROTECTED] (15 Mar 2008)
# Masked for removal in 30 days. Requires Tcl 8.3 which
# isn't in the tree anymore. See bugs 172356 and 173467.
sci-electronics/lard
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses

[Denis Dupeyron]

On Fri, Mar 14, 2008 at 8:14 AM, Rémi Cardona [EMAIL PROTECTED] wrote:
   - the gnome2 eclass now has a pkg_preinst, if you do multiple
  inherits, make sure that gnome2_pkg_preinst is called too. The
  _games_eclass_ is one of those.
[...]
  *Please* review these eclasses because with a simple grep, I could find
  over _1000_packages_ that inherited gnome2.eclass. But many more use
  other eclasses that depend on gnome2-utils.

In case that's of any help, the ugly thing below should lists all
eclasses that export pkg_preinst:

trillian ~ # for ECLASS_ECLASS in /usr/portage/eclass/*.eclass; do
echo ${ECLASS_ECLASS}:$(sed -e :a -e '/\\$/N; s/\\\n//; ta'
${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS); done | grep pkg_preinst |
cut -d . -f 1 | cut -d / -f 5
common-lisp
games
kde
kernel-2
kernel
linux-mod
mount-boot
myspell
mysql
perl-module
subversion
tetex-3
toolchain
vmware
x-modular

And the even uglier thing below should list all ebuilds that inherit a
gnome2* eclass and any of the above:

trillian ~ # for ECLASS in $(for ECLASS_ECLASS in
/usr/portage/eclass/*.eclass; do echo ${ECLASS_ECLASS}:$(sed -e :a -e
'/\\$/N; s/\\\n//; ta' ${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS);
done | grep pkg_preinst | cut -d . -f 1 | cut -d / -f 5); do qgrep -H
inherit  | grep  ${ECLASS} | grep  gnome2; done | sort | uniq
games-arcade/blobwars/blobwars-1.07.ebuild:inherit eutils gnome2-utils games
games-arcade/blobwars/blobwars-1.08.ebuild:inherit eutils gnome2-utils games
games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild:inherit
eutils games gnome2
games-board/gnono/gnono-1.9.1.ebuild:inherit autotools eutils gnome2-utils games
media-video/vlc/vlc-0.8.6e.ebuild:inherit eutils wxwidgets multilib
autotools toolchain-funcs gnome2 nsplugins
media-video/vlc/vlc-0.9.0_alpha20080117.ebuild:inherit eutils
wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4
flag-o-matic
media-video/vlc/vlc-0.9.0_alpha20080228.ebuild:inherit eutils
wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4
flag-o-matic
media-video/vlc/vlc-0.9.0_alpha20080309.ebuild:inherit eutils
wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4
flag-o-matic
net-im/pidgin/pidgin-2.3.1.ebuild:inherit flag-o-matic eutils
toolchain-funcs multilib perl-app gnome2
net-im/pidgin/pidgin-2.4.0.ebuild:inherit flag-o-matic eutils
toolchain-funcs multilib perl-app gnome2
sci-astronomy/celestia/celestia-1.4.1-r2.ebuild:inherit eutils
flag-o-matic gnome2 kde-functions autotools
sci-astronomy/celestia/celestia-1.5.0.ebuild:inherit eutils
flag-o-matic gnome2 kde-functions autotools

If you remove from that list vlc, pidgin and celestia which are false
positives, that leaves us:

games-arcade/blobwars/blobwars-1.07.ebuild
games-arcade/blobwars/blobwars-1.08.ebuild
games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild
games-board/gnono/gnono-1.9.1.ebuild

If I didn't screw up that shouldn't take long to check.

Denis.

Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses

[Denis Dupeyron]

On Fri, Mar 14, 2008 at 11:21 AM, Rémi Cardona [EMAIL PROTECTED] wrote:
   If you remove from that list vlc, pidgin and celestia which are false
   positives, that leaves us:

  Why are they false positives? They include the gnome2 eclass and other
  stuff, I guess they'll be affected too.

Because, for example celestia is found by a grep on the inherited kde
eclass that's triggered by inheriting kde-functions. And the latter
doesn't export pkg_preinst.

  /me wonders why gnome-games didn't appear in your list, which was the
  one ebuild I found out broke with the new eclass.

The answer is easy: I screwed up. I warned you. ;o) This is due to a
combination of the quoting I used in order to remove some of the false
positives and apparently something else. Here's the raw output without
quoting:

trillian ~ # for ECLASS in $(for ECLASS_ECLASS in
/usr/portage/eclass/*.eclass; do echo ${ECLASS_ECLASS}:$(sed -e :a -e
'/\\$/N; s/\\\n//; ta' ${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS);
done | grep pkg_preinst | cut -d . -f 1 | cut -d / -f 5); do qgrep -H
inherit | grep gnome2 | grep ${ECLASS} ; done | sort | uniq
app-i18n/scim-pinyin/scim-pinyin-0.5.91.ebuild:inherit kde-functions gnome2
dev-db/mysql-gui-tools/mysql-gui-tools-5.0_p12-r2.ebuild:inherit
gnome2 eutils flag-o-matic
dev-perl/gnome2-canvas/gnome2-canvas-1.002.ebuild:inherit perl-module
dev-perl/gnome2-gconf/gnome2-gconf-1.000.ebuild:inherit perl-module
dev-perl/gnome2-gconf/gnome2-gconf-1.031.ebuild:inherit perl-module
dev-perl/gnome2-gconf/gnome2-gconf-1.032.ebuild:inherit perl-module
dev-perl/gnome2-gconf/gnome2-gconf-1.040.ebuild:inherit perl-module
dev-perl/gnome2-gconf/gnome2-gconf-1.043.ebuild:inherit perl-module
dev-perl/gnome2-perl/gnome2-perl-1.023.ebuild:inherit perl-module
dev-perl/gnome2-perl/gnome2-perl-1.040.ebuild:inherit perl-module
dev-perl/gnome2-perl/gnome2-perl-1.041.ebuild:inherit perl-module
dev-perl/gnome2-print/gnome2-print-0.94.ebuild:inherit perl-module
dev-perl/gnome2-print/gnome2-print-1.000.ebuild:inherit perl-module
dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.041.ebuild:inherit perl-module
dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.060.ebuild:inherit perl-module
dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.061.ebuild:inherit perl-module
dev-perl/gnome2-wnck/gnome2-wnck-0.11.ebuild:inherit perl-module eutils
dev-perl/gnome2-wnck/gnome2-wnck-0.12.ebuild:inherit perl-module eutils
dev-perl/gnome2-wnck/gnome2-wnck-0.13.ebuild:inherit perl-module eutils
dev-perl/gnome2-wnck/gnome2-wnck-0.14.ebuild:inherit perl-module eutils
dev-util/devhelp/devhelp-0.16.1.ebuild:inherit toolchain-funcs gnome2
dev-util/devhelp/devhelp-0.17.ebuild:inherit toolchain-funcs gnome2 python
dev-util/devhelp/devhelp-0.18.ebuild:inherit toolchain-funcs gnome2 python
dev-util/devhelp/devhelp-0.19.ebuild:inherit toolchain-funcs gnome2 python
games-arcade/blobwars/blobwars-1.07.ebuild:inherit eutils gnome2-utils games
games-arcade/blobwars/blobwars-1.08.ebuild:inherit eutils gnome2-utils games
games-arcade/monkey-bubble/monkey-bubble-0.4.0.ebuild:inherit
autotools eutils gnome2
games-board/gamazons/gamazons-0.83.ebuild:inherit gnome2
games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild:inherit
eutils games gnome2
games-board/gnono/gnono-1.9.1.ebuild:inherit autotools eutils gnome2-utils games
games-board/pioneers/pioneers-0.11.3-r1.ebuild:inherit eutils gnome2
games-board/teg/teg-0.11.2.ebuild:inherit gnome2
games-kids/gmult/gmult-4.2.ebuild:inherit gnome2
games-kids/gmult/gmult-5.3.ebuild:inherit gnome2
games-mud/gnome-mud/gnome-mud-0.10.7.ebuild:inherit gnome2 games
games-puzzle/atomix/atomix-2.14.0.ebuild:inherit gnome2
games-puzzle/glightoff/glightoff-1.0.0.ebuild:inherit gnome2
games-puzzle/gtetrinet/gtetrinet-0.7.11.ebuild:inherit gnome2 games
games-puzzle/skoosh/skoosh-2.5.0.ebuild:inherit gnome2
games-strategy/gwp/gwp-0.4.0-r2.ebuild:inherit eutils gnome2
gnome-extra/drwright/drwright-0.17.ebuild:inherit gnome2 flag-o-matic
toolchain-funcs
gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.12.0.ebuild:inherit
gnome2
gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.14.0.ebuild:inherit
gnome2
gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.20.0.ebuild:inherit
gnome2
gnome-extra/gnome-games/gnome-games-2.18.2.1.ebuild:inherit games
eutils gnome2 autotools
gnome-extra/gnome-games/gnome-games-2.18.2.1.ebuild:# make sure games
is inherited first so that the gnome2
gnome-extra/gnome-games/gnome-games-2.20.3.ebuild:inherit games eutils
gnome2 python autotools virtualx
gnome-extra/gnome-games/gnome-games-2.20.3.ebuild:# make sure games is
inherited first so that the gnome2
media-gfx/comix/comix-3.6.3.ebuild:inherit toolchain-funcs gnome2
media-gfx/comix/comix-3.6.4.ebuild:inherit toolchain-funcs gnome2
media-video/jubler/jubler-3.4.0.ebuild:inherit gnome2 eutils
java-pkg-2 java-utils-2 java-ant-2 toolchain-funcs
media-video/jubler/jubler-3.4.1.ebuild:inherit gnome2 eutils
java-pkg-2 java-ant-2 toolchain-funcs

Re: [gentoo-dev] Help offered - Portage tree

[Denis Dupeyron]

On Thu, Mar 13, 2008 at 12:35 AM, Fabio Erculiani
[EMAIL PROTECTED] wrote:
  After having discussed with one of your dev about it, he suggested me
  to ask here looking for a mentor. If there's anything I can do, I'm
  ready.

On Thu, Mar 13, 2008 at 12:57 AM, Fabio Erculiani
[EMAIL PROTECTED] wrote:
  I know what you mean, but take into account I don't have much time
  left for the reporting. What I ask is [...]  getting me able to fix stuff

So you don't have time to file bugs but you would have time to fix
them ? Interesting...

In any case, we require users to have a consistent history of helping
the project before they are considered for recruitment. What you are
doing for Sabayon is great but it can't be taken into account. Please
find below some information that may be useful to get you started.

There are many ways you can help. Two good ways to start helping out
are proposing solutions for bugs [1] and contributing to an overlay
[2] like Sunrise for example [3]. There is more information on how to
get involved with overlay development at [4]. When your contributions
become significant enough, developers may contact you (or you can
contact them). You may also want to have a look at the staffing needs
page [5].

You will need to read the Gentoo Documentation Resources [6], and more
specifically the Gentoo Developer Handbook [7] and the Gentoo
Development Guide [8].

Another way to help, especially for non-technical projects, is to
contact people directly [9]. Be aware that they can be away though, so
be patient, try others on the same project, and finally get back to us
in case you fail to reach anybody.

Do not hesitate to contact recruiters in the future in case you need
more information.

Best regards,
Denis.

[1] http://bugs.gentoo.org/
[2] http://overlays.gentoo.org/
[3] http://overlays.gentoo.org/proj/sunrise/
[4] http://www.gentoo.org/proj/en/overlays/userguide.xml#doc_chap3
[5] http://www.gentoo.org/proj/en/devrel/staffing-needs/
[6] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev
[7] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
[8] http://devmanual.gentoo.org/
[9] http://www.gentoo.org/proj/en/index.xml?showlevel=2
-- 
gentoo-dev@lists.gentoo.org mailing list