Re: [gentoo-dev] Is Gentoo dying?

[Dale]

Alec Warner wrote:

On Sat, Apr 3, 2010 at 6:48 PM, Joshua Saddler  wrote:
   

On Sat, 03 Apr 2010 11:16:32 +0200
Tobias Scherbaum  wrote:

 

- Our formerly outstanding documentation still is somewhat maintained,
but that's it. I haven't seen any new additions (both to our docs, but
also to our docs-team) for years. People are constantly asking for a
documentation wiki, but ...
   

Thanks for sh**ting on my efforts. There are lots of visible changes, and I 
make a point of getting the word out when a new guide turns up in /doc/. I blog 
about the new docs I add, and I spend awhile working with contributors to make 
sure we get good stuff out there and that it's constantly updated -- the 
Openbox guide Nate Zachary wrote comes to mind. I'm also always working with 
developers who are writing docs in their spare time, coaching 'em through the 
process, assisting with GuideXML, taking patches, *and* creating patches and 
updates for devs who are posting documents in /proj/ and in their personal 
devspace. But I guess that doesn't mean anything to you.

Oh yes, and I spend hours each week constantly updating docs based on the 
inflow of bugs, forum reports, and I constantly re-read each one and improve 
stuff where I can on-the-fly. Not everything has a bug tracker, but the end 
result is still a visible difference in the stuff you see on the website.
 

You need to take comments less personally.  If there is a constant
stream of updates then point him at your cia comment log or similar;
no need to pick a fight about it.  Certainly when compared to our
documentation of old I think the rate of new documents and document
updates is likely less now than it was then.  Perhaps what Tobias is
trying to convey is that he wants more people to contribute and write
documents.

   
 

- Website redesign - we had a contest some years ago, got a winner,
someone started to adapt the design and somewhat that project fall
asleep.
   

We've added quite a bit, with the automated feeds and whatnot. And the sidebar 
stuff. And the revamping of our releases page, and lots of other areas. I've 
added lots of stuff; I guess you just haven't noticed.
 

Lots of content sure; not so much on the design side.  I personally
like our website and I think the design is fine (no need to put too
much effort into it IMHO.) but if other folks want to spend time on it
I'm not going to say no.  I still think something like taking what we
have and doing the redesign on non-gentoo stuff and then being like
'yo dawg I heard you like websites so i put a website in your website
so you can browse while you browse' or similar is the way to iterate.

   
 

- Speaking of our website, PR ... guess there's nothing more to add.
   

Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all 
the work I did to organize SCALE and go out and make a difference with our 
(potential) users by talking with them doesn't mean anything. All the 
word-of-mouth I've done with folks before and after SCALE, even my coworkers 
must not count for much.

* * *

I would have expected such this kind of negative, abrasive email from a user, 
but to see such a sensationalist letter coming from a developer is 
disappointing, to say the least. I expect better from you. Because whether you 
realize it or not, your email can only come across as denigrating my efforts, 
and everyone else who puts in hard work on (actually visible!) changes.

Your email was inflammatory and offensive, but not in the way that motivates me 
to do more or do anything different. It came across as extremely demotivational.

 

Well it certainly hi-lights one area; that we often fail at
communicating what we are doing.  The pr team has some great people on
it who do great stuff (not including me; I tend to do as little as
possible.)  Maybe Tobias is blissfully unaware of the efforts of the
team.  Maybe he thinks the team can do better.  I don't see him saying
'well the pr team sucks balls!'  I see him saying 'well the pr team is
very quiet.'  I don't think that is too far from the truth; although
certainly pr@ is active it doesn't look like it from anyone not on
that alias (SCALE aside.)

-A

   


As a user, I see both sides of this.  I rarely go to the actual Gentoo 
site and mostly read the home page when I do.  I may go to a link once 
in a while that is posted on the mailing list but that is about it.


I think what I see from the OP is that he feels there needs to be more 
people involved in several areas.  I don't know you Joshua but if you 
are doing a lot of the docs by yourself or with just a few helpers, I 
think you need more help.  The pages I do see are really good and I read 
other people using other distros commend Gentoo on its documentation.  
It just that maybe you need more help so that even more things can be 
done.  Look at it this way, what would happen if you had twice the help 
you have now and where would Gentoo's docs 

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Jesus Rivero (Neurogeek)]

On Sat, Apr 3, 2010 at 6:27 PM, Sebastian Pipping  wrote:
> On 04/04/10 00:30, Jesus Rivero (Neurogeek) wrote:
>>    Sebastian, count me in.
>
> Cool!
>
>
>> I believe this sort of stuff, or small
>> parts of what you are mentioning, was done in the newsletter. I
>> believe this is something real nice we should put somewhere public.
>
> Can you elaborate on that?  I'm not sure what what you refer to.
>

   Yep. Take for instance this issue of GMN [1],  here you can find
some bugzie statistics like bugs assigned to teams/devs, bugs
resolutions and other cool things.

>
>
> Sebastian
>
>
[1] http://www.gentoo.org/news/en/gmn/20080121-newsletter.xml#bugs-stats

--
Jesus Rivero (Neurogeek)
Gentoo Python Team

Re: [gentoo-dev] Is Gentoo dying?

[Alec Warner]

On Sat, Apr 3, 2010 at 6:48 PM, Joshua Saddler  wrote:
> On Sat, 03 Apr 2010 11:16:32 +0200
> Tobias Scherbaum  wrote:
>
>> - Our formerly outstanding documentation still is somewhat maintained,
>> but that's it. I haven't seen any new additions (both to our docs, but
>> also to our docs-team) for years. People are constantly asking for a
>> documentation wiki, but ...
>
> Thanks for sh**ting on my efforts. There are lots of visible changes, and I 
> make a point of getting the word out when a new guide turns up in /doc/. I 
> blog about the new docs I add, and I spend awhile working with contributors 
> to make sure we get good stuff out there and that it's constantly updated -- 
> the Openbox guide Nate Zachary wrote comes to mind. I'm also always working 
> with developers who are writing docs in their spare time, coaching 'em 
> through the process, assisting with GuideXML, taking patches, *and* creating 
> patches and updates for devs who are posting documents in /proj/ and in their 
> personal devspace. But I guess that doesn't mean anything to you.
>
> Oh yes, and I spend hours each week constantly updating docs based on the 
> inflow of bugs, forum reports, and I constantly re-read each one and improve 
> stuff where I can on-the-fly. Not everything has a bug tracker, but the end 
> result is still a visible difference in the stuff you see on the website.

You need to take comments less personally.  If there is a constant
stream of updates then point him at your cia comment log or similar;
no need to pick a fight about it.  Certainly when compared to our
documentation of old I think the rate of new documents and document
updates is likely less now than it was then.  Perhaps what Tobias is
trying to convey is that he wants more people to contribute and write
documents.

>
>> - Website redesign - we had a contest some years ago, got a winner,
>> someone started to adapt the design and somewhat that project fall
>> asleep.
>
> We've added quite a bit, with the automated feeds and whatnot. And the 
> sidebar stuff. And the revamping of our releases page, and lots of other 
> areas. I've added lots of stuff; I guess you just haven't noticed.

Lots of content sure; not so much on the design side.  I personally
like our website and I think the design is fine (no need to put too
much effort into it IMHO.) but if other folks want to spend time on it
I'm not going to say no.  I still think something like taking what we
have and doing the redesign on non-gentoo stuff and then being like
'yo dawg I heard you like websites so i put a website in your website
so you can browse while you browse' or similar is the way to iterate.

>
>> - Speaking of our website, PR ... guess there's nothing more to add.
>
> Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess 
> all the work I did to organize SCALE and go out and make a difference with 
> our (potential) users by talking with them doesn't mean anything. All the 
> word-of-mouth I've done with folks before and after SCALE, even my coworkers 
> must not count for much.
>
> * * *
>
> I would have expected such this kind of negative, abrasive email from a user, 
> but to see such a sensationalist letter coming from a developer is 
> disappointing, to say the least. I expect better from you. Because whether 
> you realize it or not, your email can only come across as denigrating my 
> efforts, and everyone else who puts in hard work on (actually visible!) 
> changes.
>
> Your email was inflammatory and offensive, but not in the way that motivates 
> me to do more or do anything different. It came across as extremely 
> demotivational.
>

Well it certainly hi-lights one area; that we often fail at
communicating what we are doing.  The pr team has some great people on
it who do great stuff (not including me; I tend to do as little as
possible.)  Maybe Tobias is blissfully unaware of the efforts of the
team.  Maybe he thinks the team can do better.  I don't see him saying
'well the pr team sucks balls!'  I see him saying 'well the pr team is
very quiet.'  I don't think that is too far from the truth; although
certainly pr@ is active it doesn't look like it from anyone not on
that alias (SCALE aside.)

-A

Re: [gentoo-dev] Is Gentoo dying?

[Joshua Saddler]

On Sat, 03 Apr 2010 11:16:32 +0200
Tobias Scherbaum  wrote:
 
> - Our formerly outstanding documentation still is somewhat maintained,
> but that's it. I haven't seen any new additions (both to our docs, but
> also to our docs-team) for years. People are constantly asking for a
> documentation wiki, but ... 

Thanks for sh**ting on my efforts. There are lots of visible changes, and I 
make a point of getting the word out when a new guide turns up in /doc/. I blog 
about the new docs I add, and I spend awhile working with contributors to make 
sure we get good stuff out there and that it's constantly updated -- the 
Openbox guide Nate Zachary wrote comes to mind. I'm also always working with 
developers who are writing docs in their spare time, coaching 'em through the 
process, assisting with GuideXML, taking patches, *and* creating patches and 
updates for devs who are posting documents in /proj/ and in their personal 
devspace. But I guess that doesn't mean anything to you.

Oh yes, and I spend hours each week constantly updating docs based on the 
inflow of bugs, forum reports, and I constantly re-read each one and improve 
stuff where I can on-the-fly. Not everything has a bug tracker, but the end 
result is still a visible difference in the stuff you see on the website.

> - Website redesign - we had a contest some years ago, got a winner,
> someone started to adapt the design and somewhat that project fall
> asleep.

We've added quite a bit, with the automated feeds and whatnot. And the sidebar 
stuff. And the revamping of our releases page, and lots of other areas. I've 
added lots of stuff; I guess you just haven't noticed.

> - Speaking of our website, PR ... guess there's nothing more to add. 

Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all 
the work I did to organize SCALE and go out and make a difference with our 
(potential) users by talking with them doesn't mean anything. All the 
word-of-mouth I've done with folks before and after SCALE, even my coworkers 
must not count for much.

* * *

I would have expected such this kind of negative, abrasive email from a user, 
but to see such a sensationalist letter coming from a developer is 
disappointing, to say the least. I expect better from you. Because whether you 
realize it or not, your email can only come across as denigrating my efforts, 
and everyone else who puts in hard work on (actually visible!) changes.

Your email was inflammatory and offensive, but not in the way that motivates me 
to do more or do anything different. It came across as extremely demotivational.


signature.asc
Description: PGP signature

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Ben de Groot]

On 4 April 2010 01:37, Sebastian Pipping  wrote:
> Btw was it Fedora having moved from MoinMoin to MediaWiki?
> I remember something like that, could be erring though.

You are right. Here are some relevant links a quick Google search
turned up for me:

https://fedorahosted.org/fedora-infrastructure/ticket/31
http://fedoraproject.org/wiki/Infrastructure/WikiRequirements
https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00085.html

It looks like their main concerns were performance, both in terms of
scalability and search (the default internal MoinMoin search engine
is notoriously slow). Makes you wonder how Ubuntu manage to use
MoinMoin apparently succesfully.

The conclusion (in my eyes) is that MediaWiki is likely to be the
best choice and easiest to set up for our purposes. Unless someone
comes with another proposal and good arguments to go with something
else, I'd say we should stick to MediaWiki.


>>> Here's another idea:
>>> The German Wikipedia uses a concept called "sighted revisions". If you
>>> visit an article without logging in you will see the latest sighted
>>> revision, as an identified user you can also view the latest revision.
>>
>> That's an interesting idea, which we should consider.
>
> I'm not sure if that a thing to go for.  Drawbacks:
> - More work  (whereas we could use more manpower already)
> - New bottlenecks
>
> Couldn't we just make two big "namespaces"
>
>  'devs'        -- Developers only
>  'registered'  -- Full edit access to any registered user
>
> in the same wiki and have pages be in either namespace, reflecting the
> namespace in the page name or path somehow?
>
> I expect that to be
> - easy to implement
> - providing a good mix of openness and quality control

Actually this came up in earlier discussions as well, and there was
an in my opinion valid concern about the status and quality of user
generated documentation, especially if we open it to the wider public
as we are proposing here. I think it would be a good thing to give
certain revisions of a certain page an offical "stamp of approval".
It would probably be educational to see how other distros handle
that. Does anyone want to volunteer to find that out?

>> GuideXML documents are often experienced as an unnecessary
>> barrier.
>
> I think you should clearly state again that this is not gonna replace
> GuideXML, just migrate a few use cases where a wiki fits better.
> This is what you aim for, right?

A wiki can fulfill several purposes for us:

1. Easy collaboration among devs, for brainstorming, developing new
   documentation, assembling upcoming meeting agendas, and so on
   [for which there currently is not really any obvious place]
2. A place for users to collaborate on and contribute to documentation
   [which is currently covered by the unofficial wiki]
3. A place to host and maintain our existing documentation
   [which is currently in GuideXML]

For me the most important and immediate need is number 1. This is the
need that came up several times recently, and the push for me to try
to make this happen.

I am not pushing for our existing documentation to be migrated into a
wiki at this point. But I think that once the place is there, and it
functions well, it would be the obvious next step to do so. As I said
before, the barrier to contributing and maintaining documentation is
much higher in the case of GuideXML, so it doesn't really make sense
to keep that around when we have a better solution.

I know there are people who do not agree with me on this last point,
which is why I see that as a later and separate goal. We can cross
that bridge when we come to it.

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sebastian Pipping]

On 04/04/10 02:11, Sylvain Alain wrote:
> I hope that you will not migrate the GuideXML inside the wiki, because
> it's so simple to write documentations inside a wiki and right now the
> unofficial Gentoo Wiki is clean and simple.
> 
> If you want to have registered users and contributors, then you need to
> use a standard syntaxe wiki.

I didn't plan to, no.

On a side not please only quote parts of mails that you actually refer
to.  It means less scrolling and better context for everybody.



Sebastian

RE: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sylvain Alain]

