Re: where are linux developer's guidelines/rules kept ?

not_at_top-post
Date: 08/22/04 

Date: Sun, 22 Aug 2004 10:13:44 -0500

Dances With Crows <danSPANceswitTRAPhcrows@usa.net> wrote:

> On Sat, 21 Aug 2004 14:04:05 -0500, not@top-post staggered into the
> Black Sun and said:
> > Obviously with collaboration of many persons a set of rules is needed.
> > What is the rule about contributors [NOT] modifying 'core' [or any
> > existing] modules ? Are there any rules, or even guidelines ?
>
Dances With Crows <danSPANceswitTRAPhcrows@usa.net> wrote:
> This varies according to the particular project you're talking about.
> Could you narrow it down some? Are you modifying the kernel itself, a
> KDE program, a GNOME program, a part of the X distribution? All of
> those projects have different rules.
>
> Typically, if you want to modify a "base" module like libkdebase, you
> submit your proposed changes to the module's maintainer, and he'll say
> "sure" or "no". The answer will almost always be "no" if your change
> breaks backwards combatibility, contains bugs, or is ugly. If you want
> to modify a non-base module, same rule about submitting to the module
> maintainer applies.
>
OK, I'm looking for a method which eliminates a person having to check it.
Like a society that [tries to] works by written rules, evolved and tested
over a long time, instead of depending a a particular personality.

> This is a difficult question to answer because you haven't given any
> specifics.
>
The principles are independant of specifics.

> > Where are the [obviously existing] linux guidelines kept ?
>
> Kernel guidelines are in /usr/src/linux/Documentation/ in the
> CodingStyle, SubmittingPatches, and SubmittingDrivers files. KDE
> guidelines are at http://kde.org/jobs/ (multiple links covering various
> things about KDE development, pick the ones you're interested in.)
> GNOME guidelines are somewhere on gnome.org.
>
On my installations of RH6.2 & Mandrake 9, they are not there,
so I'll search on public installations.

> > Is there a better method of capturing/stealing a collaborative
> > development METHODOLOGY than copying Linux's ?
>
> Huh? Why is "methodology" CAPITALIZED? What is it that you want to
> achieve? You can do what you want, but any development project with
> more than 1 person really should have:
>
Such a "methodology" would be a 'living organic entity' [a meme];
you need to 'capture it alive - without killing it'.
Copying code to run blindly is easier than 'understanding and
transplanting' a methodology .

> 0. One person to act as leader. His/her word is final.
   This is what a methodology hopes to eliminate.
> 1. A bug-tracking tool like Bugzilla
> 2. Source code kept in a revision-control system (CVS, Bitkeeper...)
> 3. Someplace where the users can complain (can be merged with 1)
> 4. Testing and QA of some sort, so at least some bugs get squashed
> before the users see the program
> 5. Beer and pizza :-)
OK these are the firmware that help to enforce the rules.
I'm looking for the rules.
>
> --
> Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
> Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
> http://www.brainbench.com / Hire me!
> -----------------------------/ http://crow202.dyndns.org/~mhgraham/resume
>
== Chris Glur.