You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2005/07/11 12:06:44 UTC
M4 - QA Branch details
Branch Location:
svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
Build:
http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
Re: M4 - QA Branch details
Posted by David Jencks <dj...@gluecode.com>.
I would prefer to hold off any announcements until we have fixed the
big problems we know about (ws deployment, corba)
david jencks
On Jul 11, 2005, at 2:16 PM, Jacek Laskowski wrote:
> David Blevins wrote:
>> Branch Location:
>> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>> Build:
>> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
>> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>
> Do you think it's worth to announce it on Geronimo website?
>
> What files in the repository should the change go? What's the process
> of publishing our website changes?
>
> Jacek
>
>
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 5:16 PM, Jacek Laskowski wrote:
> David Blevins wrote:
>
>> Branch Location:
>> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>> Build:
>> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
>> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>>
>
> Do you think it's worth to announce it on Geronimo website?
No.. I think we should wait until
a) all problems are resolved
b) we vote on releasing it
>
> What files in the repository should the change go? What's the
> process of publishing our website changes?
Darn simple :
1) checkout the /site directory of the geronimo repository.
2) Make sure you have ant installed
3) When it comes time to announce, we add to the xdocs/index.xml as a
new news item
4) in the site directory, run "ant"
5) look at docs/index.html to see if you like it
6) svn commit to get the changes (both source and output) into SVN
7) Go to minotaur -> cd /www/geronimo.apache.org/ -> `cat UPDATE`
Then you are done. it will take up to 4 hours for the changes on
minotaur to be replicated to the live site, depending when in the 4
hour cycle you do the update, of course.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by Jacek Laskowski <jl...@apache.org>.
David Blevins wrote:
> Branch Location:
>
> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>
> Build:
>
> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>
> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
Do you think it's worth to announce it on Geronimo website?
What files in the repository should the change go? What's the process of
publishing our website changes?
Jacek
Re: M4 - QA Branch details
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Please, please, let's update whatever does this to include the
installer package! I strongly believe that has to be part of our basic
release process!
Aaron
On Mon, 11 Jul 2005, David Blevins wrote:
> Branch Location:
>
> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>
> Build:
>
> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>
> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Cool.
I assume that we all play and test this for some period?
Then we vote to release.
geir
On Jul 11, 2005, at 6:06 AM, David Blevins wrote:
> Branch Location:
>
> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>
> Build:
>
> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>
> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 11, 2005 at 01:20:15PM +0200, Jacek Laskowski wrote:
> David Blevins wrote:
> >Branch Location:
> >
> > svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
> >
> >Build:
> >
> > http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
> >
> > 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> > 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> > 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> > 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> > 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> > 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> > 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> > 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> > 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> > 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> > 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> > 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>
> How did you do that? A step-by-step procedure would be very appreciated.
> We should put it on Wiki so that the next time someone else won't have
> to reinvent the wheel.
>
Created the branch with this command:
svn copy https://svn.apache.org/repos/asf/geronimo/trunk https://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA -m "QA Branch for 1.0-M4"
I copied this script and hard coded it specifically to create the
above package: http://svn.apache.org/repos/asf/geronimo/scripts/publish_build.sh.
Want to make it all nice and reusable at some point.
I made the email by hand.
-David
Re: M4 - QA Branch details
Posted by Jacek Laskowski <jl...@apache.org>.
David Blevins wrote:
> Branch Location:
>
> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>
> Build:
>
> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>
> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
How did you do that? A step-by-step procedure would be very appreciated.
We should put it on Wiki so that the next time someone else won't have
to reinvent the wheel.
Jacek
Re: M4 - QA Branch details
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Geir Magnusson Jr. wrote, On 7/11/2005 4:12 PM:
>
> On Jul 11, 2005, at 7:05 PM, Alan D. Cabrera wrote:
>
>> Geir Magnusson Jr. wrote, On 7/11/2005 3:46 PM:
>>
>>
>>>
>>> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
>>>
>>>
>>>> Not technically true. We can generate our own snapshots, e.g.
>>>>
>>>> outside-project-GERONIMO-200507111432.jar
>>>>
>>>> The problem is that there are a *ton* of projects that we use.
>>>>
>>>
>>>
>>> I think this is a bad idea. We would be in effect publishing/
>>> distributing software that
>>>
>>> <snip>Some arguments against it</snip>
>>>
>>
>> I've given this some more thought.
>>
>> I would hope that any project who's version is SNAPSHOT that we rely
>> on is a project where there is close to 100% overlap, otherwise we
>> would just be asking for trouble to begin with. I think that the
>> number of projects is actually quite small. I'm thinking 3-4
>> projects. Should be simple enough to get them to make their own M4
>> snapshots, no?
>>
>
> no. er, yes. er, I agree with you, no?
Yes, but, it sounds so much better when it seems like it was my idea.
Regards,
Alan
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 7:05 PM, Alan D. Cabrera wrote:
> Geir Magnusson Jr. wrote, On 7/11/2005 3:46 PM:
>
>
>>
>> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
>>
>>
>>> Not technically true. We can generate our own snapshots, e.g.
>>>
>>> outside-project-GERONIMO-200507111432.jar
>>>
>>> The problem is that there are a *ton* of projects that we use.
>>>
>>
>>
>> I think this is a bad idea. We would be in effect publishing/
>> distributing software that
>>
>> <snip>Some arguments against it</snip>
>>
>
> I've given this some more thought.
>
> I would hope that any project who's version is SNAPSHOT that we
> rely on is a project where there is close to 100% overlap,
> otherwise we would just be asking for trouble to begin with. I
> think that the number of projects is actually quite small. I'm
> thinking 3-4 projects. Should be simple enough to get them to make
> their own M4 snapshots, no?
>
no. er, yes. er, I agree with you, no?
>
>
> Regards,
> Alan
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Geir Magnusson Jr. wrote, On 7/11/2005 3:46 PM:
>
> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
>
>> Not technically true. We can generate our own snapshots, e.g.
>>
>> outside-project-GERONIMO-200507111432.jar
>>
>> The problem is that there are a *ton* of projects that we use.
>
>
> I think this is a bad idea. We would be in effect publishing/
> distributing software that
>
> <snip>Some arguments against it</snip>
I've given this some more thought.
I would hope that any project who's version is SNAPSHOT that we rely on
is a project where there is close to 100% overlap, otherwise we would
just be asking for trouble to begin with. I think that the number of
projects is actually quite small. I'm thinking 3-4 projects. Should be
simple enough to get them to make their own M4 snapshots, no?
Regards,
Alan
Re: M4 - QA Branch details
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 11, 2005 at 06:46:53PM -0400, Geir Magnusson Jr. wrote:
> When we create software for distribution, which is exactly what we'd
> be doing here, we are making a statement that this software conforms
> to the ASF process for IP provenance, oversight, etc...
Aren't we doing that anyway? Specifically, I don't see how the rules
change if we rename foo-SNAPSHOT.jar to foo-200507111245.jar.
Not arguing, I don't grok this stuff.
-David
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 11:07 PM, sissonj@insession.com wrote:
>
> It seems that there is no practical way of removing all SNAPSHOTs
> (without
> having our own specially built "temporary" versions). For example,
> I sent
> a mail to the cglib dev list asking them to post their latest
> version to
> the maven repo and I haven't got a response in approx 2 weeks.
> Maybe they
> are busy or maybe they are on holidays. My point is that I don't
> think it
> is always going to be possible to get a project (that isn't one of the
> projects we are tight with) to build a special version for us when
> we want
> it.
>
> It appears we have already been building defacto releases of external
> libraries, e.g. the cglib library in our repo:
> http://cvs.apache.org/repository/cglib/jars/
You're right - there is a problem we have to deal with, but I'd
rather see us try another approach to make things very clear and
accountable.
For any code that we must do this to we could adopt a strategery :
1) Make a copy in Apache SVN. This code must be appropriately
licensed (the Apache License) and there should be a very clear NOTICE
about the source, what we're doing, that it's not a fork, etc, etc....
2) Produce a jar :
geronimo-private-cglib-20050711.jar
3) put that in
geronimo/jars
So it's very clear that it's not a release by CGLib, but rather code
from us, by us, from our repo.
>
> Maybe a compromise is to properly document in the release notes any
> special versions of code we have with the following information:
>
> * Have a disclaimer stating that a special version of the library
> is being
> used temporarily and we plan on moving to the a formal release of the
> library as soon as possible. Maybe mention there could be a
> 'chance' of
> compatibility issues when we move to the formal version?
> * A description of why a special version of a library is needed and
> what
> the library is used by
> * The version of the code that was patched
> * A link/reference to the bug/issue tracking records for the
> problem with
> the library and the patch(s) that were submitted to the external
> project.
Yes - all good, in that NOTICE in SVN, and also in the distribution
release notes.
[SNIP]
>>
>>
>>> Something I haven't considered is what if the SNAPSHOTs we are
>>> depending
>>> upon are also depending upon SNAPSHOTs. Looks like we need to dump
>>> the
>>> whole tree of dependencies and identify where the SNAPSHOTs are?
>>>
>>
>> Yes! Get rid of all snapshots in anything we distribute as a release
>> of any sort.
>>
>
> Are you suggesting in the M4 release?
>
I can dream...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by si...@insession.com.
"Geir Magnusson Jr." <ge...@apache.org> wrote on 12/07/2005 10:21:24 AM:
> >>
> >> I mean, would you like to see geronimo-kernel-
> >> jboss-200507111423.jar? Or have to deal with questions about
> >> stacktraces and behavior that we just can't understand because it
> >> comes from code that really isn't ours?
> >>
> >
> > Yes I would prefer that to the current situation of using SNAPSHOTs.
>
> I think that we're all in agreement to dump the snapshots. And I'm
> not arguing against using datestamped releases of things if they come
> from the source project - I find that *vastly* preferable to
> SNAPSHOTS as long as the source of that dated thingy is recorded
> somewhere.
>
> What I'm arguing against is the Geronimo project creating de facto
> releases of other projects code for a bunch of reasons, including
> that we'd never tolerated it being done by others.
>
>
> > Just
> > say a user does send us a stack trace.. If they are using
> > SNAPSHOTs, how
> > do we know what day/time their SNAPSHOT was taken? How do we go about
> > reproducing their problem considering that if we try to rebuild
> > Geronimo
> > to match their environment we will most likely end up with something
> > different, since some of the SNAPSHOT dependencies have been updated
> > since.
> >
>
> Right. Agreed. No SNAPSHOTS.
>
> But for what I was arguing, take it a step further - that the user is
> using a gernonimo-kernel jar produces by some *other* project, with
> code that's not even in our SVN. Forget the date time - you could
> search forever and *never* find the code that could produce the
> stacktrace :)
>
> That's what we could potentially be doing to other projects if we
> release their stuff with patches, for example.
It seems that there is no practical way of removing all SNAPSHOTs (without
having our own specially built "temporary" versions). For example, I sent
a mail to the cglib dev list asking them to post their latest version to
the maven repo and I haven't got a response in approx 2 weeks. Maybe they
are busy or maybe they are on holidays. My point is that I don't think it
is always going to be possible to get a project (that isn't one of the
projects we are tight with) to build a special version for us when we want
it.
It appears we have already been building defacto releases of external
libraries, e.g. the cglib library in our repo:
http://cvs.apache.org/repository/cglib/jars/
Maybe a compromise is to properly document in the release notes any
special versions of code we have with the following information:
* Have a disclaimer stating that a special version of the library is being
used temporarily and we plan on moving to the a formal release of the
library as soon as possible. Maybe mention there could be a 'chance' of
compatibility issues when we move to the formal version?
* A description of why a special version of a library is needed and what
the library is used by
* The version of the code that was patched
* A link/reference to the bug/issue tracking records for the problem with
the library and the patch(s) that were submitted to the external project.
Users would appreciate the openness and can then make their own decision
on whether they are willing to run their systems on the software. They
aren't given that information at the moment.
If users want to report a problem with a library to an external library
project, they are going to be asked what version they are using and they
should see from our documentation (or by the name of the JAR in the
repository) that it is a special version.
>
> > Something I haven't considered is what if the SNAPSHOTs we are
> > depending
> > upon are also depending upon SNAPSHOTs. Looks like we need to dump
> > the
> > whole tree of dependencies and identify where the SNAPSHOTs are?
>
> Yes! Get rid of all snapshots in anything we distribute as a release
> of any sort.
Are you suggesting in the M4 release?
>
> >
> >
> >>
> >> Now, I realize that we are really close to some projects (like have
> >> 100% committer overlap) so you might say that we do have a clue, but
> >> I wouldn't want to set the practice, if we are so close then why not
> >> just do it 'there', etc
> >>
> >> When we create software for distribution, which is exactly what we'd
> >> be doing here, we are making a statement that this software conforms
> >> to the ASF process for IP provenance, oversight, etc...
> >>
> >
> >
> >
> > How are we going to deal with the situation where just before a
> > release or
> > after a release a serious bug is found where changes are needed to
> > be made
> > to a dependency. Users are not going to accept "Oh, we can't ship
> > a new
> > release until dependency x fixes the problem and ships a formal
> > release,
> > which may be a week or it may be a year".
>
> Well, that's true - but we're not facing that kind of emergency
> situation here. And if dependency X takes a year, and this is a
> major dependency of ours, I'd vote to just get a copy of the source
> and keep going with that.... :)
>
> I hope we never face this.
>
> geir
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
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: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 7:53 PM, sissonj@insession.com wrote:
> "Geir Magnusson Jr." <ge...@apache.org> wrote on 12/07/2005
> 08:46:53 AM:
>>
>> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
>>
>>>
>>> Not technically true. We can generate our own snapshots, e.g.
>>>
>>> outside-project-GERONIMO-200507111432.jar
>>>
>>> The problem is that there are a *ton* of projects that we use.
>>>
>>
>> I think this is a bad idea. We would be in effect publishing/
>> distributing software that
>>
>> a) isn't ours in that we have no real clue over the provenance and
>>
>> b) isn't something we'd want to see done to us.
>>
>> I mean, would you like to see geronimo-kernel-
>> jboss-200507111423.jar? Or have to deal with questions about
>> stacktraces and behavior that we just can't understand because it
>> comes from code that really isn't ours?
>>
>
> Yes I would prefer that to the current situation of using SNAPSHOTs.
I think that we're all in agreement to dump the snapshots. And I'm
not arguing against using datestamped releases of things if they come
from the source project - I find that *vastly* preferable to
SNAPSHOTS as long as the source of that dated thingy is recorded
somewhere.
What I'm arguing against is the Geronimo project creating de facto
releases of other projects code for a bunch of reasons, including
that we'd never tolerated it being done by others.
> Just
> say a user does send us a stack trace.. If they are using
> SNAPSHOTs, how
> do we know what day/time their SNAPSHOT was taken? How do we go about
> reproducing their problem considering that if we try to rebuild
> Geronimo
> to match their environment we will most likely end up with something
> different, since some of the SNAPSHOT dependencies have been updated
> since.
>
Right. Agreed. No SNAPSHOTS.
But for what I was arguing, take it a step further - that the user is
using a gernonimo-kernel jar produces by some *other* project, with
code that's not even in our SVN. Forget the date time - you could
search forever and *never* find the code that could produce the
stacktrace :)
That's what we could potentially be doing to other projects if we
release their stuff with patches, for example.
> Something I haven't considered is what if the SNAPSHOTs we are
> depending
> upon are also depending upon SNAPSHOTs. Looks like we need to dump
> the
> whole tree of dependencies and identify where the SNAPSHOTs are?
Yes! Get rid of all snapshots in anything we distribute as a release
of any sort.
>
>
>>
>> Now, I realize that we are really close to some projects (like have
>> 100% committer overlap) so you might say that we do have a clue, but
>> I wouldn't want to set the practice, if we are so close then why not
>> just do it 'there', etc
>>
>> When we create software for distribution, which is exactly what we'd
>> be doing here, we are making a statement that this software conforms
>> to the ASF process for IP provenance, oversight, etc...
>>
>
>
>
> How are we going to deal with the situation where just before a
> release or
> after a release a serious bug is found where changes are needed to
> be made
> to a dependency. Users are not going to accept "Oh, we can't ship
> a new
> release until dependency x fixes the problem and ships a formal
> release,
> which may be a week or it may be a year".
Well, that's true - but we're not facing that kind of emergency
situation here. And if dependency X takes a year, and this is a
major dependency of ours, I'd vote to just get a copy of the source
and keep going with that.... :)
I hope we never face this.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by si...@insession.com.
"Geir Magnusson Jr." <ge...@apache.org> wrote on 12/07/2005 08:46:53 AM:
>
> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
>
> > Geir Magnusson Jr. wrote, On 7/11/2005 5:39 AM:
> >
> >
> >>
> >> On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote:
> >>
> >>
> >>> sissonj@insession.com wrote:
> >>>
> >>>
> >>>
> >>>> Can't we resolve the SNAPSHOTs issue by modifying the branch
> >>>> before releasing and at least using dated jar files if we can't
> >>>> move to a formal release of a dependency?
> >>>>
> >>>>
> >>>
> >>> How could we use the dated jar files? Do they have to be
> >>> released by respective projects or can we do it ourselves?
> >>>
> >>
> >>
> >> They have to be released by respective projects.
> >>
> >
> > Not technically true. We can generate our own snapshots, e.g.
> >
> > outside-project-GERONIMO-200507111432.jar
> >
> > The problem is that there are a *ton* of projects that we use.
>
> I think this is a bad idea. We would be in effect publishing/
> distributing software that
>
> a) isn't ours in that we have no real clue over the provenance and
>
> b) isn't something we'd want to see done to us.
>
> I mean, would you like to see geronimo-kernel-
> jboss-200507111423.jar? Or have to deal with questions about
> stacktraces and behavior that we just can't understand because it
> comes from code that really isn't ours?
Yes I would prefer that to the current situation of using SNAPSHOTs. Just
say a user does send us a stack trace.. If they are using SNAPSHOTs, how
do we know what day/time their SNAPSHOT was taken? How do we go about
reproducing their problem considering that if we try to rebuild Geronimo
to match their environment we will most likely end up with something
different, since some of the SNAPSHOT dependencies have been updated
since.
Something I haven't considered is what if the SNAPSHOTs we are depending
upon are also depending upon SNAPSHOTs. Looks like we need to dump the
whole tree of dependencies and identify where the SNAPSHOTs are?
>
> Now, I realize that we are really close to some projects (like have
> 100% committer overlap) so you might say that we do have a clue, but
> I wouldn't want to set the practice, if we are so close then why not
> just do it 'there', etc
>
> When we create software for distribution, which is exactly what we'd
> be doing here, we are making a statement that this software conforms
> to the ASF process for IP provenance, oversight, etc...
How are we going to deal with the situation where just before a release or
after a release a serious bug is found where changes are needed to be made
to a dependency. Users are not going to accept "Oh, we can't ship a new
release until dependency x fixes the problem and ships a formal release,
which may be a week or it may be a year".
Here is a (hopefully not too stupid) analogy..
If you buy a car and the brakes fail, would you be happy if the car
company said you had the choice of:
a) to wait until the revised brake components come off one of their
supplier's production lines and they don't know when that is? The car
company cannot expect the production line to tool up immediately just for
them because they are already committed to manufacturing other models of
components for other manufacturers (waiting for a formal version of a
dependency).
b) use some brake components they found lying around at the factory. They
aren't sure when they were made and what revisions may have been made to
their design since and what problems they may have had in their design
(SNAPSHOTs)
c) A technician from the car company takes your brakes and makes some
small modifications to rectify the problem and puts the car through the
standard brake tests and has documented information on what they did
(versioned SNAPSHOTs)
I think this is a serious issue and we need to discuss how this is going
to be addressed going forward.
Thanks,
John
>
> Just my 0.02 :)
>
> geir
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
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: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
> Geir Magnusson Jr. wrote, On 7/11/2005 5:39 AM:
>
>
>>
>> On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote:
>>
>>
>>> sissonj@insession.com wrote:
>>>
>>>
>>>
>>>> Can't we resolve the SNAPSHOTs issue by modifying the branch
>>>> before releasing and at least using dated jar files if we can't
>>>> move to a formal release of a dependency?
>>>>
>>>>
>>>
>>> How could we use the dated jar files? Do they have to be
>>> released by respective projects or can we do it ourselves?
>>>
>>
>>
>> They have to be released by respective projects.
>>
>
> Not technically true. We can generate our own snapshots, e.g.
>
> outside-project-GERONIMO-200507111432.jar
>
> The problem is that there are a *ton* of projects that we use.
I think this is a bad idea. We would be in effect publishing/
distributing software that
a) isn't ours in that we have no real clue over the provenance and
b) isn't something we'd want to see done to us.
I mean, would you like to see geronimo-kernel-
jboss-200507111423.jar? Or have to deal with questions about
stacktraces and behavior that we just can't understand because it
comes from code that really isn't ours?
Now, I realize that we are really close to some projects (like have
100% committer overlap) so you might say that we do have a clue, but
I wouldn't want to set the practice, if we are so close then why not
just do it 'there', etc
When we create software for distribution, which is exactly what we'd
be doing here, we are making a statement that this software conforms
to the ASF process for IP provenance, oversight, etc...
Just my 0.02 :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Geir Magnusson Jr. wrote, On 7/11/2005 5:39 AM:
>
> On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote:
>
>> sissonj@insession.com wrote:
>>
>>
>>> Can't we resolve the SNAPSHOTs issue by modifying the branch
>>> before releasing and at least using dated jar files if we can't
>>> move to a formal release of a dependency?
>>>
>>
>> How could we use the dated jar files? Do they have to be released by
>> respective projects or can we do it ourselves?
>
>
> They have to be released by respective projects.
Not technically true. We can generate our own snapshots, e.g.
outside-project-GERONIMO-200507111432.jar
The problem is that there are a *ton* of projects that we use.
Regards,
Alan
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote:
> sissonj@insession.com wrote:
>
>
>> Can't we resolve the SNAPSHOTs issue by modifying the branch
>> before releasing and at least using dated jar files if we can't
>> move to a formal release of a dependency?
>>
>
> How could we use the dated jar files? Do they have to be released
> by respective projects or can we do it ourselves?
They have to be released by respective projects.
geir
>
>
>> John
>>
>
> Jacek
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by si...@insession.com.
Jacek Laskowski <jl...@apache.org> wrote on 11/07/2005 09:46:03 PM:
> sissonj@insession.com wrote:
>
> > Can't we resolve the SNAPSHOTs issue by modifying the branch before
> > releasing and at least using dated jar files if we can't move to a
formal
> > release of a dependency?
>
> How could we use the dated jar files? Do they have to be released by
> respective projects or can we do it ourselves?
Can someone give us a reason why we can't? I though for a project to be
accepted as a dependency it had to have a license compatible with the ASL.
So I wouldn't have thought licensing would be the issue. Maybe there are
restrictions on what can be placed in Apache's maven repo?
I was wondering whether it would be possible for us to produce dated
(cvs)/versioned (svn) jars of SNAPSHOT dependencies and upload them under
the 'geronimo' maven groupId, so it is obvious they are special versions
of the JARs and they would all appear under maven/geronimo/jars in the
repo?
Are we allowed to do this and what maven repo would we be allowed to place
dated/versioned snapshots?
John
>
> > John
>
> Jacek
>
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: M4 - QA Branch details
Posted by Jacek Laskowski <jl...@apache.org>.
sissonj@insession.com wrote:
> Can't we resolve the SNAPSHOTs issue by modifying the branch before
> releasing and at least using dated jar files if we can't move to a formal
> release of a dependency?
How could we use the dated jar files? Do they have to be released by
respective projects or can we do it ourselves?
> John
Jacek
Re: M4 - QA Branch details
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 7:40 AM, sissonj@insession.com wrote:
> I was a little surprised to see that we haven't resolved the SNAPSHOT
> issue after so many people said it was something they wanted
> resolved in
> M4 (see responses in thread "Re: [PROPOSAL] Next milestone release
> (M4?)".
> Can't we resolve the SNAPSHOTs issue by modifying the branch before
> releasing and at least using dated jar files if we can't move to a
> formal
> release of a dependency?
Yes - we can update this branch as this isn't the M4 release, just
the branch for us to do QA in prep for the eventual vote and release.
geir
>
> John
>
>
> David Blevins <da...@visi.com> wrote on 11/07/2005 08:06:44
> PM:
>
>
>> Branch Location:
>>
>> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>>
>> Build:
>>
>> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>>
>> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
>> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
>> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
>> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
>> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 - QA Branch details
Posted by si...@insession.com.
I was a little surprised to see that we haven't resolved the SNAPSHOT
issue after so many people said it was something they wanted resolved in
M4 (see responses in thread "Re: [PROPOSAL] Next milestone release (M4?)".
Can't we resolve the SNAPSHOTs issue by modifying the branch before
releasing and at least using dated jar files if we can't move to a formal
release of a dependency?
John
David Blevins <da...@visi.com> wrote on 11/07/2005 08:06:44 PM:
> Branch Location:
>
> svn co http://svn.apache.org/repos/asf/geronimo/branches/v1_0_M4-QA
>
> Build:
>
> http://cvs.apache.org/dist/geronimo/unstable/1.0-M4-QA/
>
> 4.0M Jul 11 02:37 geronimo-1.0-M4-QA-src.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.tar.gz.sha
> 8.5M Jul 11 02:37 geronimo-1.0-M4-QA-src.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA-src.zip.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.tar.gz.sha
> 42M Jul 11 02:41 geronimo-1.0-M4-QA.zip
> 33 Jul 11 02:41 geronimo-1.0-M4-QA.zip.md5
> 41 Jul 11 02:41 geronimo-1.0-M4-QA.zip.sha