> Date: Sun, 4 Apr 2010 01:37:03 +0200
> From: sp...@gentoo.org
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
> 
> On 04/03/10 16:46, Ben de Groot wrote:
> >> I propose to use MediaWiki.
> > 
> > As I said in my other post, MediaWiki and MoinMoin should, in my
> > opinion, be on our shortlist to consider.
> 
> My vote on MediaWiki, too.
> 
> (I do like DokuWiki better for personal things but mediaWiki seems the
> best choice for a project this large.)
> 
> Btw was it Fedora having moved from MoinMoin to MediaWiki?
> I remember something like that, could be erring though.
> 
> 
> >> Here's another idea:
> >> The German Wikipedia uses a concept called "sighted revisions". If you
> >> visit an article without logging in you will see the latest sighted
> >> revision, as an identified user you can also view the latest revision.
> > 
> > That's an interesting idea, which we should consider.
> 
> I'm not sure if that a thing to go for.  Drawbacks:
> - More work  (whereas we could use more manpower already)
> - New bottlenecks
> 
> Couldn't we just make two big "namespaces"
> 
>   'devs'-- Developers only
>   'registered'  -- Full edit access to any registered user
> 
> in the same wiki and have pages be in either namespace, reflecting the
> namespace in the page name or path somehow?
> 
> I expect that to be
> - easy to implement
> - providing a good mix of openness and quality control
> 
> 
> > GuideXML documents are often experienced as an unnecessary
> > barrier.
> 
> I think you should clearly state again that this is not gonna replace
> GuideXML, just migrate a few use cases where a wiki fits better.
> This is what you aim for, right?
> 
> 
> 
> Sebastian
> 


I hope that you will not migrate the GuideXML inside the wiki, because it's so 
simple to write documentations inside a wiki and right now the unofficial 
Gentoo Wiki is clean and simple.

If you want to have registered users and contributors, then you need to use a 
standard syntaxe wiki.

Sylvain aka d2_racing

  
_
Got a phone? Get Hotmail & Messenger for mobile!
http://go.microsoft.com/?linkid=9724464

Re: [gentoo-dev] Is Gentoo dying?

[Sebastian Pipping]

On 04/03/10 18:03, Alec Warner wrote:
>  - date of last commit: Gentoo is fast moving and packages that
> haven't had commits since 200{4,5,6} are probably old, unmaintained
> and may not even compile or run.
>  - date of last listed maintainer commit versus last commit:
> Basically if the maintainer hasn't touched the ebuild in a while but
> someone else (herd members?) have, the metadata.xml is probably out of
> date.

Have the result of that analysis collected somewhere?


> The above are all pretty easy to do with the data in the tree.  Some
> other useful ideas might be:
>  - compare open bugs for the package, when was the last bug for a
> package closed (bugs data kinda sucks for this)

Right, but we can get that working.  I have a regex to get package
names from bug titles around that works well.  All we need to do is fix
all bug titles ever to contain package names: Could take a whole bugday
or two :-)


>  - for a given package in a herd, check the version in the tree
> against freshmeat or similar to see how far behind it is (I think
> someone wrote something for this already, exherbo?)

That's a larger project.  GSOC ideas should contain such thing.


>  - check imlate to see if keywording is behind (is the maintainer
> filing stablereqs?)

While you mention that: it's the first time I hear a maintainer should
do that.  if so can you raise awareness of it and explain the what and
why in another thread on gentoo-dev?



Sebastian

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sebastian Pipping]

Ben, good to see you driving this process!  Thanks!



Sebastian

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sebastian Pipping]

On 04/03/10 16:36, Ben de Groot wrote:
> This also raises the question of license. Our current documentation
> mostly uses the CC-BY-SA license, while the unoffical wiki adds a
> non-commercial restriction. By choosing one license over the other
> we will make copy-pasting content from the source that has the other
> license, as far as I can see, illegal. I would say that interchange
> possibilities with our existing official documentation has priority.

Good point.  I agree that a restriction against commercial usage does
not work for us.



Sebastian

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sebastian Pipping]

On 04/03/10 16:46, Ben de Groot wrote:
>> I propose to use MediaWiki.
> 
> As I said in my other post, MediaWiki and MoinMoin should, in my
> opinion, be on our shortlist to consider.

My vote on MediaWiki, too.

(I do like DokuWiki better for personal things but mediaWiki seems the
best choice for a project this large.)

Btw was it Fedora having moved from MoinMoin to MediaWiki?
I remember something like that, could be erring though.


>> Here's another idea:
>> The German Wikipedia uses a concept called "sighted revisions". If you
>> visit an article without logging in you will see the latest sighted
>> revision, as an identified user you can also view the latest revision.
> 
> That's an interesting idea, which we should consider.

I'm not sure if that a thing to go for.  Drawbacks:
- More work  (whereas we could use more manpower already)
- New bottlenecks

Couldn't we just make two big "namespaces"

  'devs'-- Developers only
  'registered'  -- Full edit access to any registered user

in the same wiki and have pages be in either namespace, reflecting the
namespace in the page name or path somehow?

I expect that to be
- easy to implement
- providing a good mix of openness and quality control


> GuideXML documents are often experienced as an unnecessary
> barrier.

I think you should clearly state again that this is not gonna replace
GuideXML, just migrate a few use cases where a wiki fits better.
This is what you aim for, right?



Sebastian

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Sebastian Pipping]

On 04/04/10 00:42, Alec Warner wrote:
> I will help with scripting; but probably not much else.

Just right, there will be lots of scripting :-)

The current script dumping groud is hosted here:
http://git.goodpoint.de/?p=gentoo-bug-heartbeat.git;a=summary



Sebastian

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Sebastian Pipping]

On 04/04/10 00:30, Jesus Rivero (Neurogeek) wrote:
>Sebastian, count me in.

Cool!


> I believe this sort of stuff, or small
> parts of what you are mentioning, was done in the newsletter. I
> believe this is something real nice we should put somewhere public.

Can you elaborate on that?  I'm not sure what what you refer to.



Sebastian

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Alec Warner]

On Sat, Apr 3, 2010 at 3:24 PM, Sebastian Pipping  wrote:
> I'm calling for participation in a new team working on things around
> reports, bug analysis, heartbeat tracking in Gentoo:

I will help with scripting; but probably not much else.

-A

>
>
> Goals
> =
> - help track the heartbeat/breath of Gentoo
>    (bugs fixed per day, bug distribution per herd, ..)
>
> - point to problems we may be overlooking in Gentoo
>    (letting numbers speak to us and listening to them)
>
> - help to prioritize when distributing available resources
>    (specific calls for help, people switching teams, ..)
>
>
> Data we will be working with
> 
> - The Bug database  (XML from Bugzilla, ..)
> - Package tree history  (VCS logs, ..)
> - User setup details  (gentoo-smolt, ..)
> - ..
>
>
> Concrete tasks
> ==
> - bugday.g.o re-write  (work in progress)
> - work on association between bugs and packages
>  (for all bugs, not just bugday ones)
> - get real numbers on how much active manpower we have
>
>
> People
> ==
> These poeple are in de facto:
> - deathwing00
> - sping
> - 
>
>
> If this is stuff which
> - you have time for
> - you are good at
>
> please join us!
>
>
>
> Sebastian
>
>
>

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Jesus Rivero (Neurogeek)]

On Sat, Apr 3, 2010 at 5:54 PM, Sebastian Pipping  wrote:
> I'm calling for participation in a new team working on things around
> reports, bug analysis, heartbeat tracking in Gentoo:
>
>
> Goals
> =
> - help track the heartbeat/breath of Gentoo
>    (bugs fixed per day, bug distribution per herd, ..)
>
> - point to problems we may be overlooking in Gentoo
>    (letting numbers speak to us and listening to them)
>
> - help to prioritize when distributing available resources
>    (specific calls for help, people switching teams, ..)
>
>
> Data we will be working with
> 
> - The Bug database  (XML from Bugzilla, ..)
> - Package tree history  (VCS logs, ..)
> - User setup details  (gentoo-smolt, ..)
> - ..
>
>
> Concrete tasks
> ==
> - bugday.g.o re-write  (work in progress)
> - work on association between bugs and packages
>  (for all bugs, not just bugday ones)
> - get real numbers on how much active manpower we have
>
>
> People
> ==
> These poeple are in de facto:
> - deathwing00
> - sping
> - 

   Sebastian, count me in. I believe this sort of stuff, or small
parts of what you are mentioning, was done in the newsletter. I
believe this is something real nice we should put somewhere public.

>
>
> If this is stuff which
> - you have time for
> - you are good at
>
> please join us!
>
>
>
> Sebastian
>

   Best regards,

--
Jesus Rivero (Neurogeek)
Gentoo Python Team

[gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Sebastian Pipping]

I'm calling for participation in a new team working on things around
reports, bug analysis, heartbeat tracking in Gentoo:


Goals
=
- help track the heartbeat/breath of Gentoo
(bugs fixed per day, bug distribution per herd, ..)

- point to problems we may be overlooking in Gentoo
(letting numbers speak to us and listening to them)

- help to prioritize when distributing available resources
(specific calls for help, people switching teams, ..)


Data we will be working with

- The Bug database  (XML from Bugzilla, ..)
- Package tree history  (VCS logs, ..)
- User setup details  (gentoo-smolt, ..)
- ..


Concrete tasks
==
- bugday.g.o re-write  (work in progress)
- work on association between bugs and packages
  (for all bugs, not just bugday ones)
- get real numbers on how much active manpower we have


People
==
These poeple are in de facto:
- deathwing00
- sping
- 


If this is stuff which
- you have time for
- you are good at

please join us!



Sebastian

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

[Alec Warner]

2010/4/3 Gilles Dartiguelongue :
> Le samedi 03 avril 2010 à 12:50 +0300, Petteri Räty a écrit :
>> I don't think later is valid resolution. If there's a valid bug it just
>> means it's never looked at again. If the bug is not valid then a
>> different resolution should be used. So what do you think about
>> disabling later?
>
> You are trying to remove a valid status for a case that has been badly
> managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are
> for the simple reason they will be done later and no other status would
> be fine expect REJECTED maybe, but we don't want to say that to the face
> of the reported like this do we ?

Thats why I think a bugzilla LATER keyword is just as effective; but
people doing bugzie searches would no longer exclude these types of
bugs on accident.

-A

>
> --
> Gilles Dartiguelongue 
> Gentoo
>

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

[Gilles Dartiguelongue]

Le samedi 03 avril 2010 à 12:50 +0300, Petteri Räty a écrit :
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later?

You are trying to remove a valid status for a case that has been badly
managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are
for the simple reason they will be done later and no other status would
be fine expect REJECTED maybe, but we don't want to say that to the face
of the reported like this do we ?

-- 
Gilles Dartiguelongue 
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée

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

[Sebastian Pipping]

On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote:
>Maybe if we could find the way to make the knowledge found in
> quizzes be more "exciting" to new devs, then we could still have a
> strong recruitment process without the burden of completing the
> quizzes. So, what I propose is to transform the "quizzes" part of the
> process into a list of tasks the prospect should complete in order to
> gain the necessary ability to "pass". This ability could be measured
> in points or just by task completed.

Nice idea!


>This doesn't address them either. But I really don't think this is
> the main issue that causes the problem :) So I guess these questions
> could remain in one "easy" quiz.

While you mention the non-technical part: I imagine a gain out of moving
that part to the very end of recruiting: to when people know they almost
made it.  Especially putting up these questions first, turns some people
away too: The problem is they get the wrong impression that being will
be about these boring things later on, but it isn't.

Betelgeuse, what do you think?



Sebastian

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

[Sebastian Pipping]

On 04/03/10 16:05, Petteri Räty wrote:
> http://www.gentoo.org/proj/en/devrel/staffing-needs/
> 
> I don't know if developers know that this page is autogenerated from
> individual project pages these days so it's easy for any developer to
> get stuff there.

Has anyone every tried to read that page?
It's such a pain to that I doubt it.



Sebastian

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Maciej Mrozowski]

On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote:
> Shouldn't we fix that buildsystem then?  Do you have an example of a
> package/buildsystem that does that?
"We" already do, the thing is that maybe we don't have to.
https://bugs.gentoo.org/show_bug.cgi?id=240323
From top of my head: python having issues with sys-libs/db as well as some 
packages with readline.
 
> > It would indeed. Now when I think about it, moving stuff to preserved
> > library dir could be just done - provided it's possible - along with
> > fixing/setting DT_RPATH's in reverse runtime dependencies. This way no
> > system-wide LIBRARY_PATH's would be necessary.
> > Is it possible? Mike?
> No, unless you somehow make sure you reserve space for this, by e.g.
> setting a bogus rpath entry at buildtime.  If you want to go that route,
> you probably want to look at the Prefix' binutils-config wrapper that
> already calls the linker with added rpath arguments.  Afterwards you can
> use chrpath to set it to the correct location.  Will get messy with the
> vdb though, but if Portage's doing it, it can probably be dealt with.
Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they 
allow such DT_RPATH operations? It should be probably also restricted for 
binary-only packages.

On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote:
> Don't fix the hack. Remove the preserve libs "feature", make the PMs
> check for rdeps per default before unmerging things.
This will only prevent creating orphans of uninstalled libraries, what about 
upgraded ones when SOVERSION has been bumped (the most common case)? Besides I 
can already imagine PMS-related discussion regarding "make the PMs check for 
rdeps per default before unmerging things" - thx but no thx.

> Slot libraries where needed, slot dep operators (EAPI 4) will help.
Again, you suggest to SLOT every library that happened to bump SOVERSION. It's 
unrealistic. Besides library should be slotted when it's API changes, for 
source based distributions it's not needed for ABI changes - let's not confuse 
those two. Also excessive slotting increases probability of breaking library 
discovery mechanisms in various build systems (not everyone uses pkg-config).

> And if that doesn't work out we need a separate var to give the PM a hint 
when API/ABI breakages happen (such that the PM knows when to re-install the 
rev deps).
It needs PMS amended and thus GLEP. Please submit a GLEP item for this if you 
see it fit.
Anyway, as explained in OT, it's not a problem of package manager dependencies 
system but issue with broken/not smart build systems - no dependency tree 
magic will solve this issue.

-- 
regards
MM

Re: [gentoo-dev] Re: List of User projects

[Michał Górny]

On Sat, 3 Apr 2010 15:31:20 -0400
Jacob Godserv  wrote:

> On Sat, Apr 3, 2010 at 15:30, Jacob Godserv 
> wrote:
> > Last I checked, Ubuntu is going to adopt it. How's that for a
> > compliment? :) http://brainstorm.ubuntu.com/idea/18452/
> 
> Sorry for the extra e-mail, but I should clarify:
> "Ubuntu is seriously considering adopting it."

No offence but '-15' doesn't sounds as serious as '344' for upstart.

-- 
Best regards,
Michał Górny





signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: List of User projects

[Jacob Godserv]

On Sat, Apr 3, 2010 at 15:30, Jacob Godserv  wrote:
> Last I checked, Ubuntu is going to adopt it. How's that for a compliment? :)
> http://brainstorm.ubuntu.com/idea/18452/

Sorry for the extra e-mail, but I should clarify:
"Ubuntu is seriously considering adopting it."

-- 
Jacob

