[gentoo-dev] Introduction to Gentoo Development Teams and Processes

[gentoo-dev] Introduction to Gentoo Development Teams and Processes

[sirperc]

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

Hello, 

My name is Michael Spall, although I prefer sirperc or Sir Perc in
general (don't ask).
I am interested in joining in with the dvelopment of Gentoo, I am
capable of programming, although it is not my main area of interest.
Instead I am better at Design, Organization and Testing.

I would be interested in working with the documentation team, I've
signed up to the Documentation List, although it's a little quiet at the
moment and my familiarity with Gentoo is a little low at the moment.
I would also be interested in working to help formulate team dynamics,
better team co-operation and general administration of the entire
project.

Effectively if anybody has anything simplet hat you wish to be done then
please don't hesitate to email me, I'm happy to take some of those mind
numbingly boring tasks off of your hands at the moment, mostly things
like writing up documentation, composing web pages and such work.

Hope to hear from some of you soon.

My initial ideas, I am not aware of which ones have been discussed and
which haven't so apologies if these have been discussed and discarded:

1. A split between the user/newbies and other support lists and the
Development lists
At the moment the majority of traffic on the dev and doc lists seems to
be people asking questions that would be jsut as appropriate, or more so
in the user and newbie lists.
I would suggest the closure of list subscription for the development
lists to accepted developers, a web based submission form could allow
people to submit their requests for developer status.
Also this would allow the list to be set to only accepting emails from
subscribers, further reducing the badn width wastage on the list.

2. A recruitment process to get some regular posters on the users/newbie
lists to form a newbie / questions team.  developers would help out, and
the team would be more dedicated to providing accurate answers to the
posts for help on the users lists.
Again a support website could be set up, with a FAQ section (something
sorely missing), a system for listing available support members and
systems for rewarding those members in various forms.

3. The seperation and development of a team based strategy towards the
development of the whole system.  That is to say that whole sections
would form teams, somehwat like the desktop and doc teams have at the
moment but with more formalised processes.
Each team should have their own website and email list, supporting TODO
lists, their own bug-lists, and other features as necessary.
Each team should have highly visible team leaders, directing the goals
of the team, and should have clearly written team definition documents.

I have lots of little ideas in addition, some of which will probably
laughed at (Hey I'm used to it, so feel fine to point and laugh :-) )
however my main concern in gentoo is that there is no set system for
submitting new ideas for the whole system.

Ah well I hope that you dont rip these ideas apart too badly :), but
please criticise where necessary, and tell me I'm wrong where I am
wrong.

-- 
This email was written by Sir Perc (Mr M. Spall) and should be accompanied by a signature for checking with PGP, available at http://www.pgpi.org
My PGP Key is available with the email address sirperc@yahoo.com

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Introduction to Gentoo Development Teams and Processes

[Michaela Susan Buesing]

Be greeted, "Sir" Perc!

Sorry, if I don't get into too much detail, concerning your ideas, but
don't you think, that your suggestions are completely missing the point
about having an OPEN (and volountary) development process?

How are people/users supposed to learn and eventually become fully-fledged
developers if they aren't to interact/learn from those who are already
there?

I for myself would have never taken the step to apply for some official
developer status. The open system of openly available developer
documentation, mailing lists and BugZilla helped me a whole lot with
overcoming my doubts...

I also think that input from "normal" users is the best way to learn, what
should be improved. - And after all, what is OpenSource/open development
all about in the end?

Bye, Ela.

P.S.: Sorry, if this was a bit sharp. It's only my opinion, after all. :-/

RE: [gentoo-dev] Introduction to Gentoo Development Teams and Processes

[Sir Percival]

> -----Original Message-----
> From: gentoo-dev-admin@gentoo.org
> [mailto:gentoo-dev-admin@gentoo.org] On Behalf Of Michaela
> Susan Buesing
> Subject: Re: [gentoo-dev] Introduction to Gentoo Development
> Teams and Processes
>
>
> Be greeted, "Sir" Perc!

Thank you, apologies for the delay, I've had a hell of a week

>
> Sorry, if I don't get into too much detail, concerning your
> ideas, but don't you think, that your suggestions are
> completely missing the point about having an OPEN (and
> volountary) development process?

Not at all, The point I was trying to raise 9and possibly tacking my
suggestions on to the end was a mistake) was that there is no clear
defined development process.
Process being the important word here.
Firstly there is no clear documentation on the site as to how the
distribution is split amongst the developers.
The developer lists do show what rough areas each developer uses,
however they are not ordered by these areas, so to find out who is
responsible for example, for KDE, you need to look down the entire list.
This "process" is fine where you have a small number of developers,
however as the developer list grows this process becomes unmanageable
and unpalatable for your new developers looking to join the
distribution.
Secondly, there are no clearly marked descriptions of the lists, I
signed up for most of them, mostly those that interest me, but I soon
discovered that the lines between newbies, users and dev lists were very
blurry.

