[Heikki == [EMAIL PROTECTED] on Wed, 06 Apr 2005 15:27:45 -0700]
Thank you for your response.
Jared> I feel it would be advantageous to do things "the Linux way"
Jared> and really support the Linux distributions' mechanisms for
Jared> packaging and distributing software.
Heikki> We need some common platform at OSAF so that we can reliably
Heikki> do testing etc.
Yes. In general, I believe this platform should be the "latest"
Fedora, resynced at every release of Chandler.
Heikki> Chandler is just barely getting to the usable state, and I
Heikki> would imagine it would be quite hard to get it to the
Heikki> official distros installers lists in the current state.
I don't feel this is a significant issue, given a 0.6 target as you
outlined. Many distributions are happy to have emerging packages and
have explicitly support for "unstable" trees (Gentoo ~x86, Debian
experimental+sid).
Heikki> We have a pretty small community, and even smaller pool of
Heikki> resources available to do the packaging etc. involved on all
Heikki> these different platforms.
Here, my primary point has perhaps been missed, namely: "The packaging
should be done via a liaison program with volunteer packagers
representing the various distributions..."
The very spirit of my proposal is to leverage volunteer resources to
do the packaging for their preferred distribution. While it's
advantageous to package something inhouse, any extension into
additional Linux platforms should be done through distributions so as
to SAVE time, not expend more.
If you're considering spending in-house resources to package for a
second Linux distribution (as your initial email suggests), I humbly
submit that you'd get more leverage of that labor if it is applied to
collaboration with a distribution representative instead.
By focusing on distributions, you'll also get an automatic real-world
poll of the popular distribution. Popular distributions will
naturally find someone to package Chandler as early as now; unpopular
distributions will languish a while longer or never.
Heikki> We should have at least one maximally usable binary
Heikki> installer available (in addition to the source method).
Could you outline the reasoning for this requirement? I don't believe
this is an obvious conclusion, in the Linux world at least. In the
Mac/Windows world, it is such a #1 high-priority requirement as to be
obvious.
Heikki> Chandler is not yet ready to be effectively packaged in this
Heikki> manner. We simply require too many slightly-changed
Heikki> "standard packages".
I'm definitely aware of this and believe this hampers Chandler
adoption and experimentation on the Linux platforms at this stage.
While this point is up for debate, I do feel there is substantially
support for this position. That said, my respects are offered to
whatever drivers and decisions brought the team to this point.
Anecdotally, since I'm not on a Fedora desktop and am not willing to
build "slight modified" versions of any libraries if the process isn't
automated, I'm currently without Chandler experience (on Linux) and am
not a contributing member of the community.
Heikki> I come from Mozilla background, and even though many distros
Heikki> do package Mozilla-based browsers and email clients, I find
Heikki> there are several drawbacks which is why I practically
Heikki> always download and install the version from
Heikki> mozilla.org.
Interesting. I'm not aware of anyone who using the Mozilla
distribution as distributed by mozilla.org, though certainly my
experience is not all encompassing. I'm aware of dozens who use their
distribution's packaging. I'd suggest that Mozilla would not have
become popular on Linux if distributions hadn't adopted it.
My experience has been that when new releases of Mozilla codebases are
released, an updated Gentoo "official" ebuild is usually available
within 24 hours. Debian unstable typically gets updated a few days
later. That schedule is fine with me. I strongly prefer distribution
integration for all packages, so as to get automated menu handling,
automated updates, etc. Out-of-distro packages are problematic to
maintain for end-users.
Knowing that you're not currently keen on the distribution-focused
approach, I offer the following tactical plan anyway:
- Put "builds against pristine libraries" as an acceptance criteria
for Chandler 0.6 Linux release. This should be prioritized high
or Linux support should be placed on the backburner and kept at a
single distribution (Fedora 4 as suggested). It is roughly true
that dependencies on modified libraries is a blocker for
distribution adoption.
- Build the Fedora 4 RPM within OSAF. Find a sponsor within the
Fedora organization to get that adopted into the canonical Fedora
RPM repository in the 0.6 timeframe.
- Contact the Gentoo herd (workgroup) responsible for desktop
productivity applications and solicit a volunteer to develop an
ebuild for chandler-svn which can build Chandler from up-to-date
source on that platform. (Gentoo is a good first candidate
because of its build-from-source history and early-adopter user
base.) A Gentoo ebuild for a numbered release can follow later in
the 0.6 timeframe.
- Next, contact debian-devel to solicit a volunteer to create a
debian/rules file, and an associated sponsor to do handle uploads
to the Debian archive. Debian will eventually promote to
unstable, then so on from there.
In general, past this base set, once you've proven that Chandler is
able to be packaged for Linux, others will start running with it as
popularity demands.
While overall, it certainly fair to say "I agree [distribution
packaging] is ideal, but I don't think we are there yet for various
reasons", I propose that in-house effort should focus on those
blockages, exactly so as to get there.
We're not on opposite sides of any fence, I don't think. I understand
it's a resource allocation issue and I have no insights into OSAF's
issues in this area. I do feel that the effort required to package
additional distributions in-house is on-par with coordinating outside
collaborations, and the benefit is greater in doing outside
coordination. So from a cost/benefit analysis, if the cost is same,
then the ratio favors driving towards adoption into an outside
distribution (Gentoo would be easiest).
Heikki> Which Linux flavors are used most, and where do we see the
Heikki> future taking them? How can we determine this?
One location for anecdotal evidence is available in the right-hand nav
of <http://distrowatch.com/>. These numbers change frequently, and in
general it is difficult to accurately know the Linux deployed base at
a given moment. My sense for desktop users would probably be ranked:
Fedora, Mandrake, SUSE, Debian, Gentoo, Ubuntu. Versions of those are
all over the map, though.
May I also suggest (probably redundantly) that CSG should be solicited
for platform desires and their needs given heavy weight. You have the
blessing of a clear client, and clients' needs can be wonderfully
focusing. They may not have any clear Linux desktop needs, though.
Thanks again for your time and effort in soliciting feedback and
considering and responding to same.
-- [EMAIL PROTECTED]
"Better to be of a rare breed than a long line." -- TDK
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