"For then there will be great distress, unequaled
from the beginning of the world until now — and never
to be equaled again. If those days had not been cut
short, no one would survive, but for the sake of the
elect those days will be shortened."

Are you ready?

Re: [gentoo-dev] Re: List of User projects

[Jacob Godserv]

On Sun, Mar 28, 2010 at 10:27, Duncan <1i5t5.dun...@cox.net> wrote:
> What other distributions (*BSD, Linux, or...) do you know that use
> openrc?  IOW, I know it was designed to be distribution independent, but I
> don't know of anyone else using it (well, other than Gentoo derivatives),
> and Gentoo certainly influenced it.

Last I checked, Ubuntu is going to adopt it. How's that for a compliment? :)
http://brainstorm.ubuntu.com/idea/18452/

-- 
Jacob

"For then there will be great distress, unequaled
from the beginning of the world until now — and never
to be equaled again. If those days had not been cut
short, no one would survive, but for the sake of the
elect those days will be shortened."

Are you ready?

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Alex Legler]

On Sat, 3 Apr 2010 15:19:20 +0200, Ben de Groot 
wrote:

> Okay, so it seems a lot of people do want a wiki. So let's see what
> we can do to make that happen.
> 

I created a Wiki page (oh, the irony) to track the results of this
thread in the Gentoo eV wiki:
http://gentoo-ev.org/wiki/Official_Gentoo_wiki

Feel free to edit the page or email me changes.

Alex

-- 
Alex Legler | Gentoo Security / Ruby
a...@gentoo.org | a...@jabber.ccc.de


signature.asc
Description: PGP signature

Re: [gentoo-dev] Is Gentoo dying?

[Jacob Godserv]

On Sat, Apr 3, 2010 at 05:38, Petteri Räty  wrote:
> My perception from the outside is also that it's sometimes hard to offer
> help. So if we now that we are busy then let's try to embrace others
> doing the work.

This is also what I have observed. I think Gentoo needs appear to be
much more focused on how to let people contribute, rather than how to
filter/monitor contributions. There's too much discussion about how
something is bad and why it shouldn't happen in the documentation and
mailing list, and too little about what can be done to make sure the
contribution, idea, or user(s) get included.

One specific example I can give is the developer status itself. Gentoo
developers are responsible for everything, including maintenance. This
is not a bad thing, if it's part of a greater developer ecosystem. All
successful projects I've observed survive on half of the work, at
least, being done by volunteers, and the developers are there to
simply review the work before it is applied.

As far as I can tell, creating an inviting atmosphere, in which the
developers listen and react to the community, is essential to the
continued survival of Gentoo.

Yea, this one of those long-term things that sounds awesome in theory
but is hard to do right. However, I think the sooner ideas like these
are discussed and possibly implemented, the sooner we don't have
threads like these in the mailing list. I am encouraged that Gentoo
developers are considering how to regroup themselves.

-- 
Jacob

"For then there will be great distress, unequaled
from the beginning of the world until now — and never
to be equaled again. If those days had not been cut
short, no one would survive, but for the sake of the
elect those days will be shortened."

Are you ready?

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Alex Legler]

On Sat, 03 Apr 2010 19:56:53 +0100, George Prowse
 wrote:

> Does mediawiki have captcha ability?
> 

Yes, there are plug-ins provide that functionality. [1]

Let's get a general Wiki concept done before talking about spam
remedy in detail, though. :)


[1] http://www.mediawiki.org/wiki/Manual:Combating_spam#Captcha
-- 
Alex Legler | Gentoo Security / Ruby
a...@gentoo.org | a...@jabber.ccc.de


signature.asc
Description: PGP signature

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

[Jesus Rivero (Neurogeek)]

Hi guys,

On Sat, Apr 3, 2010 at 9:10 AM, Ben de Groot  wrote:
> On 3 April 2010 13:33, Richard Freeman  wrote:
>> I really think that the Gentoo recruitment process needs improvement. Right
>> now it seems like a LOT of effort is required both to become a Gentoo dev
>> and to help somebody become a Gentoo dev.  That means we have great people,
>> but not many of them.
>
> I agree. So what can we do to improve this process?
>
> I myself am not fond of the quizzes, and from what I've seen most
> recruits find them tedious as well. It can be quite demotivating,
> maybe because it reminds one too much of highschool or something.
> I took a long time myself to finish them, and that wouldn't have
> been necessary, as my mentors ensured me I was ready to become a
> dev. And I see the same thing happening with some of my own recruits.
> They can be ready, but  just find the quizzes a chore.
>

   I understand that quizzes serve a purpose and IMHO, are a good way
to face common issues when writing ebuilds. On the other hand, I
understand that quizzes are lengthy and could become a blocker in the
recruitment process (I have met at least two prospects drop out due to
the inability to finish them, being for lack of time to concentrate or
because they got bored by the chore.)

   Maybe if we could find the way to make the knowledge found in
quizzes be more "exciting" to new devs, then we could still have a
strong recruitment process without the burden of completing the
quizzes. So, what I propose is to transform the "quizzes" part of the
process into a list of tasks the prospect should complete in order to
gain the necessary ability to "pass". This ability could be measured
in points or just by task completed.

   Then it gets interesting for them and for us. Those tasks could be
to tackle problems from the quizzes but in real ebuilds (prepared by
us for this, much as when recruiters ask us to clean some ebuild) or
could be tasks created by teams to specifically address common issues
in their domain if the prospect is trying to join them or shows an
interest on helping this specific team.

> Of course this doesn't address the organizational side of things, so
> we need to come up with something else for that.

   This doesn't address them either. But I really don't think this is
the main issue that causes the problem :) So I guess these questions
could remain in one "easy" quiz.

> --
> Ben de Groot
> Gentoo Linux Qt project lead developer
>
>

  If I can be of any assistance in this, I'll gladly help.

--
Jesus Rivero (Neurogeek)
Gentoo Python Team

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

[Tiziano Müller]

Am Samstag, den 03.04.2010, 12:50 +0300 schrieb Petteri Räty:
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? I would like to avoid things like this:
Yes, please remove it. Keep it simple and stupid. LATER means it's not
resolved and is as such not a valid resolution.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[George Prowse]

On 03/04/2010 18:40, AllenJB wrote:

On 03/04/10 14:40, Dror Levin wrote:

On Sat, Apr 3, 2010 at 16:19, Ben de Groot  wrote:

2 - maintainers
===

Who is volunteering for maintaining the wiki? We need editors and
moderators, people who look out for quality control and take care of
spam removal. So let's get together a team. I'm sure if we ask on the
forums we'll get some users interested as well.

I volunteer. Spam shouldn't be that much of an issue if editing is
restricted to registered users, but it is a good idea to have a team
of moderators similar to the one that exists for the forums (of course
users can take part of it as well as developers).


Most of the spam on gentoo-wiki.com comes from registered accounts.
Requiring registration does not stop most wiki spam. Very little of the
spam comes in from unregistered editors.


On gentoo-wiki.com we currently use a combination of anti-spam tools,
which seems to work best. The main 2, from a day-to-day administration
view are the url blacklist and manual removal of spam and associated
accounts.

You could require email authentication first, but I believe this is
unlikely to reduce spam - creating a setup that automatically deals with
account verification emails is trivial and throwaway accounts are too
easy to get hold of.

In addition I believe it would reduce the amount of positive
contribution more than it reduces spam - I believe people often want to
make quick, small corrections / additions and telling them to "come back
later" is going to be the same as telling them "go away".

I would highly recommend using MediaWiki as, at least from my
experience, it's the most prevalent of the wiki setups available. While
this may bring some disadvantages (number of spam attempts (tho I'm
nottotally convinced you'll get less than any other web form out there),
etc), it also brings the advantages of being well developed with a wide
variety of plugins, lots of wiki syntax guides / tutorials you can point
users to and a wide userbase with existing knowledge of the syntax.

AllenJB


Does mediawiki have captcha ability?

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Tiziano Müller]

