Re: Discussing problems at DebConf
On Wed, 6 Jul 2005, martin f krafft wrote:
I for one would be very interested to sit together with people to
discuss optimisation in the organisation and workflow in Debian.
However, I share the concerns raised elsewhere in this thread and
would rather have fewer than more people.
Definitely.
So (only) if you are
really interested and have already thought about this issue and can
thus contribute sensibly, please get back to me.
The fact that I raised up this case might be regarded as a sign that
I'm interested.
I don't want
a discussion of the status quo nor a discussion of the ideal
situation. I want to discuss plausible steps for the near future
which would enable Debian to cope with the current size and further
growth.
We have to face (at least) the following flavours of growth:
1. Number of involved people
2. Number of packages
3. Number of architectures
4. Number of bugs
5. Number of users
6. Number of derivatives
We might have chances to just cut the growth of 2. and 3. The try to
cut 3. (number of architectures) leaded to heavy discussion and
dissatisfaction. We should learn from this case that either the
cut itself or the way we did the cut was not optimal. I guess if
we try to cut the number of packages we would run into similar trouble.
The consequence is that we face an (at least) six dimensional growth.
We will observe the principle that a drastical change in quantity
will lead to a new quality. If we would fail to find a new quality
to handle the problems which are caused by this growth the success
of our project will be in danger.
What did we in the past and ideas for the future:
A. Package pools (1.)
-> We dealt successfully with the growing number of packages
by technical means at the time when it was invented.
What can we learn from this (solving a problem by technical
means)?
B. Team maintainance of packages (4.,1.)
The intention is to reduce the number of bugs (4.) by increasing
the number of people working on it (1.). We will see whether this
works. More peopla can always mean that everybody relays on the
other and nobody does actually work. This is one reason for our
current security problem, IMHO.
C. Leader team (1.)
This might also deal with a point 7.: Number of problems which we
face - but I intentionally sparsed this point above because I see
no evidence for an increasing *number* of problems but a change
in the *quality* of problems we have to face. Currently I see
no change to the situaton before when whe had a single leader.
But I see great potential in this approach. For instance in the
current situation I would nominate a leader team member that is
responsible for security. By no means this person should technically
work on security issues but *lead* the security team by pinging
the members, is responsible for recruiting fallback members,
controling technical workflow and solving social problem between
dependant teams (ftpmaster, infrastructure) and informing fellow
developers about basic things they deserve to know. Unfortunately
there is no outer sign that this happens.
D. Substructuring Debian by CDDs (1., 2., 4., 5., 6.)
The fact that this topic deals with nearly all dimensions of growth
makes it quite singular. The reason is that we are following an
evolutional principle which is strongly connected to growth problems.
If you are looking for a reasoning about this topic - just visit
my CDD talk - this mail has inspired me to exchange two slides ... ;-)
E. We have no control about the number of derivatives because Debian
is free. But setting up a certain amount of documentation for
potential derivers might be helpful (CDD documentation)
IMHO, these topics are to hard to discuss over some glasses of beer with
random people. We need a reasonable number of people who have thought
about these problems and might develop solutions. This has to happen
in a quiet atmosphere and we should stick to a certain agenda. I'm
absolutely convinced that the DPL team should belong to this group of
people (not *because* they are the DPL team but because I regard every
single person in the team as competent). If they think they can work
out something without additional people - it's fine for me. I'm not
keen on bothering people with my personal opinion in such discussions.
If the result is a set of answers to some of the problems above written
down in a freely accessible place - its perfectly all right for me.
But silence is not the way to work on problems - at least not for a
larger time scale.
Kind regards
Andreas.
PS: CC to leader@d.o and Bdale (because his evolution talk was mentioned in
this thread.
--
http://fam-tille.de
--
To unsubscribe, send mail to debconf5-event-unsubscribe@lists.debconf.org.
Reply to: