qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack" <marnie.mccorm...@googlemail.com>
Subject Re: Including snapshot dependencies from other ASF projects
Date Mon, 20 Nov 2006 19:55:05 GMT
Hi Cliff,

Thanks very much for progressing this for us.

It has been encouraging to read such thoughtful and pragmatic responses from
Leo and Henri.

My reading of their responses is that if we cannot use a MINA release, we
can proceed with the snapshot if the MINA team do not object and there are
valid reasons for doing so (and we follow the advice about declaring the
snapshot appropriately.

Is this how you read the feedback ?

(BTW I'm leaving aside, for now, Henri's comments about issues that maven
build tools might have with snapshots (which I think is better discussed in
a separate thread).

Thanks & Regards,
Marnie


On 11/20/06, Cliff Schmidt <cliffschmidt@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message