incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_l...@fucit.org>
Subject Re: [lucy-dev] Filepath build glitch in 0.2.0
Date Thu, 18 Aug 2011 18:32:16 GMT

: 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


Mime
View raw message