Am Samstag, den 03.04.2010, 12:38 +0200 schrieb Maciej Mrozowski:
> Problem
> 
> ..is known, let me summarize briefly.
> 
> Uninstalling packages providing libraries, without checking reverse runtime 
> dependencies of those packages leaves their dependencies unsatisfied 
> (packages 
> with broken executables and/or shared libs).
> Some package managers try their best not to remove said libraries, yet 
> allowing packages to be removed.
> Those orphaned libraries cause problems[1] as build systems of some other 
> packages being (re)installed afterwards pick them up and abuse those orphaned 
> libraries. (we don't like orphans abused, we prefer them... "gone").
> 
> Solution
> 
> Now, I suppose there are some ideas how to make orphaned libraries not go in 
> a 
> way. Basically then need to be available for system, but hidden for "emerge".
> 
> There is opt-out suggestion[2], unfortunately it does not provide any info 
> how 
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, 
> maybe - as Brian Harring suggested - sandbox could be used to somehow "hide" 
> preserved libraries or preserved library directory from ebuild environment 
> (preserved library directory a'ka "purgatory" - libs could be moved there 
> when 
> considered orphaned).
> 
> Opt-in suggestion is as follows:
> 1. Use some library path (read by ld loader from environment) and export it 
> globally to environment pointing it to preserved library directory.
> 2. During "emerge", unset environment variable corresponding to said 
> preserved 
> library directory - orphans are no longer located.
> Attached patch for glibc (2.11, but should apply to any other glibc around) 
> and uClibc (this one is not tested but should work as well) that makes ld 
> loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
> 
> (LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be 
> safely mangled.. on the second though it can - one could filter out preserved 
> library paths from it during "emerge").
> 
> Thoughts?

Don't fix the hack. Remove the preserve libs "feature", make the PMs
check for rdeps per default before unmerging things. Slot libraries
where needed, slot dep operators (EAPI 4) will help. And if that doesn't
work out we need a separate var to give the PM a hint when API/ABI
breakages happen (such that the PM knows when to re-install the rev
deps).


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

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

[Petteri Räty]

On 04/03/2010 08:54 PM, Alec Warner wrote:
> On Sat, Apr 3, 2010 at 10:10 AM, Petteri Räty  wrote:
>> On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote:
>>> On 03-04-2010 09:50, Petteri Räty wrote:
 I don't think later is valid resolution. If there's a valid bug it just
 means it's never looked at again. If the bug is not valid then a
 different resolution should be used. So what do you think about
 disabling later?
>>>
>>> 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.
>>>
>>
>> What is the benefit with this instead of keeping it open until they find
>> time? I doubt for example bug days take LATER resolved bugs into account
>> or user are likely to search for them when trying to find something to
>> work on.
>>
> 
> I would vote for a LATER KEYWORD instead of a resolution.  Really what
> I would want when searching is to know what set of bugs I should be
> working on short-term versus bugs I'd consider more like
> 'project-work'.  LATER is typically stuff that is:
>  - too big to do now, but may get covered in some kind of sprint or fixit.
>  - blocking on something else (EAPI, upstream revbump, etc.)
>  - too hard to do now, but may be easier in the future (kind of like
> #2, but possibly unrelated)
> 

For #2 you can use dependencies. I have no problem adding a keyword as
it keeps the bugs open.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

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

[Alec Warner]

On Sat, Apr 3, 2010 at 10:10 AM, Petteri Räty  wrote:
> On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote:
>> On 03-04-2010 09:50, Petteri Räty wrote:
>>> I don't think later is valid resolution. If there's a valid bug it just
>>> means it's never looked at again. If the bug is not valid then a
>>> different resolution should be used. So what do you think about
>>> disabling later?
>>
>> 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.
>>
>
> What is the benefit with this instead of keeping it open until they find
> time? I doubt for example bug days take LATER resolved bugs into account
> or user are likely to search for them when trying to find something to
> work on.
>

I would vote for a LATER KEYWORD instead of a resolution.  Really what
I would want when searching is to know what set of bugs I should be
working on short-term versus bugs I'd consider more like
'project-work'.  LATER is typically stuff that is:
 - too big to do now, but may get covered in some kind of sprint or fixit.
 - blocking on something else (EAPI, upstream revbump, etc.)
 - too hard to do now, but may be easier in the future (kind of like
#2, but possibly unrelated)

The point is I'm looking for a set of bugs that are possible to fix
now; and currently closing some types of bugs as RESOLVED:LATER does
this for me.

-A

>>> I would like to avoid things like this:
>>> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
>>
>> You've chosen a terrible example as in that case the resolution is
>> accurate. The forums team didn't find that issue to be a priority and
>> doesn't have the time to deal with it. As the bug was open for years
>> without any progress, we chose to close it as LATER. If someone else
>> wants to step up and take care of it, great.
>>
>
> Yeah there's probably better examples out there but that's what sparked
> me to think about this so I went with it. From a recruiter perspective
> the need to tie to LDAP is still there so the issue isn't gone.
>
> Regards,
> Petteri
>
>

Re: [gentoo-dev] Portage, kernel sources and setgid

[Zac Medico]

On 04/03/2010 10:11 AM, Michał Górny wrote:
> Hello,
> 
> I am using umask 027 on my Gentoo boxes, and setgid bit set on a few
> directories crucial to userpriv-enabled merges. This way, I do not have
> to worry about running e.g. layman through 'sg' or similar tools, as
> all newly-created files inherit portage group ownership, and
> newly-created directories inherit the setgid bit.
> 
> I would like to be able to use similar solution for compiled kernel
> sources, i.e. through setting the setgid bit on /usr/src. But in fact
> it is impossible as portage forces setting it's own permissions on all
> installed files, thus newly-installed kernel sources do not inherit the
> parent group ownership nor the setgid bit.
> 
> Now the question is: should such behaviour be considered really correct
> and necessary? In my opinion, if user sets setuid/setgid on a parent
> directory, shklee knows what shklee is doing and emerge should not
> override this system-specific ownership inheritance.
> 

Your issue seems somewhat related to this bug:

  http://bugs.gentoo.org/show_bug.cgi?id=141619

My first inclination is to use configuration file for stuff like
this, since it's not really possible to distinguish ad hoc
permission modifications done by the user from incorrect permissions
that are due to other reasons such as faulty ebuilds. It would
probably also be a good idea to record file permissions in
/var/db/pkg/*/*/CONTENTS, so that we'd have some way know when
permissions differ from those initially set by the ebuild, and a way
to detect collisions in directory permissions between 2 different
ebuilds that install files in the same directory.
-- 
Thanks,
Zac

Re: [gentoo-dev] are hardened-sources maintained?

[Piotr Jaroszyński]

On 1 April 2010 15:43, "Paweł Hajdan, Jr."  wrote:
> Of course that would mean getting included in
> hardened-ker...@gentoo.org, but I guess it's the easiest part.

Yes, you can do it yourself:
woodpecker ~ $ echo $USER >> /var/mail/alias/misc/hardened-kernel

-- 
Best Regards
Piotr Jaroszyński

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[AllenJB]

On 03/04/10 14:40, Dror Levin wrote:
> On Sat, Apr 3, 2010 at 16:19, Ben de Groot  wrote:
>> 2 - maintainers
>> ===
>>
>> Who is volunteering for maintaining the wiki? We need editors and
>> moderators, people who look out for quality control and take care of
>> spam removal. So let's get together a team. I'm sure if we ask on the
>> forums we'll get some users interested as well.
> I volunteer. Spam shouldn't be that much of an issue if editing is
> restricted to registered users, but it is a good idea to have a team
> of moderators similar to the one that exists for the forums (of course
> users can take part of it as well as developers).
> 
Most of the spam on gentoo-wiki.com comes from registered accounts.
Requiring registration does not stop most wiki spam. Very little of the
spam comes in from unregistered editors.


On gentoo-wiki.com we currently use a combination of anti-spam tools,
which seems to work best. The main 2, from a day-to-day administration
view are the url blacklist and manual removal of spam and associated
accounts.

You could require email authentication first, but I believe this is
unlikely to reduce spam - creating a setup that automatically deals with
account verification emails is trivial and throwaway accounts are too
easy to get hold of.

In addition I believe it would reduce the amount of positive
contribution more than it reduces spam - I believe people often want to
make quick, small corrections / additions and telling them to "come back
later" is going to be the same as telling them "go away".

I would highly recommend using MediaWiki as, at least from my
experience, it's the most prevalent of the wiki setups available. While
this may bring some disadvantages (number of spam attempts (tho I'm
nottotally convinced you'll get less than any other web form out there),
etc), it also brings the advantages of being well developed with a wide
variety of plugins, lots of wiki syntax guides / tutorials you can point
users to and a wide userbase with existing knowledge of the syntax.

AllenJB

[gentoo-dev] Portage, kernel sources and setgid

[Michał Górny]

Hello,

I am using umask 027 on my Gentoo boxes, and setgid bit set on a few
directories crucial to userpriv-enabled merges. This way, I do not have
to worry about running e.g. layman through 'sg' or similar tools, as
all newly-created files inherit portage group ownership, and
newly-created directories inherit the setgid bit.

I would like to be able to use similar solution for compiled kernel
sources, i.e. through setting the setgid bit on /usr/src. But in fact
it is impossible as portage forces setting it's own permissions on all
installed files, thus newly-installed kernel sources do not inherit the
parent group ownership nor the setgid bit.

Now the question is: should such behaviour be considered really correct
and necessary? In my opinion, if user sets setuid/setgid on a parent
directory, shklee knows what shklee is doing and emerge should not
override this system-specific ownership inheritance.

-- 
Best regards,
Michał Górny





signature.asc
Description: PGP signature

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

[Petteri Räty]

On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote:
> On 03-04-2010 09:50, Petteri Räty wrote:
>> I don't think later is valid resolution. If there's a valid bug it just
>> means it's never looked at again. If the bug is not valid then a
>> different resolution should be used. So what do you think about
>> disabling later? 
> 
> 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.
> 

What is the benefit with this instead of keeping it open until they find
time? I doubt for example bug days take LATER resolved bugs into account
or user are likely to search for them when trying to find something to
work on.

>> I would like to avoid things like this:
>> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
> 
> You've chosen a terrible example as in that case the resolution is
> accurate. The forums team didn't find that issue to be a priority and
> doesn't have the time to deal with it. As the bug was open for years
> without any progress, we chose to close it as LATER. If someone else
> wants to step up and take care of it, great.
> 

Yeah there's probably better examples out there but that's what sparked
me to think about this so I went with it. From a recruiter perspective
the need to tie to LDAP is still there so the issue isn't gone.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is Gentoo dying?

[Matti Bickel]

Alec Warner wrote:
> The above are all pretty easy to do with the data in the tree.  Some
> other useful ideas might be:
>  - compare open bugs for the package, when was the last bug for a
> package closed (bugs data kinda sucks for this)

An additional search: last touched by assignee between never and now-30
days.

I also just discovered that awesome query interface our bugzilla has.

Can we publish a data set query where new bugs are plotted against
closed bugs (maybe add already open bugs) for each herd? I'll try to
come up with a query if no one else is faster with this.

If the difference between new and closed bugs in a 30 days time period
is over a given threshold (say 15% of the current open bugs), this might
be a herd that needs help.

Maybe we can come up with more insightful bugzie searches. And maybe
something like that exists already and i've failed finding it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is Gentoo dying?

[Alec Warner]

On Sat, Apr 3, 2010 at 7:59 AM, Tobias Scherbaum  wrote:
> Am Samstag, den 03.04.2010, 15:40 +0100 schrieb Roy Bamford:
>> First, we need some metrics - the first step to controlling anything is
>> to measure it.
>
> So, how do you want to measure those metrics? I for one can't think of a
> useful algorithm which helps to identify understaffed or orphaned areas.
> Sure, one might take a look at the number of packages compared with open
> bugs for example - but in the end that still won't give you some useful
> metrics.

When I was a treecleaner I tended to look at a few things; note that
because we enforce very little in the tree these are basically just a
set of heuristics.

 - metadata.xml: how many packages are maintainer-{needed,wanted}.
Does not apply to all herds because some herds fix anything in their
herd.
 - date of last commit: Gentoo is fast moving and packages that
haven't had commits since 200{4,5,6} are probably old, unmaintained
and may not even compile or run.
 - date of last listed maintainer commit versus last commit:
Basically if the maintainer hasn't touched the ebuild in a while but
someone else (herd members?) have, the metadata.xml is probably out of
date.

The above are all pretty easy to do with the data in the tree.  Some
other useful ideas might be:
 - compare open bugs for the package, when was the last bug for a
package closed (bugs data kinda sucks for this)
 - for a given package in a herd, check the version in the tree
against freshmeat or similar to see how far behind it is (I think
someone wrote something for this already, exherbo?)
 - check imlate to see if keywording is behind (is the maintainer
filing stablereqs?)

Metrics do not have to be perfect (they never are...) but they may
shine some light on some areas of the tree that need staff.

-A


>
> If someone has a feeling somewhere helping hands are missing or an area
> is orphaned - that's the best "metrics" we can get.
>
> - Tobias
>
> --
> Praxisbuch Nagios
> http://www.oreilly.de/catalog/pbnagiosger/
>
> https://www.xing.com/profile/Tobias_Scherbaum
>

Re: [gentoo-dev] spin (spinroot.com) license

[Zac Medico]

On 04/03/2010 04:16 AM, "Paweł Hajdan, Jr." wrote:
> I'd like to add a package for spin to the tree (it's used at several
> universities, including mine and Caltech).
> 
> However, it's not straightforward. The basic license is for educational
> purposes only.
> 
> Here are my suggestions how to implement that.
> 
> /usr/portage/licenses/spin-educational with the following content:
> 
> Copyright  (c) 1989-2006 Lucent Technologies, Bell Labs
> Extensions (c) 2006-2009 NASA/JPL California Institute of Technology
> All Rights Reserved. For educational purposes only.
> No guarantee whatsoever is expressed or implied by
> the distribution of this code.
> 
> /usr/portage/licenses/spin-commercial with the content pasted from
> http://www.spinroot.com/spin/spin_license.html
> 
> And then in the ebuild:
> 
> LICENSE="|| ( spin-educational spin-commercial )"
> 
> Are there any license groups these should be added to?

They both look like they belong in the EULA group to me. The
educational one is an EULA in the sense the the user must agree to
use it only for educational purposes.
-- 
Thanks,
Zac

RE: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Sylvain Alain]

Hi everyone, Gentoo-Quebec already use MediaWiki and I can say that for the 
spam prevention measures it can be pretty simple :

For a new user, he needs to
send an email to a specific adress, alos he needs to have a valid
account on the forum just to be sure that he is not a spambot. So basically, 
only members of the forum can write something on the wiki.

For the rest, if you need a moderator or a writer on that project, I can help :P

Finally, I recommend that on the Wiki team, the best team should be : 
experimented users (power users), users,moderators and Gentoo Devs for specific 
areas. 


> Date: Sat, 3 Apr 2010 10:04:38 -0400
> From: guy.fonta...@videotron.qc.ca
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
> 
> Hi !
> 
> I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some 
> other members also do. I maintain CSS, examples and wrote almost 60% of the 
> stuff.
> 
> If you think I could help, please just let me know. 
> 
> The wiki :
> 
> http://gentoo-quebec.org/wiki/index.php/Accueil
> 
> Guy Fontaine
> 
  
_
Hotmail & Messenger are available on your phone. Try now.
http://go.microsoft.com/?linkid=9724461

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

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03-04-2010 09:50, Petteri Räty wrote:
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? 

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.

> I would like to avoid things like this:
> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21

You've chosen a terrible example as in that case the resolution is
accurate. The forums team didn't find that issue to be a priority and
doesn't have the time to deal with it. As the bug was open for years
without any progress, we chose to close it as LATER. If someone else
wants to step up and take care of it, great.

> Not applicable to the bug above but in general our social contract says:
> "We will not hide problems"

When you mark something as LATER because you don't have the time nor
find it a priority, you're not "hidding a problem". If someone uses that
resolution to hide problems, that person should be warned of the above.

> Regards,
> Petteri
> 

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLt13jAAoJEC8ZTXQF1qEPVbkP/2rux+TdVxLUDl1WjKC4IOwT
sVLs4slXFYxIsd5TxlaxA9/nkPFVUiUtzmCwNHdYRLIxQpbJk2FHhHzfeuT6h2nF
0n29V9mRobXvMxUAIKNuu8F8VEoKPouKBF64rPoOgqv4KG1bmnAvmS1VzxMMj9Gi
RO2Zt9xlb1rDzy1/fTLUCT0LKvuMZvPv5ZxXBfqDZT9fD4bEFH63RfVnOaEGU/X4
7MMju7MhSxpZxpea/jTIXSEnblH/lbjwM4aYunrFvGq/O4i1A45SS2iASqN2xsmj
FCVzzigCFD0htI7pvJkCgW560UPX102jHUMxEIlMluoBsT+LvgiAVca9vySfLKF+
CuQEGpLaXFpWyJjHMW9tCKdEFZkSV7oTC1vuCwOXU5beHhHA7AHqR0j1ADTJIQa7
d2GOHkKRrrUSqmwRL4gjOj1C8LHkHdpVKAg8Ni6HTdd2aAQEGb4R+0mCZM8zJ19r
zQpCqYI4zpKOhkvYRQf7VtdgmvRbw5KX8qjjRi4DDy8+larFYLc1GcYDpuGp2W56
MfYkZy6EgAdwmKyrFlknxkYXk64FWtsWNSzTMW6Wi/Xu9OiL9ArAbgO8d2DdRL3T
p4acejrSxHbGL3wXMsOOOVkUf2rLjA1XTukgk4VK4fEKg0ITa8RIewRZRQtS0WyF
odz4rA5x2k2HwLvgA52I
=XTLq
-END PGP SIGNATURE-

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Nathan Zachary]

On 03/04/10 08:40, Dror Levin wrote:
> On Sat, Apr 3, 2010 at 16:19, Ben de Groot  wrote:
>   
>> 1 - requirements
>> 
>>
>> In order to choose the best possible wiki implementation, we need to
>> know our requirements. So what features do you think are essential or
>> good to have? What syntax would we prefer to use?
>>
>> I myself am a big fan of reStructuredText, which is quite simple,
>> easy to pick up, highly readable, and has a good featureset. Plus, it
>> is also reusable in other contexts (it is for example widely used in
>> documentation of Python libraries). MediaWiki, MoinMoin and Trac have
>> support for rst.
>>
>> Some others:
>>
>> - active upstream (bug fixes, security updates)
>> - free open source software
>> - ACLs
>> - spam prevention measures
>> - attachments (to upload screenshots for example)
>> - feeds
>> 
> There is currently a wiki for gentoo at gentoo-wiki.com, which is
> running MediaWiki, so it would be easiest to transfer the content if
> we were to run the same software. Now, this doesn't mean we should be
> limited by their actions, but it seems to me like the best choice for
> other reasons as well. Its syntax is probably the most well known,
> thanks to Wikipedia. Its upstream is active, it apparently scales and
> performs pretty well, it's GPL, supports translations/localization,
> feeds, attachments, etc.
> I'm sure many other alternatives are as qualified, so this is most
> likely a personal preference issue. As such, lets just agree on
> something that works and is widespread and go with that and avoid all
> the bikeshedding.
>
>   
>> 2 - maintainers
>> ===
>>
>> Who is volunteering for maintaining the wiki? We need editors and
>> moderators, people who look out for quality control and take care of
>> spam removal. So let's get together a team. I'm sure if we ask on the
>> forums we'll get some users interested as well.
>> 
> I volunteer. Spam shouldn't be that much of an issue if editing is
> restricted to registered users, but it is a good idea to have a team
> of moderators similar to the one that exists for the forums (of course
> users can take part of it as well as developers).
>
>   
>> 3 - edit access
>> ===
>>
>> Do we keep to the original "free for all" model, with all the spam
>> that includes, or do we go with registered users only? I think the
>> latter is the smarter option. I also think we will want to mark
>> certain pages "official" and lock down editing rights.
>> 
> IMO it's best if only registered users can edit (but registering
> should be easy, no bugs to file or anything, just sign up and use
> immediately). This will probably prevent most kinds of spam and allow
> for much better tracking of editing and history, allow for banning,
> etc. without closing the wiki up too much.
> Also, from what I could tell, this is how others are managing their
> wiki as well (Arch and Amarok, for example).
>
> Dror Levin
>
>   
I would enjoy working on a wiki as well as the fora, so I'm volunteering
as well.

--Nathan Zachary

Re: [gentoo-dev] Is Gentoo dying?

[Tobias Scherbaum]

Am Samstag, den 03.04.2010, 15:40 +0100 schrieb Roy Bamford:
> First, we need some metrics - the first step to controlling anything is 
> to measure it.

So, how do you want to measure those metrics? I for one can't think of a
useful algorithm which helps to identify understaffed or orphaned areas.
Sure, one might take a look at the number of packages compared with open
bugs for example - but in the end that still won't give you some useful
metrics.

If someone has a feeling somewhere helping hands are missing or an area
is orphaned - that's the best "metrics" we can get.

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Ben de Groot]

On 3 April 2010 16:30, Alex Legler  wrote:
> I propose to use MediaWiki.

As I said in my other post, MediaWiki and MoinMoin should, in my
opinion, be on our shortlist to consider.

> I'd be interested in helping out with the backend part, i.e. setting up
> and maintaining the Wiki software and the needed extensions,
> user management and support.

Thanks, that would certainly be helpful.

> Here's another idea:
> The German Wikipedia uses a concept called "sighted revisions". If you
> visit an article without logging in you will see the latest sighted
> revision, as an identified user you can also view the latest revision.

That's an interesting idea, which we should consider.


