[Fwd: Fw: Dropping lunar development activity]

[Auke Kok]

Date: Sat, 29 May 2004 12:11:50 -0400
From: elaine <elaine at fwsystems.com>
To: <lunar at lunar-linux.org>
Subject: Dropping lunar development activity


I regret to say that the time has come that I need to announce leaving
lunar development.

While as a practical matter, I haven't had time to develop any significant
code or keep up with package management, that is not the reason I'm electing
to drop the project; there are things I'd like to do with Lunar and I
will have the time.

My reasons are twofold

1. I'm displeased with the general code quality and developer priorities.
Specifically I was bit *yet again* this morning by the decision to add
x11 into the dependency system 'through the back door' of 'xserver-profile'.
This substantially breaks rebuild for my old boxes and I'm not willing to
continue to work with developers who:  a. don't take policy/design 
commitments
seriously and b. don't consider backward-compatibilty.

2. I'm sick and tired of politics being embedded in the moonbase ala:

---paste---
module XOrg  dependency - purpose: Answer YES to use the open source 
XOrg xserver
...
1. XOrg which is the default Lunar xserver
and will be frequently updated. 2. XFree86 which is an older version
and due to license issues will not be updated ever.
---/paste---

<rant>
This is bullshit stmtmnt 1 implise that XOrg is open source while others
aren't; stmtment 2 throws somone's politically motivated module decisions
in my face.

As it happens I'm as pleased as anyone to see the chance that the X
Consortium will again be the repository for a main branch of X11. I was
building X from source (gnu/fsf tapes) a decade ago and xfree86's code
quality has never impressed me.

The Xfree project was nominally more 'free' which was often the reason
given for xfree86 project's existence.

However xfree's new license is not non-free and it is arguably not even
gpl-incompatible for binary distribution, let alone source distribution.
</rant>


why I'm leaving:

The reason that's been given to excuse dropping our long-standing
promise that X11 will not be built into dependencies:

'we don't like fielding questions from newbies'

I'm sorry my response is 'build a system that even a fool can use and
only a fool will want to'.

So in exchange for something which could have been added to the FAQ
the project is losing a primary (albeit currently inactive) developer.


why it's important to stick to commitments:

I wrote and monitor the code that checks on how often lusers update
moonbase. The median user updates less than every 6 months.

The admonition 'run lunar update (daily, weekly, monthly)' just
doesn't cut it. That is not the average user's behavior.

Completely cutting off support for running; stable systems by
making radical changes in the dependency db imo pretty well amounts
to ignoring the actual behavior of the majority of users.


Where I'd like to see lunar going:

Those of you who've been around to hear my rants on IRC over the
years will probably be bored by this.

Lunar as a project (imnvho) has been far too willing to release
badly broken updates to moonbase (and less often core).

I believe bugs introduced that way are far harder to fix; ymmv.
I would like to see implications of changes actually be thought
through before implementation.

(AND I drew a line in the sand over this months ago asking that
*critical* modules (e.g. gcc; glibc; gnome; db; db4; ... ....) be
given sensible testing)

Regarding xserver-profile as a dependiency.

I could come up with at least 2 alternate approaches to the xserver-profile
kluge. alternate-depends as the clean way or a hack to allow lusers who
don't want x11 in deps to opt-out.

-profile 'modules' are a pretty ugly hack to begin with; they aren't
even reasonably integrated into the dependency system and so what we
got with this one was a combination of two ugly hacks for the price
of one.

I'd like to see Lunar not do that again but as I said at the start it's
not gonna be my decision or task.

I wish the project the best of luck. Of the source-based solutions it's
the best (imo).


elaine