incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Including snapshot dependencies from other ASF projects
Date Fri, 17 Nov 2006 23:59:53 GMT
Great analysis.
I concur with the points.

John
On 17/11/06, Henri Yandell <flamefew@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message