>> Is there anything else we should consider before getting started?
>>
>
> Maybe we should discuss what goals we want to reach with a Wiki.
>
> One thing is offering user-contributed documentation, of course.
> But do we also want a developer wiki? Or offer per-project realms in our
> wiki? Or $something_else?

Good suggestion. I think we would want to accommodate both
user-contributed documentation and developer needs. For example,
recently the need arose to have a wiki page for GSoC ideas.
Projects may want to use it as well. I find myself using the wiki
at gitorious.org (where we also host our overlay) for purposes of
the Qt herd. It would also be handy for developing new documentation
(it would have helped for the LXDE guide, or the Qt4 ebuild
development howto) as well as keeping existing documentation up to
date. GuideXML documents are often experienced as an unnecessary
barrier.

What else do we want it for and how would that impact organization?

-- 
Ben de Groot
Gentoo Linux Qt project lead developer

Re: [gentoo-dev] Is Gentoo dying?

[Roy Bamford]

On 2010.04.03 10:16, Tobias Scherbaum wrote:
> Hell no, but ...
> 
> We have lots of quite understaffed areas, to sum up in a positive 
> way.
> Summing it up the negative way one might say, we have lots of areas
> were
> users might get the idea Gentoo already is dead.
> 
> For example:
[snip lots of anecdotal evidence]
> - Tobias
> 
> -- 
> Praxisbuch Nagios
> http://www.oreilly.de/catalog/pbnagiosger/
> 
> https://www.xing.com/profile/Tobias_Scherbaum
> 

First, we need some metrics - the first step to controlling anything is 
to measure it.

Once we have some metrics, we can prioritise.

With priorities, we can identify gaps in our resource pool (not just 
people) and attempt to fill them with recruiting.

Maybe thats a bugday topic ?
An open day for users who would like to become contributors and 
contributors who would like to become devs.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees



pgpDuruiRdPW9.pgp
Description: PGP signature

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Ben de Groot]

On 3 April 2010 16:12, Tobias Scherbaum  wrote:
> Am Samstag, den 03.04.2010, 16:40 +0300 schrieb Dror Levin:
>> There is currently a wiki for gentoo at gentoo-wiki.com, which is
>> running MediaWiki, so it would be easiest to transfer the content if
>> we were to run the same software.
>
> This should happen (if at all) on a per article basis imho. Having the
> option to do so (if we want to) is a plus we should consider, though.

This also raises the question of license. Our current documentation
mostly uses the CC-BY-SA license, while the unoffical wiki adds a
non-commercial restriction. By choosing one license over the other
we will make copy-pasting content from the source that has the other
license, as far as I can see, illegal. I would say that interchange
possibilities with our existing official documentation has priority.

> Mediawiki sounds like what we want probably, mainly because it seems to
> be the most popular one.

I don't think that in itself is a very good argument.

> Besides that:
> - Ubuntu and Debian are using MoinMoin
> - Fedora and OpenSUSE use Mediawiki

I think we should consider the pros and cons of both these solutions.
Does anyone have any links to the considerations that led these
distros to make the choice they did?

> In addition I'd like to establish a Wiki team with both developers and
> experienced users who are able to review Wikipages (specifically every
> revision of a page) and tag those pages as reviewed.

I agree this is a good idea.

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Alex Legler]

On Sat, 3 Apr 2010 15:19:20 +0200, Ben de Groot 
wrote:

> 1 - requirements
> 
> 
> In order to choose the best possible wiki implementation, we need to
> know our requirements. So what features do you think are essential or
> good to have? What syntax would we prefer to use?
> 
> [...]
> 
> - active upstream (bug fixes, security updates)
> - free open source software
> - ACLs
> - spam prevention measures
> - attachments (to upload screenshots for example)
> - feeds
> 

I propose to use MediaWiki.

It fulfills all of your points above. Plus the software is proven in
large scale deployments and the security track record is alright.

> 
> 
> 2 - maintainers
> ===
> 
> Who is volunteering for maintaining the wiki? We need editors and
> moderators, people who look out for quality control and take care of
> spam removal. So let's get together a team. I'm sure if we ask on the
> forums we'll get some users interested as well.

I'd be interested in helping out with the backend part, i.e. setting up
and maintaining the Wiki software and the needed extensions,
user management and support.

> 
> 
> 3 - edit access
> ===
> 
> Do we keep to the original "free for all" model, with all the spam
> that includes, or do we go with registered users only? I think the
> latter is the smarter option. I also think we will want to mark
> certain pages "official" and lock down editing rights.
> 

Here's another idea:
The German Wikipedia uses a concept called "sighted revisions". If you
visit an article without logging in you will see the latest sighted
revision, as an identified user you can also view the latest revision.

For the editing part:
Some users have the privilege to mark revisions as "sighted". In
Wikipedia, you gain that privilege automatically after 300 or so edits.
We could of course set that bit manually or use another threshold.

If a "regular" user makes a contribution, one of the editors would go
and check the changes and mark the revision as sighted.

> 
> Is there anything else we should consider before getting started?
> 

Maybe we should discuss what goals we want to reach with a Wiki.

One thing is offering user-contributed documentation, of course.
But do we also want a developer wiki? Or offer per-project realms in our
wiki? Or $something_else?

Alex


signature.asc
Description: PGP signature

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

[George Prowse]

On 03/04/2010 15:05, Petteri Räty wrote:

On 04/03/2010 04:53 PM, George Prowse wrote:



Armed with a list of where developers are spread too thinly, a
willingness to answer questions (no matter how stupid you believe them
to be) and some prior organisation then i see no reason why Gentoo
wouldn't get an immediate influx of at least 20 well-qualified
developers and more that are willing to give their time and limited
knowlege to help out



http://www.gentoo.org/proj/en/devrel/staffing-needs/

I don't know if developers know that this page is autogenerated from
individual project pages these days so it's easy for any developer to
get stuff there.



Looking at that page it seems clear that that is not a comprehensive list.

Maybe if all herds posted who and what they require like this:

Java Herd

2 people needed -

Essential: Java knowlege
Recommended - Javascript and ebuild writing

If no-one is willing to put a plan forward then I might acquiesce to do it.

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Tobias Scherbaum]

Am Samstag, den 03.04.2010, 16:40 +0300 schrieb Dror Levin:
> There is currently a wiki for gentoo at gentoo-wiki.com, which is
> running MediaWiki, so it would be easiest to transfer the content if
> we were to run the same software.

This should happen (if at all) on a per article basis imho. Having the
option to do so (if we want to) is a plus we should consider, though.

> Now, this doesn't mean we should be
> limited by their actions, but it seems to me like the best choice for
> other reasons as well. Its syntax is probably the most well known,
> thanks to Wikipedia. Its upstream is active, it apparently scales and
> performs pretty well, it's GPL, supports translations/localization,
> feeds, attachments, etc.
> I'm sure many other alternatives are as qualified, so this is most
> likely a personal preference issue. As such, lets just agree on
> something that works and is widespread and go with that and avoid all
> the bikeshedding.

Mediawiki sounds like what we want probably, mainly because it seems to
be the most popular one.

Besides that:
- Ubuntu and Debian are using MoinMoin
- Fedora and OpenSUSE use Mediawiki


> > 2 - maintainers
> > ===
> >
> > Who is volunteering for maintaining the wiki? We need editors and
> > moderators, people who look out for quality control and take care of
> > spam removal. So let's get together a team. I'm sure if we ask on the
> > forums we'll get some users interested as well.
> I volunteer. Spam shouldn't be that much of an issue if editing is
> restricted to registered users, but it is a good idea to have a team
> of moderators similar to the one that exists for the forums (of course
> users can take part of it as well as developers).

It's not that I'm able to invest really much time for this, but if it's
needed to get this finally rolling - count me in. Plus it shouldn't be
much of an issue, if editing is limited to registered users (at least
when speaking of Spam).

> IMO it's best if only registered users can edit (but registering
> should be easy, no bugs to file or anything, just sign up and use
> immediately). This will probably prevent most kinds of spam and allow
> for much better tracking of editing and history, allow for banning,
> etc. without closing the wiki up too much.

Fully ack.

In addition I'd like to establish a Wiki team with both developers and
experienced users who are able to review Wikipages (specifically every
revision of a page) and tag those pages as reviewed. Something not that
difficult, but that'll allow for some QA. See 
http://www.mediawiki.org/wiki/Extension:FlaggedRevs for reference.

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Ben de Groot]

On 3 April 2010 16:04, Guy Fontaine  wrote:
> I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some 
> other members also do. I maintain CSS, examples and wrote almost 60% of the 
> stuff.
>
> If you think I could help, please just let me know.

I think you can help. Stay in touch!

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

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

[Petteri Räty]

On 04/03/2010 04:53 PM, George Prowse wrote:

> 
> Armed with a list of where developers are spread too thinly, a
> willingness to answer questions (no matter how stupid you believe them
> to be) and some prior organisation then i see no reason why Gentoo
> wouldn't get an immediate influx of at least 20 well-qualified
> developers and more that are willing to give their time and limited
> knowlege to help out
> 

http://www.gentoo.org/proj/en/devrel/staffing-needs/

I don't know if developers know that this page is autogenerated from
individual project pages these days so it's easy for any developer to
get stuff there.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Guy Fontaine]

Hi !

I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some other 
members also do. I maintain CSS, examples and wrote almost 60% of the stuff.

If you think I could help, please just let me know. 

The wiki :

http://gentoo-quebec.org/wiki/index.php/Accueil

Guy Fontaine

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

[Petteri Räty]

On 04/03/2010 04:40 PM, Ben de Groot wrote:

> 
> Another problem I see is that our documentation seems to be scattered
> all over the place. I propose that we make at least one portal page
> for (prospective) developers that will link them to all the resources
> they might need. It also means our existing documentation needs to
> be brought and kept up to date.
> 

As I said elsewhere I support adding information to each question about
what piece of documentation has the answer. I will get to it eventually
but patches get us there faster.

https://bugs.gentoo.org/show_bug.cgi?id=312977

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

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

[George Prowse]

On 03/04/2010 14:40, Ben de Groot wrote:

On 3 April 2010 13:33, Richard Freeman  wrote:

I really think that the Gentoo recruitment process needs improvement. Right
now it seems like a LOT of effort is required both to become a Gentoo dev
and to help somebody become a Gentoo dev.  That means we have great people,
but not many of them.


I agree. So what can we do to improve this process?

I myself am not fond of the quizzes, and from what I've seen most
recruits find them tedious as well. It can be quite demotivating,
maybe because it reminds one too much of highschool or something.
I took a long time myself to finish them, and that wouldn't have
been necessary, as my mentors ensured me I was ready to become a
dev. And I see the same thing happening with some of my own recruits.
They can be ready, but  just find the quizzes a chore.

So I think we need to rethink how to do this. What I have found very
helpful is to have my recruits working on actual ebuilds. The
sunrise project is ideally qualified to mold ebuild editors into
shape. Working on official overlays such as qting-edge and/or doing
proxy maintenance is also very helpful.

Recruiters (with some additional manpower) could make a list of
technical issues that recruits need to be aware of, and then gather
a number of ebuilds that display these problems and let recruits
correct some of these, under guidance of their mentors. This may
possibly be more fun and closer to the actual work that is required
of developers.

Of course this doesn't address the organizational side of things, so
we need to come up with something else for that.

Another problem I see is that our documentation seems to be scattered
all over the place. I propose that we make at least one portal page
for (prospective) developers that will link them to all the resources
they might need. It also means our existing documentation needs to
be brought and kept up to date.

Are there any other ideas on how to improve our recruitment process?



I suggested a while ago that you should have recruitment drives and 
recruitment days. Set aside a day where a few devs can answer any 
questions about what it takes to be a developer - the skills required, 
the time that needs to be set aside, the behavior expected and goals 
that developers aspire to.


Set up some threads on the forums, a channel on irc, a list like 
gentoo-recruitment and a FAQ on the front page of the website.


Armed with a list of where developers are spread too thinly, a 
willingness to answer questions (no matter how stupid you believe them 
to be) and some prior organisation then i see no reason why Gentoo 
wouldn't get an immediate influx of at least 20 well-qualified 
developers and more that are willing to give their time and limited 
knowlege to help out


"If you build it, they will come"

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

[Paweł Hajdan, Jr.]

On 4/3/10 3:40 PM, Ben de Groot wrote:
> Are there any other ideas on how to improve our recruitment process?

The idea appeared before, but I think it's worth noting.

Either merge the ebuild and end quizzes, or make the split actually
meaningful. In my case I just finished both at the same time, but was
confused why they are separate. I think I've seen similar comments from
other developers.

I think I'd rather prefer merging the quizzes.

Paweł Hajdan jr



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Dror Levin]

On Sat, Apr 3, 2010 at 16:19, Ben de Groot  wrote:
> 1 - requirements
> 
>
> In order to choose the best possible wiki implementation, we need to
> know our requirements. So what features do you think are essential or
> good to have? What syntax would we prefer to use?
>
> I myself am a big fan of reStructuredText, which is quite simple,
> easy to pick up, highly readable, and has a good featureset. Plus, it
> is also reusable in other contexts (it is for example widely used in
> documentation of Python libraries). MediaWiki, MoinMoin and Trac have
> support for rst.
>
> Some others:
>
> - active upstream (bug fixes, security updates)
> - free open source software
> - ACLs
> - spam prevention measures
> - attachments (to upload screenshots for example)
> - feeds
There is currently a wiki for gentoo at gentoo-wiki.com, which is
running MediaWiki, so it would be easiest to transfer the content if
we were to run the same software. Now, this doesn't mean we should be
limited by their actions, but it seems to me like the best choice for
other reasons as well. Its syntax is probably the most well known,
thanks to Wikipedia. Its upstream is active, it apparently scales and
performs pretty well, it's GPL, supports translations/localization,
feeds, attachments, etc.
I'm sure many other alternatives are as qualified, so this is most
likely a personal preference issue. As such, lets just agree on
something that works and is widespread and go with that and avoid all
the bikeshedding.

> 2 - maintainers
> ===
>
> Who is volunteering for maintaining the wiki? We need editors and
> moderators, people who look out for quality control and take care of
> spam removal. So let's get together a team. I'm sure if we ask on the
> forums we'll get some users interested as well.
I volunteer. Spam shouldn't be that much of an issue if editing is
restricted to registered users, but it is a good idea to have a team
of moderators similar to the one that exists for the forums (of course
users can take part of it as well as developers).

> 3 - edit access
> ===
>
> Do we keep to the original "free for all" model, with all the spam
> that includes, or do we go with registered users only? I think the
> latter is the smarter option. I also think we will want to mark
> certain pages "official" and lock down editing rights.
IMO it's best if only registered users can edit (but registering
should be easy, no bugs to file or anything, just sign up and use
immediately). This will probably prevent most kinds of spam and allow
for much better tracking of editing and history, allow for banning,
etc. without closing the wiki up too much.
Also, from what I could tell, this is how others are managing their
wiki as well (Arch and Amarok, for example).

