incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Including snapshot dependencies from other ASF projects
Date Fri, 17 Nov 2006 22:02:40 GMT
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