: What I was contemplating was something similar to what what a downstream
: package manager might do: Debian, Apple, FreeBSD, etc. routinely apply patches
: and make interim releases rather than wait on upstream. Right now, if you get
...
: The CPAN package is already modified and unofficial, and so my understanding
: is that it can be modified further -- for instance by making a small patch
: which fixes the current build bug. If we did that, we would be forced to
: increment the Lucy version number, because the CPAN system does not allow you
to
: upload two different files named "Lucy-0.2.0.tar.gz". However, as we would
: not want to conflict with a future official Apache Lucy 0.2.1 release, we
: would do like the Debian people have done and append additional info to the
: release number beyond X.Y.Z -- hence, "0.2.0.1".
:
: However, as the former benevolent dictator of this codebase, I am uniquely
: unqualified to take us down that path. Lucy's principle remaining challenge
: is that we continue to rely too heavily upon me. We've made decent progress
: in that regard, but we need to do better still. It would damage the community
: if I were to make a unilateral decision to issue a quick fix. Other people
: need to be stepping up and making these fixes, and other people need to be
: involved in the decision-making process.
Diversifying the developer/maintainer base is definitely one of the
biggest things that the Lucy community needs to focus on, but it's also
important to get to a point where the concept of "Hats" is clearly
understood by everyone in the community -- especially in a project like
this where the goal is to produce a library that will be easy to
distribute using the canonical channels for various client languages (and
where you expect most users to use these downstream distibutions instead
of of downloading from the apache mirrors)
The Lucy PMC will be solely responsible for the official apache releases,
and will need to act according to Apache policies when voting/distributing
those releases, but that doesn't mean members of the Lucy PMC can't *also*
wear "Downstream Packager" hats as well -- a long as the individuals
keep in mind which hat they are wearing at any given time, and communicate
that effectively to users when taking action.
For instance: in this specific case, it would be totally understandable
for Lucy CPAN package maintainer, on receipt of a showstoper bug in the
CPAN packaging of Lucy 0.2.0, to reply to the CPAN bug with "I have a
patch to deal with this bug, and will use it to upload Lucy 0.2.0.cpan1 to
CPAN ASAP, and then forward this bug and patch upstream to Apache ASAP".
And then on receipt of the bug report, the Lucy PMC could say "we should
immediately spin up a Lucy 0.2.1 RC and vote on it."
Wether the Lucy CPAN packager is also on the Lucy PMC (or was at one point
the benevlent dictator of the Lucy code base) isn't relevant to the story
-- what matters is that every individual "hat" is acting appropriately.
An *inappropriate* example would have been if the CPAN packager to said
"i've got a patch for this bug, i'll upload Lucy 0.2.1 to CPAN ASAP and
then commit this patch to the main Lucy code base so we can spin out an
official source release" ... because it's not the CPAN packagers place to
say what Lucy 0.2.1 will/won't look be, and "we" (in the context of a Lucy
release) is the Lucy PMC, and the CPAN packager is not authorized to speak
on behalf of what the Lucy PMC will/won't do.
A seperate, larger, concern for the user community as a whole is that it
would be good if the "packagers" for the variuous language specific
distribution channels are also not single points of failures (for those
language channels) and that multiple people are knowledgable, capable, and
have the neccessary channel specific credentials to wear those hats -- but
achieving that goal is not a job for the Lucy PMC (with their Lucy PMC
hats on) to worry about. but that doesn't mean it's a taboo subject that
can't be discussed on the lucy mailing list if/when people voluteer, or
when a lonely downstream package maintainer is seeking out more
volunteers.
: Search::Prog::Lucy, and so on. In the future, things will be much worse,
: because Lucy is designed to be a bulletproof low-level library that more
: sophisticated applications like can be built on top of. It would be most
: unfortunate if we allow our release process institutions to undermine the
: reliability of our products and discourage their use.
I don't know the details of any other langauge specific distribution
channel equivilents to CPAN, but i do know:
* CPAN has the concept of release status which lets you indicate that a
packaged version is alpha or beta quality so that people can test it out
w/o having "stable" systems slurp it in automaticly
* The Apache release policies allow projects to vote+release+distribute
"beta/unstable" releases.
So if there is a concern about stability issues that may not be noticed
until something makes it downstream, one solution would be to update the
Apache Lucy release process to always start with a "beta" release vote,
and then automaticly revote to release as a "GA" some number of days
latter assuming no critical bugs come in (and downstream packagers could
act accordingly). Alternately: Apache Lucy could continue to opperate
exactly as was done with 0.2.0 and 0.2.1, but the guidelines for
downstream packagers could encourage them to initially package every RC as
an "unstable/beta" to smoke out any distribution channel specific problems
first before they break other pacakges that depend on Lucy.
-Hoss