Dror Levin

[gentoo-dev] [Gentoo Phoenix] recruitment process

[Ben de Groot]

On 3 April 2010 13:33, Richard Freeman  wrote:
> I really think that the Gentoo recruitment process needs improvement. Right
> now it seems like a LOT of effort is required both to become a Gentoo dev
> and to help somebody become a Gentoo dev.  That means we have great people,
> but not many of them.

I agree. So what can we do to improve this process?

I myself am not fond of the quizzes, and from what I've seen most
recruits find them tedious as well. It can be quite demotivating,
maybe because it reminds one too much of highschool or something.
I took a long time myself to finish them, and that wouldn't have
been necessary, as my mentors ensured me I was ready to become a
dev. And I see the same thing happening with some of my own recruits.
They can be ready, but  just find the quizzes a chore.

So I think we need to rethink how to do this. What I have found very
helpful is to have my recruits working on actual ebuilds. The
sunrise project is ideally qualified to mold ebuild editors into
shape. Working on official overlays such as qting-edge and/or doing
proxy maintenance is also very helpful.

Recruiters (with some additional manpower) could make a list of
technical issues that recruits need to be aware of, and then gather
a number of ebuilds that display these problems and let recruits
correct some of these, under guidance of their mentors. This may
possibly be more fun and closer to the actual work that is required
of developers.

Of course this doesn't address the organizational side of things, so
we need to come up with something else for that.

Another problem I see is that our documentation seems to be scattered
all over the place. I propose that we make at least one portal page
for (prospective) developers that will link them to all the resources
they might need. It also means our existing documentation needs to
be brought and kept up to date.

Are there any other ideas on how to improve our recruitment process?

-- 
Ben de Groot
Gentoo Linux Qt project lead developer

[gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Ben de Groot]

On 3 April 2010 11:46, Patrick Lauer  wrote:
> On 04/03/10 11:16, Tobias Scherbaum wrote:
>> People are constantly asking for a documentation wiki, but ...
> yeah, as long as no one just creates a wiki there won't be one. People
> are waiting on other people, who are waiting for Godot. Just do it.
>
> I remember the long and whiny road to get a blog aggregator - what
> killed the waiting deadlock was simply karltk setting up one (unofficial
> etc.etc.) and suddenly people saw that it was good.


Okay, so it seems a lot of people do want a wiki. So let's see what
we can do to make that happen.

1 - requirements


In order to choose the best possible wiki implementation, we need to
know our requirements. So what features do you think are essential or
good to have? What syntax would we prefer to use?

I myself am a big fan of reStructuredText, which is quite simple,
easy to pick up, highly readable, and has a good featureset. Plus, it
is also reusable in other contexts (it is for example widely used in
documentation of Python libraries). MediaWiki, MoinMoin and Trac have
support for rst.

Some others:

- active upstream (bug fixes, security updates)
- free open source software
- ACLs
- spam prevention measures
- attachments (to upload screenshots for example)
- feeds

Other distros and open source projects surely have had the same
considerations. Can we find out and learn from them?


2 - maintainers
===

Who is volunteering for maintaining the wiki? We need editors and
moderators, people who look out for quality control and take care of
spam removal. So let's get together a team. I'm sure if we ask on the
forums we'll get some users interested as well.


3 - edit access
===

Do we keep to the original "free for all" model, with all the spam
that includes, or do we go with registered users only? I think the
latter is the smarter option. I also think we will want to mark
certain pages "official" and lock down editing rights.


Is there anything else we should consider before getting started?

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

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

[Magnus Granberg]

lördag 03 april 2010 12.19.19 skrev Tobias Scherbaum:
> > > - hardened-sources are nowadays only available in an experimental
> > > overlay, lots of users keep asking what's happening to the
> > > hardened-sources on both the -dev but also the -hardened mailinglist.
> > > Yeah, we do have people working on hardened stuff, but if people just
> > > take what's happening in the portage tree they might think that the
> > > hardened stuff they're relying on for their business isn't supported
> > > any longer.
> >
> > With Zorry we just got a new recruit for working on hardened things,
> > especially toolchain. It's not as dead as you make it sound ...
> 
> Good to see there's something happening in hardened - but still, the
> user outside of Gentoo still only is seeing: "Oh, no hardened-sources
> update for nearly a year."
> 
How long did it take for Hardened GCC to move to 4.X?  And we are still 
lacking SSP support in the tree. We have lost almost all dev's in the herd the 
past years.  As for hardened-sources we are working on it but that work has 
not hit the tree yet and that not a good situation. It will hit the tree soner 
or later. We work on our free time to and we don't have all the free time in 
the world to work on it. There is a long todo list. It is very time comsuming 
work on the toolchain, kernel, docs, bugs, recruit and help users at the same 
time. As tree dev that do all the work but we have users and some devs that 
help out too and that we are thankful for ther help. Hopefully we have 
something on the  hardened-sources after next meeting. 

@ Paweł Hajdan, Jr. you could ask in hardened-ker...@gentoo.org what thay need 
for help or join #gentoo-hardened @ freenode.net
And the hardened-sources in the hardened-development overlay have some 
regreesions that we are working on to fix.
Sorry if i bing roude.

Hardened at gentoo.org
Magnus Granberg (Zorry) 

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

[Ben de Groot]

On 3 April 2010 11:46, Patrick Lauer  wrote:
> On 04/03/10 11:16, Tobias Scherbaum wrote:
>> Hell no, but ...
>>
>> We have lots of quite understaffed areas, to sum up in a positive way.
>> Summing it up the negative way one might say, we have lots of areas were
>> users might get the idea Gentoo already is dead.
>
> So what are _you_ doing to make it better?

I like that attitude! And I'm so going to steal your idea about the phoenix.
I'll start using the [Gentoo Phoenix] tag for discussions about how we
can make Gentoo better. Maybe we could even start a project for it,
trying to bring together ideas and people who want to improve things.
I have several things I wanted to start a discussion about already, and
it seems these things are in the air now as I see these topics popping
up left and right now. I'll fork off from this discussion into some specific
things in order to try to keep things a bit organized.


>> So - what to do now?
> For me it's simple. I try to
> - dedicate time to fixing things. Takes lots of time, can be demotivating

As I've recently refocussed my Gentoo activities on Qt, and withdrawn
from various other herds I was involved in, I now have some time and
motivation to pick up something new. I wish to dedicate this to something
that will really help and I believe these discussions are a good starting
point. I hope it will trigger others in similar ways.

Cheers,
-- 
Ben de Groot
Gentoo Linux Qt project lead developer

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Fabian Groffen]

On 03-04-2010 14:09:42 +0200, Maciej Mrozowski wrote:
> > because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should
> > (in theory and on some platforms at least) fail.
> 
> It doesn't matter, as 'broken' build system may alphabetically find
> library by file name, and link to this library by full path.

Shouldn't we fix that buildsystem then?  Do you have an example of a
package/buildsystem that does that?

> On Saturday 03 of April 2010 13:13:00 Michał Górny wrote:
> > > 2. During "emerge", unset environment variable corresponding to said
> > > preserved library directory - orphans are no longer located.
> > Wouldn't that cause failure when the toolkit relies on a 'hidden'
> > preserved library?
> 
> It would indeed. Now when I think about it, moving stuff to preserved library 
> dir could be just done - provided it's possible - along with fixing/setting 
> DT_RPATH's in reverse runtime dependencies. This way no system-wide 
> LIBRARY_PATH's would be necessary.
> Is it possible? Mike?

No, unless you somehow make sure you reserve space for this, by e.g.
setting a bogus rpath entry at buildtime.  If you want to go that route,
you probably want to look at the Prefix' binutils-config wrapper that
already calls the linker with added rpath arguments.  Afterwards you can
use chrpath to set it to the correct location.  Will get messy with the
vdb though, but if Portage's doing it, it can probably be dealt with.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Maciej Mrozowski]

On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote:
> Is it known why this does happen exactly?  When a lib is kept because it
> is still used, only its soname + what the soname points to should be
> kept.  That would mean the lib can no longer be found during linking,
> unless you add some trickery (or does GNU ld do something "handy" out of
> the box right here?).  So for example:
> 
>  % ls
>  usr/lib/libfoo.so -> libfoo.so.2.1
>  usr/lib/libfoo.so.2 -> libfoo.so.2.1
>  usr/lib/libfoo.so.2.1
> 
>  % scanelf --soname usr/lib/libfoo.so
>  libfoo.so.2 usr/lib/libfoo.so
> 
> what should kept preserved is:
> 
>  usr/lib/libfoo.so.2 -> libfoo.so.2.1
>  usr/lib/libfoo.so.2.1
> 
> because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should
> (in theory and on some platforms at least) fail.

It doesn't matter, as 'broken' build system may alphabetically find library by 
file name, and link to this library by full path.

On Saturday 03 of April 2010 13:13:00 Michał Górny wrote:
> > 2. During "emerge", unset environment variable corresponding to said
> > preserved library directory - orphans are no longer located.
> Wouldn't that cause failure when the toolkit relies on a 'hidden'
> preserved library?

It would indeed. Now when I think about it, moving stuff to preserved library 
dir could be just done - provided it's possible - along with fixing/setting 
DT_RPATH's in reverse runtime dependencies. This way no system-wide 
LIBRARY_PATH's would be necessary.
Is it possible? Mike?

On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote:
> > There is opt-out suggestion[2], unfortunately it does not provide any
> > info how exactly it's supposed to be achieved. As far as portage/pkgcore
> > is concerned, maybe - as Brian Harring suggested - sandbox could be used
> > to somehow "hide" preserved libraries or preserved library directory
> > from ebuild environment (preserved library directory a'ka "purgatory" -
> > libs could be moved there when considered orphaned).
> that sounds nice, it would allow us to more easily spot
> packages/upstreams doing it wrong (maybe that would work for packages
> linking to themselves too btw)

Keeping preserved libraries in separate location (in "purgatory" or dumping 
place) is just a method for making implementation possibly easier (or possible 
at all), with nice side effects though.

-- 
regards
MM

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

[Petteri Räty]

On 04/03/2010 02:33 PM, Richard Freeman 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.
> 

The sessions also teach them a lot. I regularly get feedback that people
learned a lot during the sessions. Reading a lot of technical
documentation doesn't motivate many but the reviews do.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

hardened-sources development (was: Re: [gentoo-dev] Is Gentoo dying?)

[Thomas Sachau]

Am 03.04.2010 11:26, schrieb "Paweł Hajdan, Jr.":
> On 4/3/10 11:16 AM, Tobias Scherbaum wrote:
>> Hell no, but ...
>>
>> We have lots of quite understaffed areas, to sum up in a positive way.
>> Summing it up the negative way one might say, we have lots of areas were
>> users might get the idea Gentoo already is dead.
>>
>> For example:
>> - hardened-sources are nowadays only available in an experimental
>> overlay, lots of users keep asking what's happening to the
>> hardened-sources on both the -dev but also the -hardened mailinglist.
> 
> I recently sent an e-mail to gentoo-dev,
> 
> 
> It seems that some work is being done, but there are people who
> volunteered to help, like me. What needs to be done with hardened-sources?
> 
> Just a note: I'm using it on my servers, so I'm really interested in
> them being maintained, and I'm also able to test.
> 

Most development of hardened-sources was done in hardened-development overlay. 
There are currently
recent versions of hardened-sources, but they have some regressions, which 
should be fixed, before
they are added to the main tree. If you want to help out with this package, i 
suggest you join
#gentoo-hardened on freenode, since that is the place, where most of the 
conversation is done.
Additionally it might have been better to send this mail at least in CC to 
gentoo-hardened ML, since
most interested and active people are only subscribed there.

-- 
Thomas Sachau

Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

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

[Richard Freeman]

On 04/03/2010 06:19 AM, Tobias Scherbaum wrote:

And still, when someone tries to fix things in such an understaffed herd
people go all territorial and are like "omg u touched my package".
Right now I'm quite confused what our project strategy seems to be, as
far as I can tell there's one group aiming for an aesthetical optimum
and the other group just wants to get things fixed. And they are not
cooperating well ...


I for one can't say I had any territorial problems when touching
packages belonging to other devs or herds - it's just a problem if you
screw up.



Agreed - if you ping the herd in advance, and get an OK (or at least no 
reply for a few days), and then you make some simple fixes to their 
packages, it is very unlikely that you're going to have any complaints.


If you send the the proposed patch in advance and let them review it, 
and you get no complaints, you're even more clearly in the right.


If you don't notify them at all, or you notify them and do a cvs commit 
3 minutes later, or if you completely redesign their ebuilds in addition 
to fixing a 1-line problem, then you're going to get complaints.


Nobody minds help.  People do mind when somebody drops by to help them 
for 5 minutes and they're stuck with the aftermath.  We don't "own" our 
packages, but existing maintainers have at least shown a long-term 
commitment to them (however strong) and that should at least be respected.


On other topics in this thread:

I agree wholeheartedly that whenever possible "just do it" is a good 
approach - especially when you're talking about documentation and 
external websites/etc.  Modifications to things that already exist are 
less amenable to "just do it."


I really think that the Gentoo recruitment process needs improvement. 
Right now it seems like a LOT of effort is required both to become a 
Gentoo dev and to help somebody become a Gentoo dev.  That means we have 
great people, but not many of them.


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.


So, now instead of a recruiter having to spend hours helping somebody 
through quizzes without giving them answers, instead they just send them 
a list of interviewers, and collate the results.  Any interviewer will 
just need to spend 30 minutes on an interview and 10 minutes on a 
writeup.  Plus, the whole process will make Gentoo a bit more human.


Rich

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Gilles Dartiguelongue]

Le samedi 03 avril 2010 à 12:38 +0200, Maciej Mrozowski a écrit :
> There is opt-out suggestion[2], unfortunately it does not provide any info 
> how 
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, 
> maybe - as Brian Harring suggested - sandbox could be used to somehow "hide" 
> preserved libraries or preserved library directory from ebuild environment 
> (preserved library directory a'ka "purgatory" - libs could be moved there 
> when 
> considered orphaned).

that sounds nice, it would allow us to more easily spot
packages/upstreams doing it wrong (maybe that would work for packages
linking to themselves too btw)

-- 
Gilles Dartiguelongue 
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée

[gentoo-dev]

[Jérémie Klein]

www.medicationsshop.refytopls.com

[gentoo-dev] spin (spinroot.com) license

[Paweł Hajdan, Jr.]

I'd like to add a package for spin to the tree (it's used at several
universities, including mine and Caltech).

However, it's not straightforward. The basic license is for educational
purposes only.

Here are my suggestions how to implement that.

/usr/portage/licenses/spin-educational with the following content:

Copyright  (c) 1989-2006 Lucent Technologies, Bell Labs
Extensions (c) 2006-2009 NASA/JPL California Institute of Technology
All Rights Reserved. For educational purposes only.
No guarantee whatsoever is expressed or implied by
the distribution of this code.