>
> How are people/users supposed to learn and eventually become
> fully-fledged developers if they aren't to interact/learn
> from those who are already there?

I never suggested that the development system become closed, I would
recommend that processes for ensureing that the development system is
open and viewable are discussed and decided upon by the whole community.
For example, is there a set process for someone deciding to bring a new
application into the gentoo system?  I've seen several posts on dev to
that effect, asking for advice on whether a package is being maintained
and if not how they go about maintaining it.

>
> I for myself would have never taken the step to apply for
> some official developer status. The open system of openly
> available developer documentation, mailing lists and BugZilla
> helped me a whole lot with overcoming my doubts...

The open system?  So exactly what happens on gnetoo-core that we aren't
even allowed to browse it's archives?
If I dislike the way an ebuild sets itself up on my system how do I go
about changing that ebuild, contacting the maintainer, and contributing
my fixes?

The points I am suggesting is that these processes need to be firmly
defined, not set down from on high, but put forward as proposals from on
high, discussed and agreed upon, then enforced.
Of coruse there are different systems for deciding the development
processes, the -core team could simply decide them and put them in
place, but that might not be the best move, on the other hand that might
be a good move.
These are the thigns that need to be discussed, the processes for the
development of the system.  The current system wherevy the processes are
vaguely known to everyone is fine for a small group of core developers
and a slightly larger group of general developers.  With less than one
hundered people, it could be viewed that the processes are working fine.
However these processes are not working fine because they are not
officially mandated and recorded.
Once a policy is created it should be open to change naturally, when I
looked at this community and lurked on the mailing lists I immediately
thought of a proposal -> specification -> final process model.
In my eye, anybody could propose either a change in policy or a whole
new policy for any area that they feel is not fully covered.
They would get a proposal form of some sort and submit it to the
gentoo-dev list for example, the gentoo-dev would dsicuss the proposal,
and a web absed system would allow developers to mark a yes or no to a
proposal, as the proposal went around the list, changes would be made to
it, if the proposal had more yes's than no's then it would become a
specification, which would be discussed in -core, or even gentoo-policy
if necessary.

This is only my view of a possible system, there are millions of ways of
designing such a system, and it would be the work of the entire
development community to build such a system and agree to work with the
results of such a system.

>
> I also think that input from "normal" users is the best way
> to learn, what should be improved. - And after all, what is
> OpenSource/open development all about in the end?

Yes, my suggestion of segregating developers from users was not intended
to be an enforced segregation like -dev and -core, but for both lists to
be open for archival reading fromt eh public, and the -dev lists to
require you to register, an automated system could be used, further more
I thinkt he dev list should only be postable to by subscribers.
The users list should be watched carefully, as I'm sure it currently is,
by all developers and -core maintainers to get such input.
I have other ideas for such user input systems, web based user input,
suggestion boxes and so forth but these are my ideas, and ones that I
will propose in due time as and when I have the time to implement them,
or feel that they are necessary and furthermore wanted or requested.

>
> Bye, Ela.
>
> P.S.: Sorry, if this was a bit sharp. It's only my opinion,
> after all. :-/

