WARNING: Extremely long mail!
Pierre Schmitz wrote:
> Am Dienstag, 8. Mai 2007 22:30:59 schrieb Tobias Powalowski:
>> Hi
>> something is really going wrong at the moment.
>> People claim for having other interests or not time for doing the packaging
>> work.
This is a fact of life and even more so for computer lovers who at any
given time have _so_many_ projects (individual, personal research, work,
obligatory, etc). We'll have to find out how to make Arch related work
become naturaly positioned at the top of their priorities.
><snip>
>>
>> It's time to cleanup [current].
>> Orphan all packages of Judd, Dorphell, Aurelien, Gregor
>> 1 week of time to grab what packages you wanna have.
>> Keep in mind it's your job then to test and ensure that the package works!
>> Please one of the enablers do this, or give me the permission to orphan
>> them.
>>
>> After that period, look whats left if noone feels responsable for a package
>> make a list of possible drops or try to find one on ML who wants to
>> maintain it. It's better to have 1 maintainer for just 1 package who is
>> active and knows the package well, then 1 who just cross updates because he
>> saw the version bump.
It seems to me that there are too few devs maintaining packages that
they don't use and have no _real_ incentive to maintain (no one is
paying them... they just do it out of a sense of duty).
The only problem with a sense of duty is that, something comes along and
your sense of duty is subject to change... nothing wrong with that. If
on the other hand... there is sense of duty + utility (you use it too) +
fun (there's nothing honestly better to do) + prestige (yup... i'm an
ArchLinux maintainer.. booyaaa!!!), things suddenly become more alive.
The following is my own thought about the whole situation, bearing in
mind that i'm not a dev, and do not know the situation well enough.
Strip ArchLinux down to a small tight Core that does one thing ONLY
====================================================================
I think we have *too* many packages in current and extra. I think we
ought to rethink the basics of Arch and look at it in the light of our
current scenario.
Back then, I used to think of Arch as a meta-distro that got you up
and running as fast as possible, and then left you to do your own
customisations. These days, *everything* and the kitchen sink is
packaged (which is a good thing for end users), but not such a good
thing for maintainers.
I think that Arch can successfully use a minimal core and some
specialized repositories which are seperate mini projects.
From my thinking we could have so:
[core] or [base]
The packages on the base install iso. no more no less. You will agree
with me that this will be terribly easy to maintain even across varios
architectures.
The thinking behind this is goal oriented. The goal of working with the
[base] or [core] repo is that you have a base linux install, which is up
to date and you can use for which ever purpose comes to your mind...
routers, mailserver, dns server, developer work station, etc... you name it.
What of end user packages
=========================
The question is what happens to extra? To this i have two suggestions
that can be used independently or together, also keeping in mind the
goal oriented nature of the new repositories i'm proposing.
In my day job, the company i work for creates a distro based on Fedora
Core, and I've come to see that most people who use Fedora, RHEL, etc,
tend to get most of their packages from unofficial repositories like
rpmfind, dag, livna, etc. I think we can do something similar only
difference is our will be quasi-official.
Basically, we can have packaging sub projects which like [core] focus on
achieving another layer of usability for users of that repository
project. Just like what the kdemod guys have done or what the ArchLinux
Office project guys are doing. these guys are motivated to do this, so i
think we think of a way to empower them and let them drive those
processes. We can also choose to have in addition to the goal oriented
projects, some general category oriented projects.
[gui-core] : users of this project, would have the _extreme_ minimal
stuff neccessary to get a gui system up and running. This would not have
any Window Manager specific packages, just the basic core, like Xorg,
dbus, hal, etc, - This one is goad oriented, and if careful design,
should be small enough to be also probably managed by the core team.
[daemons]
This would be a category oriented project, that would be a catch all for
various contributed packages. postfix, sendmail, mail, mysql, postgres,
etc... all come in here. if over time, a group of ppl are highly
specialized on say mail or even specifically qmail, they can extract
themselves and their packages from [daemons] and start a [qmail] or
[mail] project. This wouldn't be under the care of the core team.
[network-utils]
category for stuff like tcpdump, netcat, hping, ntop, etc.
[development] : a category repo for various language compilers,
intepreters, etc... and then there would definitely be a need for
specialized groups like [python], [perl], [ruby], these would not be
under the care of the core team.
[webframeworks]: need not be said, django, RoR, turbogears, cakephp,
codeigniter, you name it. And if some one starts a [django] well, enjoy.
[gnome], [kde], [e17], [matchbox], etc would also exist here, maintained
by their various fanatic^H^H^H^H^Hs
It should be noted that these repositories/projects would have
dependencies on others. for instance [gui-core] would need [base] and
any of [kde], [gnome], etc, would need [gui-core]
Project Installation CD Packs
=============================
There is one more thing that the core dev team would do for these other
projects to make things even more integrated while still being
decentralized. The backend repository hosting infrastructure should have
support for building installation CD/DVD sets based on the contents of
the repository. And when a new core release is being made, efforts could
be made to cordinate with all the subprojects (or at least the major
ones), to also release project ISOs that can be downloaded and installed
ontop of their dependencies, so instead of having just links to base and
full isos, there would be links to base, gui-core, office, kde, gnome,
etc isos.
The role of [community]
========================
This in my opinion would continue to serve as it serves today... a
breeding ground for ppl just coming in. though they will also need to
point contributors to the right place (think of kernelnewbies pointing
folks at the right subsystems.
The place of pacbuild
========================
[community-src] would also host the source only packages, which would be
built using pacbuild, and in that way, we would have a huge wealth of
packages in various categories being mainained by the ppl who actually
use them and feel like mainaining them.
To conclude. I think we can move from our current developer scarcity
into a highly focused group that gets much done by creatively attacking
the problem.
Even if we don't take any ideas from this mail, I think we ought to
admit that we need to think differently about the future of ArchLinux,
and work smarter, not neccessarily work harder.
I'm stuck with ArchLinux, no other distro is better, so I'm obliged to
help make it work, else...
cheers,
Essien
PS: If you've made it this far... thnx for patiently absorbing the
ideas. I guess you can also contribute to see how we can make ArchLinux
better in a different way.
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