/usr/portage/licenses/spin-commercial with the content pasted from
http://www.spinroot.com/spin/spin_license.html

And then in the ebuild:

LICENSE="|| ( spin-educational spin-commercial )"

Are there any license groups these should be added to?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Michał Górny]

On Sat, 3 Apr 2010 12:38:17 +0200
Maciej Mrozowski  wrote:

> 2. During "emerge", unset environment variable corresponding to said
> preserved library directory - orphans are no longer located.

Wouldn't that cause failure when the toolkit relies on a 'hidden'
preserved library?

-- 
Best regards,
Michał Górny





signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Fabian Groffen]

On 03-04-2010 12:38:17 +0200, Maciej Mrozowski wrote:
> Problem
> 
> ..is known, let me summarize briefly.
> 
> Uninstalling packages providing libraries, without checking reverse
> runtime dependencies of those packages leaves their dependencies
> unsatisfied (packages with broken executables and/or shared libs).
> Some package managers try their best not to remove said libraries, yet
> allowing packages to be removed.  Those orphaned libraries cause
> problems[1] as build systems of some other packages being
> (re)installed afterwards pick them up and abuse those orphaned
> libraries. (we don't like orphans abused, we prefer them... "gone").

Is it known why this does happen exactly?  When a lib is kept because it
is still used, only its soname + what the soname points to should be
kept.  That would mean the lib can no longer be found during linking,
unless you add some trickery (or does GNU ld do something "handy" out of
the box right here?).  So for example:

 % ls
 usr/lib/libfoo.so -> libfoo.so.2.1
 usr/lib/libfoo.so.2 -> libfoo.so.2.1
 usr/lib/libfoo.so.2.1

 % scanelf --soname usr/lib/libfoo.so
 libfoo.so.2 usr/lib/libfoo.so

what should kept preserved is:

 usr/lib/libfoo.so.2 -> libfoo.so.2.1
 usr/lib/libfoo.so.2.1

because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should
(in theory and on some platforms at least) fail.

> Solution
> 
> Now, I suppose there are some ideas how to make orphaned libraries not
> go in a way. Basically then need to be available for system, but
> hidden for "emerge".
> 
> There is opt-out suggestion[2], unfortunately it does not provide any
> info how exactly it's supposed to be achieved. As far as
> portage/pkgcore is concerned, maybe - as Brian Harring suggested -
> sandbox could be used to somehow "hide" preserved libraries or
> preserved library directory from ebuild environment (preserved library
> directory a'ka "purgatory" - libs could be moved there when considered
> orphaned).
> 
> Opt-in suggestion is as follows:
> 1. Use some library path (read by ld loader from environment) and export it 
> globally to environment pointing it to preserved library directory.

you mean: move preserved libs to some special place and have that place
being found at runtime somehow?

> 2. During "emerge", unset environment variable corresponding to said
> preserved library directory - orphans are no longer located.  Attached
> patch for glibc (2.11, but should apply to any other glibc around) and
> uClibc (this one is not tested but should work as well) that makes ld
> loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
> 
> (LD_LIBRARY_PATH would work as well, but it's being used widely so
> cannot be safely mangled.. on the second though it can - one could
> filter out preserved library paths from it during "emerge").

In general, LD_LIBRARY_PATH is considered harmful, and I wouldn't like
to see it being used for normal operation.

Instead I'd like to know first why applications can find retained libs,
because from the Portage side, in theory they shouldn't.  Maybe patching
GNU ld if it turns out being too smart may solve problems in a nicer way.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Brian Harring]

On Sat, Apr 03, 2010 at 12:38:17PM +0200, Maciej Mrozowski wrote:
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, 
> maybe - as Brian Harring suggested - sandbox could be used to somehow "hide" 
> preserved libraries or preserved library directory from ebuild environment 
> (preserved library directory a'ka "purgatory" - libs could be moved there 
> when 
> considered orphaned).

When I've tried experimenting w/ this I've had zero luck in 
intercepting lib loadup on that one.

~harring


pgpoGunNZ7rNI.pgp
Description: PGP signature

[gentoo-dev] [RFC] More reliable hiding preserved libraries

[Maciej Mrozowski]

Problem

..is known, let me summarize briefly.

