> 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