[arch-dev-public] discussions to death, rules - no innovations?

Paul Mattal paul at mattal.com
Tue Oct 23 19:36:53 EDT 2007

I'll chime in, and then attempt not to get engaged in the "reply to
every reply" syndrome chastised by the open source projects book.

Andreas Radke wrote:
> In the last few weeks I've seen so many threads about rules and votings
> we want to give ourself(e.g repo destinctions and repo dividing lines,
> pkg signoff, iso naming, package movements, license issues, cvs
> move,...).
> Wasn't it the big advantage to trust the ArchLinux developers that made
> it fast growing and bleading edge with an acceptable level of
> instability? 

It depends on what kind of instability.

Arch introduces inherent instability because it uses the most
cutting-edge things and delivers them quickly. This is good instability,
because it's the kind that inherently comes from living on the
cutting-edge. I agree, that's part of our distro identity.

Organizational limitations and lack of peer review lead to bad
instability. Instability that is infused into otherwise more stable
software by our assembling it poorly.

I think the bad instability is the kind we're trying to stamp out,
without ignoring the benefits of the good kind. As a result, we're
trying to find a system that slows us down just enough to still get most
of the good instability and eliminate most of the bad instability.

> I still like to decide myself what and when to move packages into the
> repos or when to remove them. Now I have to ask and wait for other devs
> to signoff packages even for minor bugfixes. And that for two
> architectures.
> Didn't we elect Mr. T to become the release manager to let him
> decide what to do?

We're all part of a group building a group project. What I do affects
you and what you do affects me. It's reasonable for at least two
developers to get some weigh-in when an important package is modified.
Many times it will be perfunctory, but sometimes it will be important
and will save tons of hours of user support and headaches.

To take the specific example: I think sign-offs in core are a good idea,
though I think the current mechanism for them is bad. Once we have 2 or
more people registered as maintainers for each package in core, the
sign-offs can be two of those maintainers, and the whole development
staff doesn't have to be distracted by every sign-off.

The point is: we needed to take a step to see if sign-offs had benefits.
It seems like they did. We will continue to optimize them so they slow
us down as little as possible while giving us as great stability
benefits as possible.

> Now with all the discussions to death and often no actions following
> - see orphans and cleanup - I loose some of the Arch feeling. All
> these coming rules seem to slow us down more and more without finding
> new skilled manpower. 
> I'm sure we all only want the best for ArchLinux but is that
> the right way? Some rules are always ok. But I have the feeling we are
> on the way to become somewhat of an overcontrolled and superduper
> planned Debian.
> Don't you feel the same?

I don't. Have you ever seen the voting formula for Debian elections?
We're far from that, thankfully.

Recently, we're having more discussions about important issues than we
have before, writing more code, involving more people, making more
things happen than were happening before Aaron took the helm.

Certainly the shift from the invisible hand of Judd to Aaron's more
active management style is a stark contrast.. but things are happening,
and most of it is about inspecting our current state with a critical eye
and trying to solve the problems that have been plaguing us for a long
time, streamline our own processes and systems, and make each hour we
spend on Arch more efficient and result in a better product.

Open source projects live and die by consensus. Not by dictate, not by
votes. When enough of us agree, something will get done. The funny thing
about consensus is you can't force it to happen.. but when it does
happen, it's inspiring, and that's what causes someone to take action
and do good work. And that's happening more often than it was before.

We still do trust the Arch developers, but to make the most of the
single distro that we all maintain, we have to communicate more and work
together more effectively.

It's not that one man acting alone is "wrong" it's just that he's not
going to produce as good a product as one man acting as part of an
organized and thoughtful group.

- P

More information about the arch-dev-public mailing list