Uninstalling packages providing libraries, without checking reverse runtime 
dependencies of those packages leaves their dependencies unsatisfied (packages 
with broken executables and/or shared libs).
Some package managers try their best not to remove said libraries, yet 
allowing packages to be removed.
Those orphaned libraries cause problems[1] as build systems of some other 
packages being (re)installed afterwards pick them up and abuse those orphaned 
libraries. (we don't like orphans abused, we prefer them... "gone").

Solution

Now, I suppose there are some ideas how to make orphaned libraries not go in a 
way. Basically then need to be available for system, but hidden for "emerge".

There is opt-out suggestion[2], unfortunately it does not provide any info how 
exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, 
maybe - as Brian Harring suggested - sandbox could be used to somehow "hide" 
preserved libraries or preserved library directory from ebuild environment 
(preserved library directory a'ka "purgatory" - libs could be moved there when 
considered orphaned).

Opt-in suggestion is as follows:
1. Use some library path (read by ld loader from environment) and export it 
globally to environment pointing it to preserved library directory.
2. During "emerge", unset environment variable corresponding to said preserved 
library directory - orphans are no longer located.
Attached patch for glibc (2.11, but should apply to any other glibc around) 
and uClibc (this one is not tested but should work as well) that makes ld 
loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.

(LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be 
safely mangled.. on the second though it can - one could filter out preserved 
library paths from it during "emerge").

Thoughts?

1. https://bugs.gentoo.org/show_bug.cgi?id=240323
2. https://bugs.gentoo.org/show_bug.cgi?id=307391

-- 
regards
MM
diff -ru ../glibc-2.11/elf/rtld.c ./elf/rtld.c
--- ../glibc-2.11/elf/rtld.c	2009-10-30 18:17:08.0 +0100
+++ ./elf/rtld.c	2010-04-03 10:51:46.468906521 +0200
@@ -874,6 +874,8 @@
 
 /* The library search path.  */
 static const char *library_path attribute_relro;
+/* Gentoo preserved library path.  */
+static const char *preserved_library_path attribute_relro;
 /* The list preloaded objects.  */
 static const char *preloadlist attribute_relro;
 /* Nonzero if information about versions has to be printed.  */
@@ -1385,7 +1387,18 @@
 
   /* Initialize the data structures for the search paths for shared
  objects.  */
-  _dl_init_paths (library_path);
+  char *llp = alloca ((library_path != NULL ? strlen (library_path) : 0) +
+(preserved_library_path != NULL ? strlen (preserved_library_path) : 0) + 2);
+  *llp = '\0';
+  if (library_path != NULL)
+{
+  strcat (llp, library_path);
+  if (preserved_library_path != NULL)
+strcat (llp, ":");
+}
+  if (preserved_library_path != NULL)
+strcat (llp, preserved_library_path);
+  _dl_init_paths (llp);
 
   /* Initialize _r_debug.  */
   struct r_debug *r = _dl_debug_initialize (GL(dl_rtld_map).l_addr,
@@ -2648,6 +2661,16 @@
 	mode = trace;
 	  break;
 
+	case 29:
+	  /* Read Gentoo preserved library path from env here. Watch out for
+	 possible future 'case' additions in this switch as well as in
+	 EXTRA_LD_ENVVARS defined in sysdeps//dl-librecon.h.
+	 LD_GENTOO_PRESERVED_LIBRARY_PATH is blacklisted for SUID
+	 programs in sysdeps/generic/unsecvars.h.  */
+	  if (memcmp (envline, "GENTOO_PRESERVED_LIBRARY_PATH", 29) == 0)
+	preserved_library_path = &envline[30];
+	  break;
+
 	  /* We might have some extra environment variable to handle.  This
 	 is tricky due to the pre-processing of the length of the name
 	 in the switch statement here.  The code here assumes that added
diff -ru ../glibc-2.11/sysdeps/generic/unsecvars.h ./sysdeps/generic/unsecvars.h
--- ../glibc-2.11/sysdeps/generic/unsecvars.h	2009-10-30 18:17:08.0 +0100
+++ ./sysdeps/generic/unsecvars.h	2010-04-03 10:48:07.192280437 +0200
@@ -10,6 +10,7 @@
   "LD_DEBUG_OUTPUT\0"			  \
   "LD_DYNAMIC_WEAK\0"			  \
   "LD_LIBRARY_PATH\0"			  \
+  "LD_GENTOO_PRESERVED_LIBRARY_PATH\0"	  \
   "LD_ORIGIN_PATH\0"			  \
   "LD_PRELOAD\0"			  \
   "LD_PROFILE\0"			  \
diff -ru ../uClibc-0.9.30.1/ldso/include/dl-hash.h ./ldso/include/dl-hash.h
--- ../uClibc-0.9.30.1/ldso/include/dl-hash.h	2008-11-03 16:41:17.0 +0100
+++ ./ldso/include/dl-hash.h	2010-04-03 11:23:44.026291507 +0200
@@ -132,6 +132,7 @@
 extern int _dl_linux_dynamic_link(void);
 
 extern char * _dl_library_path;
+extern char * preserved_library_path;
 extern char * _dl_not_lazy;
 
 static __inline__ int _dl_symbol(char * name)
diff -ru ../uClibc-0.9.30.1/ldso/include/ldso.h ./ldso/include/ldso.h
--- ../uClibc-0.9.30.1/ldso/include/ldso.h	2008-05-3

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* James Cloos :
> One change the perl eclasses require is elimination of the code which
> deletes the man pages.
> 
> Deleting the man pages is /extremely/ rude and should not occur.

There was a reason why the man-pages were removed: I think it was
collisions protection and perl people use `perldoc` anyway.

Do we need a patch to avoid collisions? Do you have it ready and tested?

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* Alec Warner :
> It is obvious what many of the functions do (I can read shell, yay!)
> but it is not obvious to me why they exist or why I would want to call
> them.  Why do I want to delete AppleDouble files?  What are dual-life
> scripts and why do I want to symlink them?  Why would I want to delete
> packfiles?  Some documentation would be nice h ere.

Absolutely. The perl-team already has a bug for it (#259815).
Perl eclass changes are tracked in bug #239510.
But I don't think missing documentation is a stopper here. Most of it
is copied from perl-modules.eclass.

- AppleDouble (name reported by `file`)
  268497 [p...@gentoo.org] - Remove ._* files in perl-module_src_prepare
  273104 [dev-port...@gentoo.org] - New QA check: installed OSX fork files (if 
I got the name right)

- dual-life scripts
  scripts installed by dual-life packages (part of dev-lang/perl and
  also stand-alone in perl-core/). Only relevant for perl-core/
  packages.

- .packlist
  something like CONTENTS.

[---=| TOFU protection by t-prot: 143 lines snipped |=---]

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

[Krzysztof Pawlik]

On 04/03/10 11:09, "Paweł Hajdan, Jr." wrote:
> On 4/3/10 12:03 PM, Krzysztof Pawlik wrote:
>> On 04/03/10 10:50, Petteri Räty wrote:
>>> I don't think later is valid resolution. If there's a valid bug it just
>>> means it's never looked at again. If the bug is not valid then a
>>> different resolution should be used. So what do you think about
>>> disabling later? I would like to avoid things like this:
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
>>>
>>> Not applicable to the bug above but in general our social contract says:
>>> "We will not hide problems"
>>
>> Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are
>> not valid anymore due to changed situation, RESOLVED INVALID isn't 
>> applicable in
>> this case as it implies the bug is and was invalid from the begining).
> 
> Wouldn't WORKSFORME apply in that case? Just renaming the resolutions
> doesn't gain us much. Reducing the number of possible resolutions does,
> I'd say.

In my opinion: no. WORKSFORME is for a problems that can't be reproduced.
OBSOLETE would be: yes, this bug has been applicable, but situation changed,
ignore it. One of the examples could be stabilization bugs: you have an open
stabilization bug, but new version comes out with important security fix and it
needs to go stable ASAP. You mark the old stabilization bug as OBSOLETE and
continue in the one opened for security issue (as it usually happens).

To summarize: I'm suggesting axing two resolutions (LATER and REMIND) and
introduce OBSOLETE. If OBSOLETE doesn't sound like a good idea I'm ok with not
having it -- removing two resolutions is a nice achievement too :)

-- 
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...



signature.asc
Description: OpenPGP digital signature

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

[Tobias Scherbaum]

Am Samstag, den 03.04.2010, 11:46 +0200 schrieb Patrick Lauer:
> > We have lots of quite understaffed areas, to sum up in a positive way.
> > Summing it up the negative way one might say, we have lots of areas were
> > users might get the idea Gentoo already is dead.
> 
> So what are _you_ doing to make it better?

I started to maintain those "unmaintained" packages which are important
to me myself and ended up in the net-mail/netmon herds for example.
Postfix, Cyrus-Imap, Bind, Nagios and several others are packages i put
my hands on - just because noone else did and those were and still are
essential to me.

> > - hardened-sources are nowadays only available in an experimental
> > overlay, lots of users keep asking what's happening to the
> > hardened-sources on both the -dev but also the -hardened mailinglist.
> > Yeah, we do have people working on hardened stuff, but if people just
> > take what's happening in the portage tree they might think that the
> > hardened stuff they're relying on for their business isn't supported any
> > longer. 
> With Zorry we just got a new recruit for working on hardened things,
> especially toolchain. It's not as dead as you make it sound ...

Good to see there's something happening in hardened - but still, the
user outside of Gentoo still only is seeing: "Oh, no hardened-sources
update for nearly a year."

> > - Understaffed herds: For example net-mail, netmon and others - were
> > missing lots of developers and their support in lots of areas. Sadly
> > those areas are mostly those ones, one might need packages for their
> > business servers from.
> And still, when someone tries to fix things in such an understaffed herd
> people go all territorial and are like "omg u touched my package".
> Right now I'm quite confused what our project strategy seems to be, as
> far as I can tell there's one group aiming for an aesthetical optimum
> and the other group just wants to get things fixed. And they are not
> cooperating well ...

I for one can't say I had any territorial problems when touching
packages belonging to other devs or herds - it's just a problem if you
screw up.

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Is Gentoo dying?

[Tobias Scherbaum]

Am Samstag, den 03.04.2010, 11:26 +0200 schrieb "Paweł Hajdan, Jr.":
> > For example:
> > - hardened-sources are nowadays only available in an experimental
> > overlay, lots of users keep asking what's happening to the
> > hardened-sources on both the -dev but also the -hardened mailinglist.
> 
> I recently sent an e-mail to gentoo-dev,
> 

Yeah, seen that.

> It seems that some work is being done, but there are people who
> volunteered to help, like me. What needs to be done with hardened-sources?
> 
> Just a note: I'm using it on my servers, so I'm really interested in
> them being maintained, and I'm also able to test.

See - what we've been doing with people like you who are willing to
contribute was something like "Hey, nice to see you. Get in touch with
the correct people, please" - and i'm pretty sure there are many options
on how to improve our handling of people like you, who are willing to
contribute some amount of time to the Gentoo Project.

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Is Gentoo dying?

[Tobias Scherbaum]

Am Samstag, den 03.04.2010, 02:37 -0700 schrieb Brian Harring:
> On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote:
> > Hell no, but ...
> 
> Then avoid feeding the distrowatch trolls w/ sensational 
> subjects please ;)

oh, well ;)

> > We have lots of quite understaffed areas, to sum up in a positive way.
> > Summing it up the negative way one might say, we have lots of areas were
> > users might get the idea Gentoo already is dead.
> 
> Got any metrics offhand?  The reason I ask is that I can't think of a 
> time when 'understaffed' wasn't an applicable term.

Metrics are a problem and i'm pretty sure you won't get any somewhat
"correct" metrics as we have lots of herds which do have some developers
listed as herd members, who are mia for quite some time. Still when
considering herd members who did a commit to a package belonging to
given herd in the past say 4 weeks as active you won't get useful
metrics.

> Sidenote, if we *aren't* tracking the basics, it might be worthwhile.  
> Shouldn't be too hard to grab the history of herds.xml for example and 
> extract the relevant data.
> 
> One thing to note... crappy support for something can draw people out 
> to contribute.  Hence asking about metrics- I wouldn't be surprised if 
> the headcount for misc. projects is a cyclic rise/fall.
> 
> At the very least I'd be curious about the pre and post git metrics, 
> once that conversion is finished up.
> 
> 
> > - Infra: One might get the idea our Infra team is just Robin (yeah, sure
> > there are more people, but ) ... things are happening slowly (no
> > offend - I fully understand that those few can't dedicate more of their
> > spare time to infra work!), take overlays.g.o migration, Bugzie-3
> > migration and so on as an example.
> 
> Relaying from IRC, overlays.g.o migration bits seem to be done...

Yeah, probably i had something wrong in mind. Nevermind. 

Tbh, my intention wasn't to discuss the _examples_ i listed, but to hear
all your opinions and ideas on where we do have problems and how to
solve them.

> > - Website redesign - we had a contest some years ago, got a winner,
> > someone started to adapt the design and somewhat that project fall
> > asleep.
> 
> A status update on this one would be useful, even if it's just "got no 
> time, here's what is remaining" so someone could jump in and help 
> where possible.
> 
> Personally I'd suggest trying to extract status updates from folk- 
> it's more useful anyways to know what's needed to get various projects 
> done.

Yeah, status updates++ ... at least active projects/herds (like what
Robin said about Infra) would be considered more active then :)

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

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

[Paweł Hajdan, Jr.]

On 4/3/10 12:03 PM, Krzysztof Pawlik wrote:
> On 04/03/10 10:50, Petteri Räty wrote:
>> I don't think later is valid resolution. If there's a valid bug it just
>> means it's never looked at again. If the bug is not valid then a
>> different resolution should be used. So what do you think about
>> disabling later? I would like to avoid things like this:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
>>
>> Not applicable to the bug above but in general our social contract says:
>> "We will not hide problems"
> 
> Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are
> not valid anymore due to changed situation, RESOLVED INVALID isn't applicable 
> in
> this case as it implies the bug is and was invalid from the begining).

Wouldn't WORKSFORME apply in that case? Just renaming the resolutions
doesn't gain us much. Reducing the number of possible resolutions does,
I'd say.



signature.asc
Description: OpenPGP digital signature

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

[Krzysztof Pawlik]

On 04/03/10 10:50, Petteri Räty wrote:
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? I would like to avoid things like this:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
> 
> Not applicable to the bug above but in general our social contract says:
> "We will not hide problems"

Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are
not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in
this case as it implies the bug is and was invalid from the begining).

When we kill RESOLVED LATER maybe we could also kill RESOLVED REMIND? I don't
remember it being very useful.

-- 
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...



signature.asc
Description: OpenPGP digital signature

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

[Petteri Räty]

I don't think later is valid resolution. If there's a valid bug it just
means it's never looked at again. If the bug is not valid then a
different resolution should be used. So what do you think about
disabling later? I would like to avoid things like this:

https://bugs.gentoo.org/show_bug.cgi?id=113121#c21

Not applicable to the bug above but in general our social contract says:
"We will not hide problems"

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is Gentoo dying?

[Robin H. Johnson]

On Sat, Apr 03, 2010 at 09:40:12AM +, Robin H. Johnson wrote:
> > So - what to do now? To be honest - I have no real clue. But a first
> > step might be to collect your opinions on where we do lack manpower and
> > ideas on how to solve this problems. A Wiki might be fitting well for
> > that task *cough*. A next step might be to discuss every identified
> > problem and discuss our options and ideas how to improve the situation. 
> Discussion on wiki has been going on for a while, I'll come, in a couple
> of months probably, but I still haven't heard anything of my call for
> people that were willing to do the work of editors and spam removal.
"It'll come". That typo sucked.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

[Patrick Lauer]

On 04/03/10 11:16, Tobias Scherbaum wrote:
> Hell no, but ...
> 
> We have lots of quite understaffed areas, to sum up in a positive way.
> Summing it up the negative way one might say, we have lots of areas were
> users might get the idea Gentoo already is dead.

So what are _you_ doing to make it better?

> For example:
> - hardened-sources are nowadays only available in an experimental
> overlay, lots of users keep asking what's happening to the
> hardened-sources on both the -dev but also the -hardened mailinglist.
> Yeah, we do have people working on hardened stuff, but if people just
> take what's happening in the portage tree they might think that the
> hardened stuff they're relying on for their business isn't supported any
> longer. 
With Zorry we just got a new recruit for working on hardened things,
especially toolchain. It's not as dead as you make it sound ...


> - Our formerly outstanding documentation still is somewhat maintained,
> but that's it. I haven't seen any new additions (both to our docs, but
> also to our docs-team) for years. People are constantly asking for a
> documentation wiki, but ... 
yeah, as long as no one just creates a wiki there won't be one. People
are waiting on other people, who are waiting for Godot. Just do it.

I remember the long and whiny road to get a blog aggregator - what
killed the waiting deadlock was simply karltk setting up one (unofficial
etc.etc.) and suddenly people saw that it was good.

> - Understaffed herds: For example net-mail, netmon and others - were
> missing lots of developers and their support in lots of areas. Sadly
> those areas are mostly those ones, one might need packages for their
> business servers from.
And still, when someone tries to fix things in such an understaffed herd
people go all territorial and are like "omg u touched my package".
Right now I'm quite confused what our project strategy seems to be, as
far as I can tell there's one group aiming for an aesthetical optimum
and the other group just wants to get things fixed. And they are not
cooperating well ...

> So - what to do now? 
For me it's simple. I try to
- dedicate time to fixing things. Takes lots of time, can be demotivating
- try to motivate and recruit new users - hard to motivate them, and
with our current recruiting setup it's hard to keep them motivated
- not get demotivated by the "OMG it's all bad" attitude some people radiate

And don't just start discussing how to discuss things. That's not going
to work. You'll end up with a pretty specific plan how to discuss the
whole thing, then get bored and not discuss it at all.

Just start fixing things. Set yourself some personal goals (do on
average one commit a day? fix one bug a day?) and try to reach them. If
you do, set yourself some new goals.

I have found some pretty amazing proxy-maintainers in the last weeks,
there's quite a lot of progress happening. There's still lots of
potential, but most people only start interacting with us once we have
started to show some activity.

Right now we might be in a not-that-excellent position, but it won't
just go away. It needs all of us to _do_ something.

wkr,

Patrick

Re: [gentoo-dev] Is Gentoo dying?

[Robin H. Johnson]

On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote:
> - Infra: One might get the idea our Infra team is just Robin (yeah, sure
> there are more people, but ) ... things are happening slowly (no
> offend - I fully understand that those few can't dedicate more of their
> spare time to infra work!), take overlays.g.o migration, Bugzie-3
> migration and so on as an example.
- Presently in the infra team and active on a day-to-day basis:
darkside
ford_prefect
halcy0n
idl0r
robbat2
- In the infra team and active several times/month:
fox2mike
kingtaco
ramereth
solar
armin76

Problems in infra:
- lack of communication and perceived transparency
- We'd like to open read-only access to our Nagios soon...
- lack of perceived progress
- The perceived big ticket items appear to move very slowly, because
  they are much lower priority than day-to-day running of infra.

I do have an announcement to make in the next day or 3 about some infra
stuff that's going on, because it's going to affect every developer.

Question for you there, you said 'overlays.g.o migration'. What
migration? It moved to the "new" hardware more than a year ago.

> - Website redesign - we had a contest some years ago, got a winner,
> someone started to adapt the design and somewhat that project fall
> asleep.
The guy that was doing the redesign changes vanished for a long time,
he's been around again lately however.

> So - what to do now? To be honest - I have no real clue. But a first
> step might be to collect your opinions on where we do lack manpower and
> ideas on how to solve this problems. A Wiki might be fitting well for
> that task *cough*. A next step might be to discuss every identified
> problem and discuss our options and ideas how to improve the situation. 
Discussion on wiki has been going on for a while, I'll come, in a couple
of months probably, but I still haven't heard anything of my call for
people that were willing to do the work of editors and spam removal.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Is Gentoo dying?

[Brian Harring]

On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote:
> Hell no, but ...

Then avoid feeding the distrowatch trolls w/ sensational 
subjects please ;)


> We have lots of quite understaffed areas, to sum up in a positive way.
> Summing it up the negative way one might say, we have lots of areas were
> users might get the idea Gentoo already is dead.

Got any metrics offhand?  The reason I ask is that I can't think of a 
time when 'understaffed' wasn't an applicable term.

Sidenote, if we *aren't* tracking the basics, it might be worthwhile.  
Shouldn't be too hard to grab the history of herds.xml for example and 
extract the relevant data.

One thing to note... crappy support for something can draw people out 
to contribute.  Hence asking about metrics- I wouldn't be surprised if 
the headcount for misc. projects is a cyclic rise/fall.

At the very least I'd be curious about the pre and post git metrics, 
once that conversion is finished up.


> - Infra: One might get the idea our Infra team is just Robin (yeah, sure
> there are more people, but ) ... things are happening slowly (no
> offend - I fully understand that those few can't dedicate more of their
> spare time to infra work!), take overlays.g.o migration, Bugzie-3
> migration and so on as an example.

Relaying from IRC, overlays.g.o migration bits seem to be done...


> - Website redesign - we had a contest some years ago, got a winner,
> someone started to adapt the design and somewhat that project fall
> asleep.

A status update on this one would be useful, even if it's just "got no 
time, here's what is remaining" so someone could jump in and help 
where possible.

Personally I'd suggest trying to extract status updates from folk- 
it's more useful anyways to know what's needed to get various projects 
done.

~harring


pgp3WZkFI335U.pgp
Description: PGP signature

Re: [gentoo-dev] Is Gentoo dying?

[Petteri Räty]

On 04/03/2010 12:16 PM, Tobias Scherbaum wrote:

> 
> - Infra: One might get the idea our Infra team is just Robin (yeah, sure
> there are more people, but ) ... things are happening slowly (no
> offend - I fully understand that those few can't dedicate more of their
> spare time to infra work!), take overlays.g.o migration, Bugzie-3
> migration and so on as an example.
>

My perception from the outside is also that it's sometimes hard to offer
help. So if we now that we are busy then let's try to embrace others
doing the work.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is Gentoo dying?

[Paweł Hajdan, Jr.]

On 4/3/10 11:16 AM, Tobias Scherbaum wrote:
> Hell no, but ...
> 
> We have lots of quite understaffed areas, to sum up in a positive way.
> Summing it up the negative way one might say, we have lots of areas were
> users might get the idea Gentoo already is dead.
> 
> For example:
> - hardened-sources are nowadays only available in an experimental
> overlay, lots of users keep asking what's happening to the
> hardened-sources on both the -dev but also the -hardened mailinglist.

I recently sent an e-mail to gentoo-dev,


It seems that some work is being done, but there are people who
volunteered to help, like me. What needs to be done with hardened-sources?

Just a note: I'm using it on my servers, so I'm really interested in
them being maintained, and I'm also able to test.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Is Gentoo dying?

[Tobias Scherbaum]

Hell no, but ...

We have lots of quite understaffed areas, to sum up in a positive way.
Summing it up the negative way one might say, we have lots of areas were
users might get the idea Gentoo already is dead.

For example:
- hardened-sources are nowadays only available in an experimental
overlay, lots of users keep asking what's happening to the
hardened-sources on both the -dev but also the -hardened mailinglist.
Yeah, we do have people working on hardened stuff, but if people just
take what's happening in the portage tree they might think that the
hardened stuff they're relying on for their business isn't supported any
longer. 

- Our formerly outstanding documentation still is somewhat maintained,
but that's it. I haven't seen any new additions (both to our docs, but
also to our docs-team) for years. People are constantly asking for a
documentation wiki, but ... 

- Infra: One might get the idea our Infra team is just Robin (yeah, sure
there are more people, but ) ... things are happening slowly (no
offend - I fully understand that those few can't dedicate more of their
spare time to infra work!), take overlays.g.o migration, Bugzie-3
migration and so on as an example.

- Understaffed herds: For example net-mail, netmon and others - were
missing lots of developers and their support in lots of areas. Sadly
those areas are mostly those ones, one might need packages for their
business servers from.

- Website redesign - we had a contest some years ago, got a winner,
someone started to adapt the design and somewhat that project fall
asleep.

- Speaking of our website, PR ... guess there's nothing more to add. 

So - what to do now? To be honest - I have no real clue. But a first
step might be to collect your opinions on where we do lack manpower and
ideas on how to solve this problems. A Wiki might be fitting well for
that task *cough*. A next step might be to discuss every identified
problem and discuss our options and ideas how to improve the situation. 

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: This is a digitally signed message part

Re: Re: [gentoo-dev] GSoC

[Serheo]

> On 20:59 Wed 31 Mar , Serheo wrote: 
> > 
> > Google summer of code test message. Sorry for interuption. 
> You might want to consider the impression you make on people when you 
> send an email like this. When you're required to send an email, why not 
> make it something useful and get people excited about your proposal? 
> -- 

Sorry, You Right)
I live in Russian Federation and I'm 5-th year student on speciality "Software 
development".
I.experienced in C++ ,C# and Rails development (I linked my CV with application 
on Gsoc site)
and I'm really interested in participating this year in the GSoC.
In the Ideas list I found an "Gentoo Web Application" and wrote an application 
(It's already on Gsoc site).
All additional requrement requirement completed (mailing lists and patch).

Thanks for your the and collaboration,
I would happy to work on this project and 
appreciate any help I could get from mentors.

Yours Faithfully.