You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/03/29 16:10:44 UTC
[PROPOSAL] Next milestone release (M4?)
(From a tangential discussion on pmc@, this came up and Alan noted this
would be better discussed here, so I'm just moving it here....)
It's been 5 months since the M3 milestone release, and a *tremendous*
work has gone into the project since then.
We think we're functionally complete (or very close), so is now a good
time to do a milestone? I'm willing to help with the mechanics to keep
Dain and David (and others) cranking on certification work...
Comments?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Mark <de...@hotmail.com>.
+1
I support this as long as it doesn't require a lot of resources.
Mark
Geir Magnusson Jr. wrote:
> (From a tangential discussion on pmc@, this came up and Alan noted
> this would be better discussed here, so I'm just moving it here....)
>
> It's been 5 months since the M3 milestone release, and a *tremendous*
> work has gone into the project since then.
>
> We think we're functionally complete (or very close), so is now a good
> time to do a milestone? I'm willing to help with the mechanics to
> keep Dain and David (and others) cranking on certification work...
>
> Comments?
>
> geir
>
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Jeff Genender <jg...@savoirtech.com>.
+1...alot of people have commented on this, so this would be good.
Geir Magnusson Jr. wrote:
> (From a tangential discussion on pmc@, this came up and Alan noted this
> would be better discussed here, so I'm just moving it here....)
>
> It's been 5 months since the M3 milestone release, and a *tremendous*
> work has gone into the project since then.
>
> We think we're functionally complete (or very close), so is now a good
> time to do a milestone? I'm willing to help with the mechanics to keep
> Dain and David (and others) cranking on certification work...
>
> Comments?
>
> geir
>
Re: Split Interop Module ...
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Mar 29, 2005, at 7:36 AM, Jeremy Boynes wrote:
> Mark wrote:
>> I am considering the idea of splitting up the interop module into two
>> different pieces: interop and interop-corba. Moving forward, the
>> interop module will need to make some calls into OpenEJB and
>> OpenEJB/interop will both require generated corba related classes.
>> The OpenEJB dependency could be change to interop-corba and the
>> interop module could depend on both interop-corba and OpenEJB.
>> I anticipate this to be a minor change with no interrpution on other
>> developers.
>> Any thoughts?
>
> Just that we need to ensure that Geronimo does not depend on OpenEJB -
> where we are calling in it should be through interfaces that Geronimo
> defines and OpenEJB implements.
Mark, please create a new fresh email when sending something to the
list. When you respond to an existing email and clean out the body and
subject, the mail headers that link this new email to the previous
thread are still intact, so many mail clients will automatically mix
the new thread emails into the original thread.
Anyway, is this the Adapter code for OpenEJB? If so, this code is very
OpenEJB specific and should be moved into the OpenEJB project instead
of being part of Geronimo. Then we don't have circular dependency
problems.
-dain
Re: Split Interop Module ...
Posted by Jeremy Boynes <jb...@apache.org>.
Mark wrote:
> I am considering the idea of splitting up the interop module into two
> different pieces: interop and interop-corba. Moving forward, the
> interop module will need to make some calls into OpenEJB and
> OpenEJB/interop will both require generated corba related classes. The
> OpenEJB dependency could be change to interop-corba and the interop
> module could depend on both interop-corba and OpenEJB.
>
> I anticipate this to be a minor change with no interrpution on other
> developers.
>
> Any thoughts?
>
Just that we need to ensure that Geronimo does not depend on OpenEJB -
where we are calling in it should be through interfaces that Geronimo
defines and OpenEJB implements.
--
Jeremy
Split Interop Module ...
Posted by Mark <de...@hotmail.com>.
I am considering the idea of splitting up the interop module into two
different pieces: interop and interop-corba. Moving forward, the
interop module will need to make some calls into OpenEJB and
OpenEJB/interop will both require generated corba related classes. The
OpenEJB dependency could be change to interop-corba and the interop
module could depend on both interop-corba and OpenEJB.
I anticipate this to be a minor change with no interrpution on other
developers.
Any thoughts?
Thanks
Mark
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Thoughts on naming :
How about stopping with the M* convention, and do something like
"Geronimo 0.8". It reflects our nearness to a released version, it is
not a 1.0 so no one should have expectations of 1.0 functionality, and
we can rapidly get to 1.0 in the next month or -ish.
geir
On Mar 29, 2005, at 9:10 AM, Geir Magnusson Jr. wrote:
> (From a tangential discussion on pmc@, this came up and Alan noted
> this would be better discussed here, so I'm just moving it here....)
>
> It's been 5 months since the M3 milestone release, and a *tremendous*
> work has gone into the project since then.
>
> We think we're functionally complete (or very close), so is now a good
> time to do a milestone? I'm willing to help with the mechanics to
> keep Dain and David (and others) cranking on certification work...
>
> Comments?
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Mar 31, 2005, at 10:31 AM, David Blevins wrote:
> On Thu, Mar 31, 2005 at 10:12:42AM -0500, toby cabot wrote:
>> Jeremy,
>>
>> I agree with the first few bullets.
>>
>> On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
>>> * verification that the src bundle actually builds and results in the
>>> same binary as we are distibuting
>>
>> Is a src bundle is useful to anyone at this stage of the game? For
>> "real" releases, sure, but for now it might make more sense to release
>> binaries only and point people at the source code control system if
>> they want to build. The problem with people building from the source
>> bundle is that if they try to do anything interesting (like make
>> changes to the code) then they're in trouble since they won't have a
>> mechanism to stay in sync or submit patches that apply cleanly. I
>> think that we've got good enough instructions on the wiki so building
>> from svn isn't much more complicated than building from a tarball.
>
> It'd be nice to have a pure source jar (no build files or anything
> else) that people could hookup to their IDE. Something like the
> src.jar in JAVA_HOME.
+1
-dain
Re: [PROPOSAL] Next milestone release (M4?)
Posted by si...@insession.com.
David Blevins <da...@visi.com> wrote on 01/04/2005 04:31:33 AM:
> On Thu, Mar 31, 2005 at 10:12:42AM -0500, toby cabot wrote:
> > Jeremy,
> >
> > I agree with the first few bullets.
> >
> > On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
> > > * verification that the src bundle actually builds and results in
the
> > > same binary as we are distibuting
> >
> > Is a src bundle is useful to anyone at this stage of the game? For
> > "real" releases, sure, but for now it might make more sense to release
> > binaries only and point people at the source code control system if
> > they want to build. The problem with people building from the source
> > bundle is that if they try to do anything interesting (like make
> > changes to the code) then they're in trouble since they won't have a
> > mechanism to stay in sync or submit patches that apply cleanly. I
> > think that we've got good enough instructions on the wiki so building
> > from svn isn't much more complicated than building from a tarball.
>
> It'd be nice to have a pure source jar (no build files or anything
> else) that people could hookup to their IDE. Something like the
> src.jar in JAVA_HOME.
>
> -David
That would be nice so that any IDE/tool that operates on a source archive
can be used (not just some IDEs (e.g. eclipse) that have smarts to find
source files in subdirectories of an archive).
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Blevins <da...@visi.com>.
On Thu, Mar 31, 2005 at 10:12:42AM -0500, toby cabot wrote:
> Jeremy,
>
> I agree with the first few bullets.
>
> On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
> > * verification that the src bundle actually builds and results in the
> > same binary as we are distibuting
>
> Is a src bundle is useful to anyone at this stage of the game? For
> "real" releases, sure, but for now it might make more sense to release
> binaries only and point people at the source code control system if
> they want to build. The problem with people building from the source
> bundle is that if they try to do anything interesting (like make
> changes to the code) then they're in trouble since they won't have a
> mechanism to stay in sync or submit patches that apply cleanly. I
> think that we've got good enough instructions on the wiki so building
> from svn isn't much more complicated than building from a tarball.
It'd be nice to have a pure source jar (no build files or anything
else) that people could hookup to their IDE. Something like the
src.jar in JAVA_HOME.
-David
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Jencks <dj...@gluecode.com>.
On Mar 31, 2005, at 4:16 PM, sissonj@insession.com wrote:
> toby cabot <to...@caboteria.org> wrote on 01/04/2005 01:12:42 AM:
>
>> Jeremy,
>>
>> I agree with the first few bullets.
>>
>> On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
>>> * verification that the src bundle actually builds and results in the
>>> same binary as we are distibuting
>>
>> Is a src bundle is useful to anyone at this stage of the game? For
>> "real" releases, sure, but for now it might make more sense to release
>> binaries only and point people at the source code control system if
>> they want to build. The problem with people building from the source
>> bundle is that if they try to do anything interesting (like make
>> changes to the code) then they're in trouble since they won't have a
>> mechanism to stay in sync or submit patches that apply cleanly. I
>> think that we've got good enough instructions on the wiki so building
>> from svn isn't much more complicated than building from a tarball.
>>
>> Regards,
>> Toby
>
> Is there a reason why we don't include the svn files in the source
> tarball
> (we didn't in M3). Wouldn't that make it easier for people to make
> patches or see a comparison to HEAD to see if a problem they have
> encountered has been fixed?
I like the idea, although it would double the size of the jar since
.svn includes pristine copies of each file. Maybe we could remove the
normal working copies and ask people to do svn revert --recursive after
unpacking.
david jencks
>
> John
>
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information. This information is intended
> solely for the designated recipient(s). If an addressing or
> transmission
> error has misdirected this e-mail, please notify the sender immediately
> and destroy this e-mail. Any review, dissemination, use or reliance
> upon
> this information by unintended recipients is prohibited. Any opinions
> expressed in this e-mail are those of the author personally.
>
Re: [PROPOSAL] Next milestone release (M4?)
Posted by si...@insession.com.
toby cabot <to...@caboteria.org> wrote on 01/04/2005 01:12:42 AM:
> Jeremy,
>
> I agree with the first few bullets.
>
> On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
> > * verification that the src bundle actually builds and results in the
> > same binary as we are distibuting
>
> Is a src bundle is useful to anyone at this stage of the game? For
> "real" releases, sure, but for now it might make more sense to release
> binaries only and point people at the source code control system if
> they want to build. The problem with people building from the source
> bundle is that if they try to do anything interesting (like make
> changes to the code) then they're in trouble since they won't have a
> mechanism to stay in sync or submit patches that apply cleanly. I
> think that we've got good enough instructions on the wiki so building
> from svn isn't much more complicated than building from a tarball.
>
> Regards,
> Toby
Is there a reason why we don't include the svn files in the source tarball
(we didn't in M3). Wouldn't that make it easier for people to make
patches or see a comparison to HEAD to see if a problem they have
encountered has been fixed?
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: [PROPOSAL] Next milestone release (M4?)
Posted by toby cabot <to...@caboteria.org>.
Jeremy,
I agree with the first few bullets.
On Tue, Mar 29, 2005 at 07:40:13AM -0800, Jeremy Boynes wrote:
> * verification that the src bundle actually builds and results in the
> same binary as we are distibuting
Is a src bundle is useful to anyone at this stage of the game? For
"real" releases, sure, but for now it might make more sense to release
binaries only and point people at the source code control system if
they want to build. The problem with people building from the source
bundle is that if they try to do anything interesting (like make
changes to the code) then they're in trouble since they won't have a
mechanism to stay in sync or submit patches that apply cleanly. I
think that we've got good enough instructions on the wiki so building
from svn isn't much more complicated than building from a tarball.
Regards,
Toby
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Mar 29, 2005, at 8:30 AM, Bruce Snyder wrote:
> On Tue, 29 Mar 2005 07:40:13 -0800, Jeremy Boynes <jb...@apache.org>
> wrote:
>> -1
>>
>> Whilst I agree with the intention, we do not have a process defined
>> that
>> would allow us to generate a reproducable release. This led to
>> several
>> of the issues with the last M3 release that ultimately made is
>> unusable.
>> We must fix this before we can release another version.
>>
>> Specific things I think we need include in such a process:
>> * an mechanical process for producing the candidate binaries that can
>> be
>> executed against any SVN tag. This would reduce the potential for
>> minor variations by people doing the release that would result in
>> potentially different binaries
>>
>> * elimination of SNAPSHOT dependencies - these are by nature ephemeral
>> making it impossible to later regenerate the same distribution
>>
>> * a testing/review period that is at least comprehensive enough to
>> catch
>> the blaring defects that plagued M3
>>
>> * verification that the src bundle actually builds and results in the
>> same binary as we are distibuting
>
> +100 on creating a reproduceable, mechanical process for these tasks.
> I was told by someone that much of this already exists in the form of
> shell/perl scripts somewhere. Is this true or not? I think that
> spending time on this task takes a fairly high priority, no matter
> whether we decide to produce a release at this time or not. That said,
> any idea how long it might take to accomplish this set of tasks? In
> working toward this goal, the first thing I'd like to see is a
> comprehensive list of tasks necessary to complete this work as well as
> a list of artifacts that must be produced. Jeremy's list above is a
> very good start, let's build upon it.
This is a lot harder then it looks. All of these items and sever
others (such as tagging cvs/svn) were on the list last time David and
I worked on the last release. Also you need to coordinate with OpenEJB
to get a tagged set of binaries released.
I guess practice makes perfect. I suggest you make a dry run branch of
the server and work out the steps (script) required for a release.
Once you get a reproducible process worked out, take a current branch
and cut a release.
-dain
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, 29 Mar 2005 07:40:13 -0800, Jeremy Boynes <jb...@apache.org> wrote:
> -1
>
> Whilst I agree with the intention, we do not have a process defined that
> would allow us to generate a reproducable release. This led to several
> of the issues with the last M3 release that ultimately made is unusable.
> We must fix this before we can release another version.
>
> Specific things I think we need include in such a process:
> * an mechanical process for producing the candidate binaries that can be
> executed against any SVN tag. This would reduce the potential for
> minor variations by people doing the release that would result in
> potentially different binaries
>
> * elimination of SNAPSHOT dependencies - these are by nature ephemeral
> making it impossible to later regenerate the same distribution
>
> * a testing/review period that is at least comprehensive enough to catch
> the blaring defects that plagued M3
>
> * verification that the src bundle actually builds and results in the
> same binary as we are distibuting
+100 on creating a reproduceable, mechanical process for these tasks.
I was told by someone that much of this already exists in the form of
shell/perl scripts somewhere. Is this true or not? I think that
spending time on this task takes a fairly high priority, no matter
whether we decide to produce a release at this time or not. That said,
any idea how long it might take to accomplish this set of tasks? In
working toward this goal, the first thing I'd like to see is a
comprehensive list of tasks necessary to complete this work as well as
a list of artifacts that must be produced. Jeremy's list above is a
very good start, let's build upon it.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Mar 29, 2005, at 1:16 PM, David Blevins wrote:
> On Tue, Mar 29, 2005 at 12:39:17PM -0500, Geir Magnusson Jr. wrote:
>>
>> On Mar 29, 2005, at 12:16 PM, Alan D. Cabrera wrote:
>>
>>>
>>>
>>> Geir Magnusson Jr. wrote:
>>>>
>>>> Heh. I was just thinking about that, and also about the subject of
>>>> OpenEJB - would there be good benefit into bringing it to Geronimo?
>>>> We seem to be so interdependent...
>>>
>>>
>>> Well, hopefully that will change. I would be very much opposed to
>>> including OpenEJB into Geronimo.
>>>
>>
>> Can I ask why? I'm just curious since we seem so interdependent on
>> one
>> another. I'm not a part of OpenEJB, so I don't know who else is using
>> it, what part of the committer base is independent of Geronimo, stuff
>> like that.
>
> Just making a note here as well. Those people can be contacted at
> user@openejb.org. Only fair we include them in this kind of talk.
>
David,
I'm not trying to start anything here, and I would expect that it be a
OpenEJB community decision anyway. I am just curious why Alan was very
much opposed. What is your opinion?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Blevins <da...@visi.com>.
On Tue, Mar 29, 2005 at 12:39:17PM -0500, Geir Magnusson Jr. wrote:
>
> On Mar 29, 2005, at 12:16 PM, Alan D. Cabrera wrote:
>
> >
> >
> >Geir Magnusson Jr. wrote:
> >>
> >>Heh. I was just thinking about that, and also about the subject of
> >>OpenEJB - would there be good benefit into bringing it to Geronimo?
> >>We seem to be so interdependent...
> >
> >
> >Well, hopefully that will change. I would be very much opposed to
> >including OpenEJB into Geronimo.
> >
>
> Can I ask why? I'm just curious since we seem so interdependent on one
> another. I'm not a part of OpenEJB, so I don't know who else is using
> it, what part of the committer base is independent of Geronimo, stuff
> like that.
Just making a note here as well. Those people can be contacted at user@openejb.org. Only fair we include them in this kind of talk.
-David
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Mar 29, 2005, at 12:16 PM, Alan D. Cabrera wrote:
>
>
> Geir Magnusson Jr. wrote:
>>
>> Heh. I was just thinking about that, and also about the subject of
>> OpenEJB - would there be good benefit into bringing it to Geronimo?
>> We seem to be so interdependent...
>
>
> Well, hopefully that will change. I would be very much opposed to
> including OpenEJB into Geronimo.
>
Can I ask why? I'm just curious since we seem so interdependent on one
another. I'm not a part of OpenEJB, so I don't know who else is using
it, what part of the committer base is independent of Geronimo, stuff
like that.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Geir Magnusson Jr. wrote:
>
> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>
>>
>>
>> Geir Magnusson Jr. wrote:
>>
>>>
>>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>>
>>>> -1
>>>>
>>>
>>> We'll ignore this as it isn't a vote :)
>>>
>>>> Whilst I agree with the intention, we do not have a process defined
>>>> that would allow us to generate a reproducable release. This led
>>>> to several of the issues with the last M3 release that ultimately
>>>> made is unusable. We must fix this before we can release another
>>>> version.
>>>>
>>>> Specific things I think we need include in such a process:
>>>> * an mechanical process for producing the candidate binaries that
>>>> can be
>>>> executed against any SVN tag. This would reduce the potential for
>>>> minor variations by people doing the release that would result in
>>>> potentially different binaries
>>>>
>>>
>>> Yes
>>>
>>>> * elimination of SNAPSHOT dependencies - these are by nature ephemeral
>>>> making it impossible to later regenerate the same distribution
>>>>
>>>
>>> Yes
>>>
>>>> * a testing/review period that is at least comprehensive enough to
>>>> catch
>>>> the blaring defects that plagued M3
>>>
>>>
>>>
>>> yes
>>>
>>>>
>>>> * verification that the src bundle actually builds and results in the
>>>> same binary as we are distibuting
>>>
>>>
>>>
>>> Yes
>>>
>>> All of these were the standard way for other projects I've been
>>> involved with. No argument.
>>>
>>> But can we, with this in mind, first discuss going forward w/ a
>>> release? We're going to have to bang out a real release process for
>>> 1.0, and this is a good opportunity to get started. I volunteer to
>>> help.
>>
>>
>>
>> Is now a good time to talk about how Geornimo needs its own remote
>> maven repo?
>
>
> Heh. I was just thinking about that, and also about the subject of
> OpenEJB - would there be good benefit into bringing it to Geronimo?
> We seem to be so interdependent...
Well, hopefully that will change. I would be very much opposed to
including OpenEJB into Geronimo.
Regards,
Alan
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Blevins <da...@visi.com>.
On Tue, Mar 29, 2005 at 10:29:14AM -0800, David Jencks wrote:
> On Mar 29, 2005, at 10:09 AM, Alan D. Cabrera wrote:
>
> >2. This is a tall order, IMHO. I think that this is a goal that
> >should be vigorously sought but I don't think that it should stop a
> >milestone release. Maybe a v1.0 release, I'll grant you that.
>
> I agree. I'd like to eliminate privately patched jars but try to
> minimize snapshots.
>
+1
Can't think of how exactly, but +1 none the less.
David
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, 29 Mar 2005 13:59:23 -0500, Geir Magnusson Jr
<ge...@4quarters.com> wrote:
>
> On Mar 29, 2005, at 1:43 PM, Bruce Snyder wrote:
>
> >
> > It seems like we're starting to get a good pile of issues identified
> > here that need to happen before work goes into creating a
> > reproduceable release process, not to mention the requirements of the
> > release process. I think we should begin by creating JIRA issues to
> > identify all of this work, but I'm not sure whether to classify these
> > circular dependencies as bugs, improvements or tasks. Anyone have an
> > opinion?
> >
>
> I think they are improvements or tasks :)
>
> But I was also thinking of getting a thread started here on the dev
> list summarizing what we need to do and get going. We're going to need
> this soon, and as long as it's not disruptive to the certification
> effort, we can do in parallel.
I concur, which is why I am trying to identify these items/issues and
record them using JIRA.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 29, 2005, at 1:43 PM, Bruce Snyder wrote:
>
> It seems like we're starting to get a good pile of issues identified
> here that need to happen before work goes into creating a
> reproduceable release process, not to mention the requirements of the
> release process. I think we should begin by creating JIRA issues to
> identify all of this work, but I'm not sure whether to classify these
> circular dependencies as bugs, improvements or tasks. Anyone have an
> opinion?
>
I think they are improvements or tasks :)
But I was also thinking of getting a thread started here on the dev
list summarizing what we need to do and get going. We're going to need
this soon, and as long as it's not disruptive to the certification
effort, we can do in parallel.
geir
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, 29 Mar 2005 10:29:14 -0800, David Jencks <dj...@apache.org> wrote:
> As usual, I'm afraid I was less clear than mud.
> On Mar 29, 2005, at 10:09 AM, Alan D. Cabrera wrote:
>
> > 1. Agreed. This should be a non-issue shortly.
>
> I'm not referring to the current "maven detects circular dependencies
> in uber-build" problem but rather the problem that the uberbuild is the
> only way to build geronimo + openejb starting from a repo with no
> geronimo and openejb artifacts. Openejb depends on various geronimo
> modules whereas assembly depends on openejb. We need a way to build
> something like specs/tranql/(g. modules - assembly)/openejb/assembly.
>
> > 2. This is a tall order, IMHO. I think that this is a goal that
> > should be vigorously sought but I don't think that it should stop a
> > milestone release. Maybe a v1.0 release, I'll grant you that.
>
> I agree. I'd like to eliminate privately patched jars but try to
> minimize snapshots.
It seems like we're starting to get a good pile of issues identified
here that need to happen before work goes into creating a
reproduceable release process, not to mention the requirements of the
release process. I think we should begin by creating JIRA issues to
identify all of this work, but I'm not sure whether to classify these
circular dependencies as bugs, improvements or tasks. Anyone have an
opinion?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Jencks <dj...@apache.org>.
As usual, I'm afraid I was less clear than mud.
On Mar 29, 2005, at 10:09 AM, Alan D. Cabrera wrote:
> 1. Agreed. This should be a non-issue shortly.
I'm not referring to the current "maven detects circular dependencies
in uber-build" problem but rather the problem that the uberbuild is the
only way to build geronimo + openejb starting from a repo with no
geronimo and openejb artifacts. Openejb depends on various geronimo
modules whereas assembly depends on openejb. We need a way to build
something like specs/tranql/(g. modules - assembly)/openejb/assembly.
> 2. This is a tall order, IMHO. I think that this is a goal that
> should be vigorously sought but I don't think that it should stop a
> milestone release. Maybe a v1.0 release, I'll grant you that.
I agree. I'd like to eliminate privately patched jars but try to
minimize snapshots.
thanks
david jencks
>
>
> Regards,
> Alan
>
>
> David Jencks wrote:
>
>> I will -1 any milestone release proposal until these issues are taken
>> care of in a way I consider satisfactory:
>>
>> 1. circular build dependencies between openejb and geronimo. I've
>> proposed a simple solution that would not involve moving any code and
>> will repeat the suggestion if requested. A better solution would
>> move assembly out of modules.
>>
>> 2. dependence on privately patched jars or even snapshots of other
>> projects. Currently the only private patch I know of is of Jetty and
>> I hope to resolve this shortly. I would definitely prefer that we
>> minimize the number of snapshots of other projects, especially axis.
>>
>> In addition I would prefer that we move to xmlbeans 2 or provide a
>> convincing argument why not.
>>
>> thanks
>> david jencks
>>
>> On Mar 29, 2005, at 9:12 AM, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>>>
>>>>
>>>>
>>>> Geir Magnusson Jr. wrote:
>>>>
>>>>>
>>>>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>>>>
>>>>>> -1
>>>>>>
>>>>>
>>>>> We'll ignore this as it isn't a vote :)
>>>>>
>>>>>> Whilst I agree with the intention, we do not have a process
>>>>>> defined that would allow us to generate a reproducable release.
>>>>>> This led to several of the issues with the last M3 release that
>>>>>> ultimately made is unusable. We must fix this before we can
>>>>>> release another version.
>>>>>>
>>>>>> Specific things I think we need include in such a process:
>>>>>> * an mechanical process for producing the candidate binaries that
>>>>>> can be
>>>>>> executed against any SVN tag. This would reduce the potential
>>>>>> for
>>>>>> minor variations by people doing the release that would result
>>>>>> in
>>>>>> potentially different binaries
>>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>>> * elimination of SNAPSHOT dependencies - these are by nature
>>>>>> ephemeral
>>>>>> making it impossible to later regenerate the same distribution
>>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>>> * a testing/review period that is at least comprehensive enough
>>>>>> to catch
>>>>>> the blaring defects that plagued M3
>>>>>
>>>>>
>>>>>
>>>>> yes
>>>>>
>>>>>>
>>>>>> * verification that the src bundle actually builds and results in
>>>>>> the
>>>>>> same binary as we are distibuting
>>>>>
>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>> All of these were the standard way for other projects I've been
>>>>> involved with. No argument.
>>>>>
>>>>> But can we, with this in mind, first discuss going forward w/ a
>>>>> release? We're going to have to bang out a real release process
>>>>> for 1.0, and this is a good opportunity to get started. I
>>>>> volunteer to help.
>>>>
>>>>
>>>>
>>>> Is now a good time to talk about how Geornimo needs its own remote
>>>> maven repo?
>>>
>>>
>>> Heh. I was just thinking about that, and also about the subject of
>>> OpenEJB - would there be good benefit into bringing it to Geronimo?
>>> We seem to be so interdependent...
>>>
>>> geir
>>>
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>>
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org
>>>
>
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
1. Agreed. This should be a non-issue shortly.
2. This is a tall order, IMHO. I think that this is a goal that should
be vigorously sought but I don't think that it should stop a milestone
release. Maybe a v1.0 release, I'll grant you that.
Regards,
Alan
David Jencks wrote:
> I will -1 any milestone release proposal until these issues are taken
> care of in a way I consider satisfactory:
>
> 1. circular build dependencies between openejb and geronimo. I've
> proposed a simple solution that would not involve moving any code and
> will repeat the suggestion if requested. A better solution would move
> assembly out of modules.
>
> 2. dependence on privately patched jars or even snapshots of other
> projects. Currently the only private patch I know of is of Jetty and
> I hope to resolve this shortly. I would definitely prefer that we
> minimize the number of snapshots of other projects, especially axis.
>
> In addition I would prefer that we move to xmlbeans 2 or provide a
> convincing argument why not.
>
> thanks
> david jencks
>
> On Mar 29, 2005, at 9:12 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>>
>>>
>>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>>
>>>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>>>
>>>>> -1
>>>>>
>>>>
>>>> We'll ignore this as it isn't a vote :)
>>>>
>>>>> Whilst I agree with the intention, we do not have a process
>>>>> defined that would allow us to generate a reproducable release.
>>>>> This led to several of the issues with the last M3 release that
>>>>> ultimately made is unusable. We must fix this before we can
>>>>> release another version.
>>>>>
>>>>> Specific things I think we need include in such a process:
>>>>> * an mechanical process for producing the candidate binaries that
>>>>> can be
>>>>> executed against any SVN tag. This would reduce the potential for
>>>>> minor variations by people doing the release that would result in
>>>>> potentially different binaries
>>>>>
>>>>
>>>> Yes
>>>>
>>>>> * elimination of SNAPSHOT dependencies - these are by nature
>>>>> ephemeral
>>>>> making it impossible to later regenerate the same distribution
>>>>>
>>>>
>>>> Yes
>>>>
>>>>> * a testing/review period that is at least comprehensive enough to
>>>>> catch
>>>>> the blaring defects that plagued M3
>>>>
>>>>
>>>>
>>>> yes
>>>>
>>>>>
>>>>> * verification that the src bundle actually builds and results in the
>>>>> same binary as we are distibuting
>>>>
>>>>
>>>>
>>>> Yes
>>>>
>>>> All of these were the standard way for other projects I've been
>>>> involved with. No argument.
>>>>
>>>> But can we, with this in mind, first discuss going forward w/ a
>>>> release? We're going to have to bang out a real release process
>>>> for 1.0, and this is a good opportunity to get started. I
>>>> volunteer to help.
>>>
>>>
>>>
>>> Is now a good time to talk about how Geornimo needs its own remote
>>> maven repo?
>>
>>
>> Heh. I was just thinking about that, and also about the subject of
>> OpenEJB - would there be good benefit into bringing it to Geronimo?
>> We seem to be so interdependent...
>>
>> geir
>>
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Jencks <dj...@gluecode.com>.
I will -1 any milestone release proposal until these issues are taken
care of in a way I consider satisfactory:
1. circular build dependencies between openejb and geronimo. I've
proposed a simple solution that would not involve moving any code and
will repeat the suggestion if requested. A better solution would move
assembly out of modules.
2. dependence on privately patched jars or even snapshots of other
projects. Currently the only private patch I know of is of Jetty and I
hope to resolve this shortly. I would definitely prefer that we
minimize the number of snapshots of other projects, especially axis.
In addition I would prefer that we move to xmlbeans 2 or provide a
convincing argument why not.
thanks
david jencks
On Mar 29, 2005, at 9:12 AM, Geir Magnusson Jr. wrote:
>
> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>
>>
>>
>> Geir Magnusson Jr. wrote:
>>
>>>
>>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>>
>>>> -1
>>>>
>>>
>>> We'll ignore this as it isn't a vote :)
>>>
>>>> Whilst I agree with the intention, we do not have a process defined
>>>> that would allow us to generate a reproducable release. This led
>>>> to several of the issues with the last M3 release that ultimately
>>>> made is unusable. We must fix this before we can release another
>>>> version.
>>>>
>>>> Specific things I think we need include in such a process:
>>>> * an mechanical process for producing the candidate binaries that
>>>> can be
>>>> executed against any SVN tag. This would reduce the potential for
>>>> minor variations by people doing the release that would result in
>>>> potentially different binaries
>>>>
>>>
>>> Yes
>>>
>>>> * elimination of SNAPSHOT dependencies - these are by nature
>>>> ephemeral
>>>> making it impossible to later regenerate the same distribution
>>>>
>>>
>>> Yes
>>>
>>>> * a testing/review period that is at least comprehensive enough to
>>>> catch
>>>> the blaring defects that plagued M3
>>>
>>>
>>> yes
>>>
>>>>
>>>> * verification that the src bundle actually builds and results in
>>>> the
>>>> same binary as we are distibuting
>>>
>>>
>>> Yes
>>>
>>> All of these were the standard way for other projects I've been
>>> involved with. No argument.
>>>
>>> But can we, with this in mind, first discuss going forward w/ a
>>> release? We're going to have to bang out a real release process for
>>> 1.0, and this is a good opportunity to get started. I volunteer to
>>> help.
>>
>>
>> Is now a good time to talk about how Geornimo needs its own remote
>> maven repo?
>
> Heh. I was just thinking about that, and also about the subject of
> OpenEJB - would there be good benefit into bringing it to Geronimo?
> We seem to be so interdependent...
>
> geir
>
>>
>>
>> Regards,
>> Alan
>>
>>
>>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
Re: [PROPOSAL] Next milestone release (M4?)
Posted by David Blevins <da...@visi.com>.
On Tue, Mar 29, 2005 at 12:12:25PM -0500, Geir Magnusson Jr. wrote:
>
> On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
> >
> >Is now a good time to talk about how Geornimo needs its own remote
> >maven repo?
>
> Heh. I was just thinking about that, and also about the subject of
> OpenEJB - would there be good benefit into bringing it to Geronimo? We
> seem to be so interdependent...
If you want to have that conversation, we should do it on the OpenEJB users list where all the OpenEJB committers and users can give their feedback.
user-subscribe@openejb.org
-David
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote:
>
>
> Geir Magnusson Jr. wrote:
>
>>
>> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>>
>>> -1
>>>
>>
>> We'll ignore this as it isn't a vote :)
>>
>>> Whilst I agree with the intention, we do not have a process defined
>>> that would allow us to generate a reproducable release. This led to
>>> several of the issues with the last M3 release that ultimately made
>>> is unusable. We must fix this before we can release another
>>> version.
>>>
>>> Specific things I think we need include in such a process:
>>> * an mechanical process for producing the candidate binaries that
>>> can be
>>> executed against any SVN tag. This would reduce the potential for
>>> minor variations by people doing the release that would result in
>>> potentially different binaries
>>>
>>
>> Yes
>>
>>> * elimination of SNAPSHOT dependencies - these are by nature
>>> ephemeral
>>> making it impossible to later regenerate the same distribution
>>>
>>
>> Yes
>>
>>> * a testing/review period that is at least comprehensive enough to
>>> catch
>>> the blaring defects that plagued M3
>>
>>
>> yes
>>
>>>
>>> * verification that the src bundle actually builds and results in the
>>> same binary as we are distibuting
>>
>>
>> Yes
>>
>> All of these were the standard way for other projects I've been
>> involved with. No argument.
>>
>> But can we, with this in mind, first discuss going forward w/ a
>> release? We're going to have to bang out a real release process for
>> 1.0, and this is a good opportunity to get started. I volunteer to
>> help.
>
>
> Is now a good time to talk about how Geornimo needs its own remote
> maven repo?
Heh. I was just thinking about that, and also about the subject of
OpenEJB - would there be good benefit into bringing it to Geronimo? We
seem to be so interdependent...
geir
>
>
> Regards,
> Alan
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Geir Magnusson Jr. wrote:
>
> On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
>
>> -1
>>
>
> We'll ignore this as it isn't a vote :)
>
>> Whilst I agree with the intention, we do not have a process defined
>> that would allow us to generate a reproducable release. This led to
>> several of the issues with the last M3 release that ultimately made
>> is unusable. We must fix this before we can release another version.
>>
>> Specific things I think we need include in such a process:
>> * an mechanical process for producing the candidate binaries that can be
>> executed against any SVN tag. This would reduce the potential for
>> minor variations by people doing the release that would result in
>> potentially different binaries
>>
>
> Yes
>
>> * elimination of SNAPSHOT dependencies - these are by nature ephemeral
>> making it impossible to later regenerate the same distribution
>>
>
> Yes
>
>> * a testing/review period that is at least comprehensive enough to catch
>> the blaring defects that plagued M3
>
>
> yes
>
>>
>> * verification that the src bundle actually builds and results in the
>> same binary as we are distibuting
>
>
> Yes
>
> All of these were the standard way for other projects I've been
> involved with. No argument.
>
> But can we, with this in mind, first discuss going forward w/ a
> release? We're going to have to bang out a real release process for
> 1.0, and this is a good opportunity to get started. I volunteer to help.
Is now a good time to talk about how Geornimo needs its own remote maven
repo?
Regards,
Alan
Re: [PROPOSAL] Next milestone release (M4?)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote:
> -1
>
We'll ignore this as it isn't a vote :)
> Whilst I agree with the intention, we do not have a process defined
> that would allow us to generate a reproducable release. This led to
> several of the issues with the last M3 release that ultimately made is
> unusable. We must fix this before we can release another version.
>
> Specific things I think we need include in such a process:
> * an mechanical process for producing the candidate binaries that can
> be
> executed against any SVN tag. This would reduce the potential for
> minor variations by people doing the release that would result in
> potentially different binaries
>
Yes
> * elimination of SNAPSHOT dependencies - these are by nature ephemeral
> making it impossible to later regenerate the same distribution
>
Yes
> * a testing/review period that is at least comprehensive enough to
> catch
> the blaring defects that plagued M3
yes
>
> * verification that the src bundle actually builds and results in the
> same binary as we are distibuting
Yes
All of these were the standard way for other projects I've been
involved with. No argument.
But can we, with this in mind, first discuss going forward w/ a
release? We're going to have to bang out a real release process for
1.0, and this is a good opportunity to get started. I volunteer to
help.
geir
>
> I am sure there are more
> --
> Jeremy
>
> Geir Magnusson Jr. wrote:
>> (From a tangential discussion on pmc@, this came up and Alan noted
>> this would be better discussed here, so I'm just moving it here....)
>> It's been 5 months since the M3 milestone release, and a *tremendous*
>> work has gone into the project since then.
>> We think we're functionally complete (or very close), so is now a
>> good time to do a milestone? I'm willing to help with the mechanics
>> to keep Dain and David (and others) cranking on certification work...
>> Comments?
>> geir
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [PROPOSAL] Next milestone release (M4?)
Posted by Jeremy Boynes <jb...@apache.org>.
-1
Whilst I agree with the intention, we do not have a process defined that
would allow us to generate a reproducable release. This led to several
of the issues with the last M3 release that ultimately made is unusable.
We must fix this before we can release another version.
Specific things I think we need include in such a process:
* an mechanical process for producing the candidate binaries that can be
executed against any SVN tag. This would reduce the potential for
minor variations by people doing the release that would result in
potentially different binaries
* elimination of SNAPSHOT dependencies - these are by nature ephemeral
making it impossible to later regenerate the same distribution
* a testing/review period that is at least comprehensive enough to catch
the blaring defects that plagued M3
* verification that the src bundle actually builds and results in the
same binary as we are distibuting
I am sure there are more
--
Jeremy
Geir Magnusson Jr. wrote:
> (From a tangential discussion on pmc@, this came up and Alan noted this
> would be better discussed here, so I'm just moving it here....)
>
> It's been 5 months since the M3 milestone release, and a *tremendous*
> work has gone into the project since then.
>
> We think we're functionally complete (or very close), so is now a good
> time to do a milestone? I'm willing to help with the mechanics to keep
> Dain and David (and others) cranking on certification work...
>
> Comments?
>
> geir
>