On Nov 17, 2006, at 9:36 AM, Cliff Schmidt wrote:
The Qpid community has been debating whether or not they should
include an unreleased snapshot version of MINA within their upcoming
Qpid release, and whether they would even be allowed to do so by
"Apache rules".
(...)
Interested in hearing everyone's thoughts (especially PMC members).
Ah, interesting and complex subject...
= IMHO =
(0) above and beyond all the below, release management is not
easily encapsulated in rules like this and (P)PMCs SHOULD
spend serious effort in figuring this kind of thing out for
themselves and their specific situation
(1) for any release from an incubating project...
(2) all dependencies SHOULD have a stable/final release
(3) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(4) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(5) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(6) custom builds of other incubating projects SHOULD
NOT be included at all
(7) the source, license, and status for all dependencies MUST
be clearly documented
(8) for any release from a non-incubating project...
(9) all dependencies SHOULD have a stable/final release
(10) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(11) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(12) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(13) custom builds of other incubating projects MUST
NOT be included at all
(14) dependencies SHOULD NOT be incubating projects
(15) the source, license, and status for all dependencies MUST
be clearly documented
= Some ranting to explain and qualify this further =
(0) really is the only clear and unambiguous "rule" if you ask me.
The difference between (1)-(7) and (8)-(15) is between (6) and
(13,14): projects that are not incubating really MUST NOT ship with
custom builds of incubating projects, and I think having dependencies
on incubating projects should also not happen in general (though
there can be good exceptions to this, in particular when the
incubating project was already an established open source project
with a compatible license, eg a dependency on an incubator release of
activemq or wicket would be just fine).
For java projects that following the maven-style naming mechanism,
one example is having a jar which has "SNAPSHOT" in its name, by
itself that DOES NOT satisfy (7) or (15), and "downloaded from
ibiblio" in terms of "where we got it" is also NOT OK.
Note this is all, explicitly, **IM(NS)HO**. There's quite a few
projects out there that don't follow these rules at all.
(...)
(16) With my incubator PMC hat on, when I vote, I will vote according
to (1)-(7), and I expect[*] that any SHOULDs or SHOULD NOTs that
can't be met are explicitly brought to my attention when asked to vote.
(17) With my member-of-other PMC hat on, when I vote, I will vote
according to (8)-(15).
I will often get (16,17) wrong at least a little bit. Since I try
hard to get it right, you don't see me voting on many podling releases.
With other hats on (like infrastructure when I was active there, or
that of a general opinionist), I will usually refrain from claiming
any MUSTs or SHOULDs, but if I have a vested interest in a project I
will often be rather vocal nonetheless.
= Applying this opinion of mine to qpid/MINA =
- good to see the discussion
- good to see the question asked
== next steps ==
- try and work within the MINA community to get the release
you need
- if that doesn't work out, let the MINA community know you
will build a custom release
- if they object, work to get the objections dealt with
- do a custom branch of the mina tree (you can `svn cp` parts
of the ASF repository into your own svn area easily
enough)
- change (project|pom).xml and similar files to have a
sensible artifact version
- create the MINA snapshot from your branch
- do not release or seperately distribute your snapshot, and
add some documentation to discourage others from doing so as
needed
- include the MINA snapshot in your release candidate
- document the MINA's snapshot use and origin
- business as usual
- note the custom-built thingie (by reference probably) on
the VOTE thread for the podling release
- note that doing this properly is often more work than just
doing the needed work within MINA, especially if you have a
good working relationship with that community already
cheers,
/LSD
[*] and this is because of the awkward PMC-member-sometimes-votes-on-
software-he-does-not-work-on thing we have around here
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
