[arch-dev-public] Goals / Mission Statement
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.
On Tue, 29 May 2007 17:15:41 -0500
"Aaron Griffin"
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.
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.
Thanks for keeping on this, Aaron. I think I've just realized why these goals are a difficult step for me. If you look through the summarized list of goals we have so far, most of them are actually goals we've already achieved and simply need to continue to achieve. eg, - Simple design - Remain a "install once, run forever" distribution - Continue to be a strongly community oriented distribution - Remain a lightweight, general purpose distributino - Not be dependent on any graphical interface - Provide the latest software as is practical etcetera. Now granted, goals need to be upheld so that we don't regress and start "un-accomplishing" some already-achieved goals. But at the same time, most of these are old hat. With the exception of a few goals, the gist I'm getting from the developers is that we're already where we want to be, goal-wise. Objective-wise, I'm sure there are more efficient ways to _stay_ where we are (internal organization/communciation, package building, roles and accountability, etc) but these are just the means to the end. So at the goal-setting stage of this discussion, these objectives are not yet relevant. So, in a multi-paragraph nutshell, that's why I've struggled with the "next step" as far as Arch vision goes. We're already really good. These may be more objectives than goals, and if so, I apologize for jumping the gun. But personally, these are things that could/should be addressed. These aren't new points -- in fact, we've been circling them for years now. 1. A clean movement towards multiple architectures. x86-64 has been a hack so far as far as its official integration goes. Props to andyrtr and his team, but we still haven't found a good way to alter our infrastructure to bring in x86-64 at the same capacity as 32-bit. Our underlying tools obviously need to evolve. Thankfully, Paul and others are already working on this. 2. Internal organization could improve somewhat so that growth spurts are not counter-productive. I'm amazed at how much time some developers have to devote to Arch Linux, and frustrated at the same time by my own dwindling spare time (I think I'm in the red now, actually). There are a solid chunk of developers that are more-or-less carrying the team, and it's a scary thought to think what would happen if they discontinued their selfless contributions. If most developers only have 5 hours/week to devote to the project, then we'll obviously need more developers. But as the number of devs grows, we need a logical hierarchy so we can grow properly. Short version: Internal Hierarchy, Communication, Organization, Processes, and Roles. I call it project HIPCOR. Sounds more evil that way. Anyway, I kinda digressed into the goals/objs above, but to revisit my main point -- most of our goals are already achieved. With the future in mind, what _new_ goals should we shoot for? - Judd
On 5/29/07, Aaron Griffin
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.
I will get the ball rolling with my current thoughts on this. My ideal sets of goals for Archlinux are as follows: * Provide the latest-and-greatest versions of software without sacrificing stability Please note I am NOT suggesting we "lag behind" or move away from the "bleeding edge" type of software that we've been going for. What I am suggesting is that IF stability is in question, there is no reason to release a new version while breaking things. Stability may be a poor word here. Rather, I would like to phrase this as follows: "Provide the latest-and-greatest versions of software with a /consistent end user experience/". The point here is that, some apps are a little broken in general. There is no reason for us to go out of our way to fix what the original developers feel is acceptable, but at the same time, if programs get *worse* with newer releases, we have an obligation to those using archlinux packages to "shield" them, if you will, from crappy applications. If we have to skip a point release so that the app isn't entirely broken, then so what? * Maintain the mantra of simplicity, in all things, including packages and utilities. By this, I mean that we need to stay "light weight". Like the point above about a "meta distribution". If we focus solely on creating a tight "core" with high quality, we allow others, more interested in things, to maintain the outer layers of the onion. A perfect example is AEGIS. The software that makes up AEGIS is important to a handful of people, but not to everyone. It is our job to make sure that the AEGIS people (person?) do not need to worry about the next coreutils release, or glibc. It is their duty to watch over their software and only theirs. * Continue to be a strongly community oriented distribution This is VERY important to me and relates to the previous point. We *are* a community distribution, like it or not. Generally, there is nothing that says that me, as a "developer" is more skilled than another member of the community. The difference is generally timing, and effort and things like that. But skill comes from everywhere, and people have different goals for themselves. We need to allow people to follow *their* goals, which may be different from ours, but which will, in the end, help us as a whole. There's my set of goals for arch, the way I see us going forward. To reiterate, I see us: * Providing the latest software within the confines of a consistent user experience * Maintaining simplicity in all things, including packages and utilities * Backing the community, and letting users flourish around us. As an analogy for the whole thing: Arch is the top soil that one would plant his own garden in
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.
Some of these goals are so vague that they could be interpreted to mean anything... Either way, here's my list, some copied some made up: - Binary distribution. Things can just be installed and (possibly with some configing) work. - Vanilla packages. As few changes to the original package as possible. If someone wants to know how to configure a package, the original documentation should be as good as anything we put out. - Not get in the way of the user (of the distro). Don't force them to jump through hoops to get common tasks done. Don't force them to learn the Arch Way of doing things. This goes along with the vanilla packages goal. - Help as much as possible. This goal is secondary to the not getting in the way goal. If you have to make a choice between being helpful and not getting in the way of the user, choose to not get in the way. - Include the community in as much of this as we can. We're making/distributing this distro so that people can use it. If they don't like using it they'll leave. If they can offer help, then we should accept it. I don't like any goals that try to define what sorts of packages we include in the distro, especially ones that limit the total number of packages and push responsibility for everything else to someone else. Arch Linux includes more than just a core. Without the other packages, it's just a fancy way to see a bash prompt. Jason
On Tue, May 29, 2007 at 04:13:59PM -0700, Judd Vinet wrote:
Anyway, I kinda digressed into the goals/objs above, but to revisit my main point -- most of our goals are already achieved. With the future in mind, what _new_ goals should we shoot for?
Well it's come up before, but I think world domination is both a realistic and feasible goal. I know that I, for one, will be quitting this developer crap (tm) if it isn't included on our shiny new list of goals. -S
On 5/29/07, Simo Leone
On Tue, May 29, 2007 at 04:13:59PM -0700, Judd Vinet wrote:
Anyway, I kinda digressed into the goals/objs above, but to revisit my main point -- most of our goals are already achieved. With the future in mind, what _new_ goals should we shoot for?
Well it's come up before, but I think world domination is both a realistic and feasible goal. I know that I, for one, will be quitting this developer crap (tm) if it isn't included on our shiny new list of goals.
Nudge nudge? I wanted to begin fleshing this out tonight. While we did happen to get a JuddMail(tm) on the topic, there was fairly low activity. I was hoping for at least a few suggestions/ideas from others. Unless, of course, everything is covered by the above. The bleaker option is that no one cares. If this is the case, this is going to end up as a one-man show and it probably won't make people all that happy in the long run... So speak up now if you have anything to say.... tick tock
Nudge nudge? I wanted to begin fleshing this out tonight. While we did happen to get a JuddMail(tm) on the topic, there was fairly low activity. I was hoping for at least a few suggestions/ideas from others. Unless, of course, everything is covered by the above. The bleaker option is that no one cares. If this is the case, this is going to end up as a one-man show and it probably won't make people all that happy in the long run...
So speak up now if you have anything to say.... tick tock
I would guess (just a guess), that people are using this to ruminate upon, until the upcoming dev meeting. I will poke around in that wiki page and see if I have anything constructive to bring to the discussion.
On 5/29/07, Aaron Griffin
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. _______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Here is my ideal set of goals, trying to keep them short and sweet as most of them have been elaborated on already. * Be up to date but never broken; ensure we don't leave a subset of users in the dust due to a package upgrade that wasn't quite ready for primetime. A new release of a package should be no less stable than the one before it if we can prevent it. In the same light, ensure that the core components (which keep us lightweight) are always functional. This ties into the next goal. * Simple and lightweight. The install should not put a bunch of packages on my machine I will never use, and never automate things to the point where it does things the user does not want to do. WRT package management, ensure pacman continues to be the easiest package manager out there all the way through from build to install. * Keep the community involved. I am at my 1 year mark of using Arch, and I've never looked back. I've been able to become a dev in that short time by making slow steps- adding some AUR packages, helping on the forums, filing bug reports, etc. Then I started contributing to pacman and was rewarded for my efforts. We need to keep community members wanting to help if we want to keep up with our own duties. We should also never hold anyone back (whether dev, TU, or user) from helping out if they have the initiative. Remarkably similar to Aaron's goals, ha. Great minds think alike. :) -Dan P.S. Reading Jason's goals, I think many of those are good foundations for what I've stated above (binary, vanilla, etc.).
participants (6)
-
Aaron Griffin
-
Dan McGee
-
eliott＠cactuswax.net
-
Jason Chu
-
Judd Vinet
-
Simo Leone