Not a problem, I understand your views and it is my mistake for mixing
my discussion of defining processes with other ideas.

My main point is that from what I have seen, Gentoo Linux has no fixed,
defined procedures for doing things, cvs access is handed out as and
when it is needed, future developments are decided upon by a core team
that keep their discussions private (no offence, but why is there a need
for gentoo-core to have private archives?), ebuilds can be submitted
with little or no Quality assurance (which I know daniel is working on,
and trying to find a solution to), ebuilds can be submitted and if
entered into the portage tree are then within the hour available on all
users amchines.
I could go on, each of these problems can and will be sorted out
individually, but my point is that these problems are not the problems
so to speak they are symptoms of a deeper problems and that is lack of
team management, and lack of clear guidelines.

P.s. Thank you I found the FAQ, I had seen it before but I
mis-represented my original point, I was suggesting a development FAQ,
nota  users FAQ, again somewhere where there needs to be a finer split
in my opinion


(I appear to have misplaced my PGP plugin in MS Outlook, so this one
isn't signed, I hate MS software!)
This email was written by Sir Perc (Mr M. Spall) and should be
accompanied by a signature for checking with PGP, available at
http://www.pgpi.org
My PGP Key is available with the email address sirperc@yahoo.com

RE: [gentoo-dev] Introduction to Gentoo Development Teams and Processes

[Wout Mertens]

[Original message omitted for brevity]

Some points:
- I agree that the gentoo-core mailing list archive should at least be
publicly browseable
- For devs with a day job, just keeping up with gentoo-dev and gentoo-core
is a real chore. I appreciate the fact that there is a gentoo-core mailing
list for people who are really committed to gentoo and know the ins and
outs of the system.
- Gentoo is, despite what its popularity might suggest, still in the
babycradle. It's going places fast, but it still needs to go there. I
think we simply aren't ready yet for a more open development process with
voting and whatnot, but that will come.

Of course, that is just my opinion :)

Wout.

Re: [gentoo-dev] Introduction to Gentoo Development Teams and Processes

[Andy Arbon]

> Some points:
> - I agree that the gentoo-core mailing list archive should at least be
> publicly browseable
> - For devs with a day job, just keeping up with gentoo-dev and gentoo-core
> is a real chore. I appreciate the fact that there is a gentoo-core mailing
> list for people who are really committed to gentoo and know the ins and
> outs of the system.
> - Gentoo is, despite what its popularity might suggest, still in the
> babycradle. It's going places fast, but it still needs to go there. I
> think we simply aren't ready yet for a more open development process with
> voting and whatnot, but that will come.
> 
> Of course, that is just my opinion :)
> 

Hello,

I think a valid point (which I certainly hold) is that for those of us 
who would really like to be able to get stuck in and help in some way it 
would be very useful to be able to sit in and observe the discussions 
between the core developers. I'm not yet educated enough in the ways of 
Gentoo to be able to help in a meaningful way, but the more information 
I can absorb the quicker I and others will get there.

Can we have the list made open to subscription by anyone, even if 
posting is reserved for the core team?

Cheers,

Andy


-- 
Real Men don't make backups. They upload it via ftp and let the world 
mirror it. -- Linus Torvalds

Re: [gentoo-dev] Introduction to Gentoo Development Teams and Processes

[Karl Trygve Kalleberg]

On Tue, 2 Jul 2002 sirperc@yahoo.com wrote:

> I'm happy to take some of those mind numbingly boring tasks off of your
> hands at the moment, mostly things like writing up documentation,
> composing web pages and such work. 

> a FAQ section (something sorely missing)

Oh, really, now ? :P

Why not start off the current FAQ at http://www.gentoo.org/doc/faq.html ?
It's sources are in gentoo-src/gentoo-web/xml/doc/en/faq.xml 
(cvs -d :pserver:anonymous@cvs.gentoo.org:/space/gentoo/cvsroot co \
gentoo-src)

You will definitely want to look at the gentoo-user and gentoo-dev 
archives, and our forums, there are a lot of really good nuggets of info
there.


Kind regards,

Karl T