qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <cliffschm...@gmail.com>
Subject Fwd: Including snapshot dependencies from other ASF projects
Date Mon, 20 Nov 2006 18:42:48 GMT
We got a lot of good feedback on the incubator general@ thread about
this issue.  Most PMC members seemed to feel that there was a way to
do this properly.  Paul Fremantle made some very good points about
this.  And then, Leo Simons had a very detailed suggestion.  Leo is
just one of the many members of the Incubator PMC, but I think his
email below is really well thought out and makes a lot of sense.

I recommend the the Qpid PPMC adopt his guidelines below for dealing
with the MINA situation and similar ones in the future (I'm not saying
there needs to be a formal vote to do decide to follow his email, but
that I think it would be nice if there appeared to be a general
consensus to do things this way).  Henri Yandell (also on the PMC and
on the ASF board) had a few additional comments worth considering as
well: http://mail-archives.apache.org/mod_mbox/incubator-general/200611.mbox/%3c31cc37360611171549r380bc3bdg32eda533340c8153@mail.gmail.com%3e.

Cliff

---------- Forwarded message ----------
From: Leo Simons
Date: Nov 17, 2006 2:02 PM
Subject: Re: Including snapshot dependencies from other ASF projects
To: general at incubator .apache.org


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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Mime
View raw message