incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: Including snapshot dependencies from other ASF projects
Date Fri, 17 Nov 2006 23:49:22 GMT
On 11/17/06, Leo Simons <mail@leosimons.com> wrote:
> 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

> (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

+1. Revision and who it's for are essential.

>           (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

One thing I think we shouldn't do is have an incubating project be
deemed less 'safe' that a project outside the ASF. So +1 to SHOULD NOT
rather than MUST NOT. Definitely a place where (0) is expected to take
strong precedence.

>     (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).

+1

> 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.

Yep, banning SNAPSHOTs in releases is becoming the defacto. Afaik, the
Maven2 release plugin does not allow releases with snapshots in the
dependency tree, and we definitely ban such a thing in Commons
releases (we averaged 2 releases a month when we weren't very active -
now we'd probably want to do 1 a week if we could get up to speed; so
Commons has a lot of release discussions).

Snapshot dependencies come back to bite you in many user error
reports. It's not worth the benefit of not having to solve this stuff
up front.

(snip...)

> = 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

And have patience here. It may slow your project down, but the ties
between your project and the dependency are worth the slow down.

Geronimo needed Axis to do a 1.4 release; and in the end one of the
Geronimo guys dug in and did a lot of the work for it. Axis needed
Commons to do a release, and an Axis guy dug in and did the work.
Although this can be a pain, the ties between the communities are much
more valuable in the long term than the short-term delay (imnsho etc).

> - if that doesn't work out, let the MINA community know you
>    will build a custom release

I'd like to see reports of custom releases in board reports. It's a
reflection on communities working together and being aware of this is
critical for the board I think. It shouldn't be a negative aspect
towards either community, there are good reasons why one community has
to go fast and one has to go slow.

>    - 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

Is this possible if you're going to be a maven build? ie) there will
be a mina jar that qpid would need to depend on. If it's a maven build
(no idea what qpid uses); would they change the group id to be qpid's
id, or keep it as mina's?

>          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

How about package name? Should those be changed to avoid clashes with
official releases?

>     - 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

Yep. Effectively you are taking on the role of release manager, so
it's going to be more effort doing it from scratch than in the
original place with local experts (even if they're inactive).

Great email Leo :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message