[CentOS] How to Contribute to CentOS was: CentOS Project Infrastructure

[R P Herrold]

On Fri, 7 Aug 2009, Marcus Moeller wrote:

> 2009/8/7 R P Herrold <herrold at centos.org>:

>> You don't like reputational vetting and a meritocracy, or how
>> it is run by the people in charge who have as one goal: not
>> distributing malware.  I get it.  Thank you.

> Hey Russ, it's open source. You can just review the spec and 
> comment it until it's ready for release. Source could be 
> fetched directly from upstream and patches could be verified 
> easily.

If you want my attention seeking to persuade, do not start a 
communication: 'Hey' as I consider it rude.

You are right -- I 'can' but I have no plans to do so as it is 
not safe as stated, as trojaned content can leak in.  I guess 
it is the case that you do not read.  I have clearly said:

 	I am just not interested in 'competing' with El Repo,
 	or RPMforge, or EPEL
 		...
 	It is also a truth I have observed that because there
 	are doers and talkers, that after a while the doers
 	tire of talk, withdraw from the talkers, and build a
 	future.
 		...
 	It is fantasy to think that the effort expended by the
 	central project members would continue if 'guided' or
 	'controlled' by the hands of others with less
 	technical skills

And in a later piece:

 	either people do not read, or will not believe
 	what we write.


If a person wishes to be advanced in the project, contribute 
to the project.  [It is not clear to me WHY people think there 
is some huge benefit for being a 'project insider' as it is 
really just a chance to do more work. Early access to QA is 
just not that hard to earn] We are not likely to hold your 
hand much, but will answer questions well framed [see: /topic 
in #centos for the link].  Be a self starter.  Do something 
material.  Some things to do to gain my notice as a 
contributor of merit:

1. The bug tracker is open self serve for people to sign up. 
Add its RSS feed, and read every one as it crosses [I do]. 
Start working through the bugs to replicate or note an 
inability to replicate issues; Work through the bug tracker 
from latest to earliest, seeing if there is a similar upstream 
bug, or a fix, or if an issue is CentOS local. Note your 
results. That would be useful

2. The -docs ML is open for proposals of new content into the 
wiki.  Add its RSS feed, and read every diff as it crosses [I 
do].  Fix broken stuff that can be fixed at once.  Some even 
believe it is more useful to re-write documentation locally 
rather than feeding improvements upstream so that it flows 
back down and out into RHEL, Fedora, etc as well as just 
CentOS [I do not, and referred you to Fedora earlier in this 
thread]

3. Set up a local mirror of SRPMs, not just of the released 
Enterprise sources of upstream, but its RawHide as well.  I do 
this, and have a daily 'diff' report to scan for new material 
to review.  Start building and testing and filing bugs to make 
the .spec files more general and less distribution specific, 
so that cross pollination can occur. You may get rejected (I 
often am), but I try to improve the breed

4. The same problems repeat time and again in the Forums. 
Add its RSS feed, and read every new post as it crosses [I 
do]. Add pointers or content as needed, and 'cc' into updates 
on the thread [I do].  I have noticed a trend, that lately the 
three or four regulars are moving content more to the correct 
tree location, and asking questioners to do their research, 
and dropping out-links to answers rather than doing so in line. 
I do this as well when I form an answer, as it provides the 
linkage hints Google needs to note 'reputation' and to weave 
answers together.

5.  Join the main IRC channel or mailing list, and confirm you 
can answer every question posed for a solid week; if not, fill 
in your knowledge gaps with experimentation.  At that point, 
start thoughtfully pointing a person toward the answers. 
Spoon-feeding is NOT a good thing, and does not gain any points 
in my eyes, as that is not the stated purpose of the channel.

The mailing list is looser as to /on topic/ but when a person 
repeatedly recommends 'non-CentOS' approaches over acceptable 
CentOS product, I'll certainly notice ... and that is perhaps 
not a good thing for further advancement.  I _USE_ tinydns 
some places where it is the right fit, but I don't mention it 
here

6.  Once you have demonstrated skills, ask to be admitted to 
the next QA effort (we get three of four point update chances 
a year), and do QA.  People who sign up and are admitted often 
slack off [don't participate in the ML, don't file reports, 
are not in IRC], and by that inaction demonstrate they are are 
not interested in progressing further.  People _do_ get busy 
with real life or have to rest from burnout and take time off

7.  Once you have demonstrated skills, ask for some special 
project to build some element of needed infrastructure that is 
not otherwise getting done, and do it.  John Pierce's post 
earlier this week certainly caught my eye, as he demonstrated 
self-starter problem solving skills in a complex space I had 
not seen before.  He is now on my 'watch list' to draw into 
the project


Will any of those 'earn' a centos.org mailing address as 
someone lamented they lacked earlier in this thread? 
Sometimes, but frankly, we don't give those out easily.  I saw 
a remark earlier:

> In the meanwhile some things ... are getting a bit clearer 
> so I guess we are on the right track.

'We' can perhaps be read here as a generic 'things are on the 
right track' -- but frankly, the only 'we' that I would look 
to for authoritative statements as to the project are people 
with a '@centos.org' in their email address.  There is back 
channel coordination, infrastructure, and much more

And even then (as an example) I might not accurately KNOW 
exact status of the project as it is moving along.  My QA work 
on AMD K6-II support went back and forth in an email and IRC 
interchange with three of the eight signers participating 
yesterday.  I (sadly) happened to have the right answer as it 
turned out, and a hoped for patch for its support is not 
working properly yet.  I saw the draft 4.8 release notes go 
out and come back in translation, and while I have not read 
the final copy, I know that a fourth person in the QA loop was 
watching the thread for changes


You (Marcus) have established yourself as irrelevant to me. 
I will not presently be supporting you for further advancement 
into the CentOS infrastructure if you seek or are proposed for 
such, until I see some 'merit' outside of talking

> I do not see any problem here.

Of course you do not -- you are not doing the work to write 
code, nor implement a trial setup, nor see the errors nor 
solve them.  It is easy to tell others to do something

How about you stop posting to a mailing list and do some work? 
I am certainly not going to pursue your visions unless you pay 
me to do so.  Similarly I will not propose that others be 
forced to work toward your 'arm waving' visions within the 
aegis of the CentOS project

> Maybe, but I like the idea of setting up a community backed 
> Enterprise OS and CentOS is a great choice for that task.

And I would like a pony

As before as I told Ned:

 	> BTW, I and many others really like the Wiki

 	Then we differ, but great stuff still happens -- that's how
 	FOSS works

Here as well, we differ -- CentOS at its core is about boring, 
and stable and conservative as a core value.  You are in the 
wrong place if you think otherwise.  It makes a fine BASE to 
build on, as Dag's archive has long demonstrated, but there is 
NOT a good fit for a beginner to start doing invasive changes 
to get 'the latest and greatest' to compile.  That is the 
'rap' as to Axel's archive, and why people end up frustrated 
using it and moan and groan about their ignorance and NOT 
READING our clear warnings on the wiki's Repositories page

I'll go further -- complaints about RPMforge being down, or 
affirmations that EPEL is the cat's whiskers on CentOS 
channels will not just be silently ignored by me here any 
more.  I will start remarking about them just not being 
supported here.  I will probably start adding a <!> to wiki 
content, warning people using such outside archives that 
such content is NOT vetted, nor supported by CentOS, but 
rather by the relevant project's support mechanisms (if any)

[Al]pine just flashed that Johnny could not sleep either and 
posted something -- I'll stop now and go snooze a bit

-- Russ herrold