Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of cctrieloff@redhat.com
 designates 66.187.233.31 as permitted sender)
Message-ID: <4561F485.30806@redhat.com>
Date: Mon, 20 Nov 2006 13:31:33 -0500
From: Carl Trieloff <cctrieloff@redhat.com>
Reply-To: cctrieloff@redhat.com
Organization: Red Hat
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: Including snapshot dependencies from other ASF projects
References: <c5e632550611170036y4f3f1b99xba01fcbadd91c4d0@mail.gmail.com>
	 <ABC2EE26-CFB5-4897-8897-BF3275C2CAC5@leosimons.com>
	 <31cc37360611171549r380bc3bdg32eda533340c8153@mail.gmail.com>
 <1194ab690611171559k3e94db01w1f6ffd9fcb08adb3@mail.gmail.com>
In-Reply-To: <1194ab690611171559k3e94db01w1f6ffd9fcb08adb3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


this is great, thank you. It gives us a clear way to work the issue in qpid.

Regards
Carl.


John O'Hara wrote:
> 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
>>
>>
>


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