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

["Sir Percival" <sirperc@yahoo.com>]

> -----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