[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian culture

> You seem to be suggesting some sort of formal delegate status.  What
> would be the benefit of having formally delegated lieutenants, over the
> self-organizing teams we're now seeing arise for things like X, the
> kernel, apache, the installer, etc.?
  Well, I think there should/could be some others...
  I think, people packaging perl apps, python apps, x, apache, kernels
patches, ...  use quite different skills.

  For those, there is already infrastructures, and docs (sepcial policy
for perl eg).  But for many quite common tasks there is none.  I'm
thinking at web based apps.  There is wwwcommon-config, but it's not
that widely used, and people don't know each other.  There is IMHO, some
lack of structure (docs, mailing lists, and stuff like that).

  The question is Why ???

  The answer, IMHO is : X, kde, gnome, apache, ...  are quite big
project, and need to be packaged by a _group_ of persons, and couldn't
live alone.  those guys naturally build teams.
  Take now web based apps, they all have things in common (have to
modify apache configs, restart it, interact with databases, etc...)
They all do it their own way, there is a lot of duplicated code, and it
inevitably leads to more bugs, broken packages, etc...
  I intensively use web based apps (phpmyadmin, diogenes, horde2, imp3,
some cgi ones, otrs, ...).  I've had more problems with those packages
than with any kde, apache or X.  But here, it's not natural that people
gather themselves.  Why the phpmyadmin guys (php+mysql) would want to
talk with the otrs or rt guys (perl cgi ticket managers) ???  Well,
maybe sth has to be done here, not to force ppl to gather themself if
they don't want to, but to have some common work done.

  I took this example because I've packaged flyspray (it's in the new
queue since 3/4 I guess) following the example of some other web based
apps.  I've been horrified by a couple of postinst scripts.
wwwconfig-comon scripts are highly unintuitive, and some are buggy.
debconf templates are not standardized, there is no policy about what
the postinst should do or not, and that's only the most obvious things
to say.

  And then, even in this big group of the web based apps (FYI apt-cache
search web|wc -l  says  1463 ...) there is the ones that use databases,
the one written in perl, python, or php (here we have most of them, but
not all).  And in those groups, there is again things that have to be
made the same way : for example, 99% of the admins that run web apps use
the same database server for all of those.  but for each package you
have to select it again and again and again (no default to the prefered
mysql, or pgsql or foobarsql server -- should be wwwconfig work).
  Another example, a lot of admins does really not like having a lot of
subdirectories for each of their web apps and wants to use virtualhost
instead (I mean instead of having foo.bar.org/phpmyadmin/ they want
phpmyadmin.bar.org, or instead of foo.bar.org/horde2/imp3/ they want
imp.bar.org ...).  Here there is no way to know if the admin prefers the
one or the other, and in fact he never has the choice and allways has to
use the default subdirectory way (and it adds him lot of work which is
easy to do ...  with some centralized things)...

  Well, all of this to say web apps lack of regularity in their
configuration scripts, and in the possibility the postinst offers.
Without having some group making some recomandations on what has to be
done, we will still have the actual packages, quite sucky for most of
them (a lot of web apps even ask the admin in a nice debconf dialog to
run the init_your_package_database.sql by hand !!!).

  It is only one example, taken from my experience.  But I'm quite sure
there is a lot of such problems.

  Maybe the lieutenant thing is not that good.  I'd prefer to say some
gurus.  I mean debian has to provide some reference group for more
domains as it does now.  As said, there is a thousand of DD's wether
they are active or not, it's a big amount of people, and a 2 level
hierarchy cannot work very efficiently.  It would be better to have more
and more little (ie less than a dozen of guys) groups, organized by
skills that should ensure that the packages depending of their skills
present some common features (and it doesn't mean a pacakge cannot
depend on several of those).

  I think it's not sensible to ask any DD to be able to have skills on
every sort of package in the debian.  Why a perl package should know
about X packaging or kernel patches ? If he is good at perl packaging,
his help will be much appreciated in other perl packages than in the kde
ones (but nothing prevent him to be good in both ;P)

  Such groups exists I know, but they are not generalized, because there
is _no_ common way to create such 'skills group', because pple still
think they have to keep an eye on all that is going on in the debian.
It's a rather monolithic, old-fashionned approach, full of inefficiency,
and rather silly.  Let the people good at some task take the decisions
tehmself, and take the one that concern other's tasks take theirs.
Critical votes and decisions still have to be taken together.  But why
the question of eg "does web apps should provide both directory and
vhost based configuration" matters for X packagers ?
Pierre Habouzit                                   http://www.madism.org/
gpg : 1024D/A1EE761C  6045 409E 5CB5 2CEA 3E70  F17E C41E 995C C98C 90BE 
spam: mad.junk@madism.org

Attachment: signature.asc
Description: Digital signature

Reply to: