Hey all,
This has been brought up a few times by Andy, but it seems it's fallen
on deaf ears recently. I want to make sure we get this done this
time.
One of our recent "growing pains" we've had is that there is a certain
sense of direction that is unclear. We don't have a clear set of
"goals" defined.
So lets do that now. Our dev wiki (for the benefit of the subscribed
users) contains some ideas which are rather raw. I will strip the
names to make things anonymous.
Below you will find the points listed in our dev wiki. What I want to
do, right now, is flesh this out. We need to define ourselves a clear
set of goals. It's important to note that a goal is not "make sure
packages go to testing" - that's an implementation detail. A goal is
something more ethereal, such as "provide stable, up-to-date
software".
I would like all of you to read through these (feel free to add your
own) and try and list 3-5 of these that you feel are important. On
Thursday, I'd like to compile a list of the responses, and we can go
through and cherrypick our goals from this subset from everyone - yes
this includes those of you without write access to this list. Email
me directly, if you want to remain anonymous.
Please look these over, and reply with anything you feel is important.
Thanks,
Aaron
----------------- Dev Wiki Entries -----------------
* Provide the latest software as is practical, while aiming to achieve
a reasonable level of stability
* Not be dependent on any graphical interface for any system function
* Remain a lightweight, general purpose distribution that is simple in
it's implementation
* Continue to be a strongly community oriented distribution
* Provide a good set of reliable and modern Linux technologies for
desktop, server and portable PCs
* Be equally suitable for home, educational, small business and corporate use
* Provide a solid base for creating custom Arch (ISOs and repos)
variants for users specific purposes
* Remain a "install once, run forever" distribution
* Provide good i18n and l10n support
* Simple design. Reasoning: "Debugging is twice as hard as writing the
code in the first place. Therefore, if you write the code as cleverly
as possible, you are, by definition, not smart enough to debug it." –
Brian W. Kernighan
* Vanilla. As few patches as is reasonable to make things play
together in the ways necessary, and then primarily as stopgap
solutions until things get fixed upstream. This creates predictability
and allows smart people with general GNU/Linux knowledge to pick up
Arch instantly. It also keeps us from maintaining more and more custom
patches over time.
* Easy packaging with pacman. The SINGLE thing that will probably keep
me from ever leaving Arch is how simple it is to create packages with
Pacman. The thought of ever having to write another RPM spec file or
something else as obtuse or complicated or ill-conceived as that makes
me want to toss my lunch. When I find new software on the Web to help
me do my work, I can have it packaged and integrated into my bag of
tricks usually in less than an hour. As a result of this simplicity,
we have a Community who understands what's going on and can be
productively helpful and supportive of each other.
* Binary distribution. Unlike Gentoo, we can download and install
Firefox on a reasonably fast machine with a reasonably fast link in
less than a minute. Also, we test and certify binaries, so quirks of
people's machines don't bugger up their compile processes. The result
is that after a pacman -Syu, on any machine, most things just work.
* This might not be exactly where or what we are, but someone once
called Arch a "meta distribution". That is, it gives you tools and a
very nice base with which you can do whatever you want. I think this
also coincides with 2 of the "goals" I would like to see - that is,
(a) like Andy said, we provide a very nice base system and not much
more, and (b) "Slackware with pacman" - we get likened to Slackware
enough, and I think the simplicity that slackware strives for is ideal
for us as well.
* I say focus more on the core packages.. the underlying fundamentals.
Push the addons higher into the stack. I liken Arch to one of the
BSD's, oddly enough. The BSD team focuses on handling the core. They
deal with things that come about when the system goes from poweroff to
running a base network os. Then ports managers handle the packages
that lay on top of this core system.
Just a thought.