Stable/Unstable/Sandbox

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Stable/Unstable/Sandbox

Geir Magnusson Jr.
Can we agree that we need to somehow construct the stable, unstable  
and sandbox codebases?

If so, can we move on to how?


geir
--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

ammulder
        Fine with me, though I'm not sure we really need sandbox --
unstable is unstable, right?  Whatever.

        Are we planning that these locations are for modules, and the
kernel and assembly/assemblies will be maintained outside of this
structure?

Aaron

On Tue, 31 May 2005, Geir Magnusson Jr. wrote:

> Can we agree that we need to somehow construct the stable, unstable  
> and sandbox codebases?
>
> If so, can we move on to how?
>
>
> geir
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Geir Magnusson Jr.

On May 31, 2005, at 12:19 PM, Aaron Mulder wrote:

>     Fine with me, though I'm not sure we really need sandbox --
> unstable is unstable, right?  Whatever.

Well, maybe.  For example, refactoring $foo is a lot different than  
adding something new and strange, or dropping in some code for people  
to decide how to introduce into the mainline, etc.

>
>     Are we planning that these locations are for modules, and the
> kernel and assembly/assemblies will be maintained outside of this
> structure?

Good questions :)

I think that assemblies should be outside, because there are lots of  
interesting assemblies that people might want to do that aren't  
J2EE.  For example, a simple Geronimmo server (no API stakc), a  
simple servlet/jsp stack, etc...

geir

>
> Aaron
>
> On Tue, 31 May 2005, Geir Magnusson Jr. wrote:
>
>> Can we agree that we need to somehow construct the stable, unstable
>> and sandbox codebases?
>>
>> If so, can we move on to how?
>>
>>
>> geir
>> --
>> Geir Magnusson Jr                                  +1-203-665-6437
>> [hidden email]
>>
>>
>>
>>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Alan Cabrera
In reply to this post by ammulder
I like the sandbox.  It's a place where people can goof off w/
experimental  stuff and propose significant changes .  I tend to think
that all non-sandbox stuff as things that the Geronimo community is
commited to supporting.


Regards,
Alan

Aaron Mulder wrote, On 5/31/2005 12:19 PM:

> Fine with me, though I'm not sure we really need sandbox --
>unstable is unstable, right?  Whatever.
>
> Are we planning that these locations are for modules, and the
>kernel and assembly/assemblies will be maintained outside of this
>structure?
>
>Aaron
>
>On Tue, 31 May 2005, Geir Magnusson Jr. wrote:
>  
>
>>Can we agree that we need to somehow construct the stable, unstable  
>>and sandbox codebases?
>>
>>If so, can we move on to how?
>>
>>
>>geir
>>--
>>Geir Magnusson Jr                                  +1-203-665-6437
>>[hidden email]
>>
>>
>>
>>    
>>

Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Alan Cabrera
In reply to this post by ammulder


Aaron Mulder wrote, On 5/31/2005 12:19 PM:

> Fine with me, though I'm not sure we really need sandbox --
>unstable is unstable, right?  Whatever.
>
> Are we planning that these locations are for modules, and the
>kernel and assembly/assemblies will be maintained outside of this
>structure?
>  
>
What are the concrete scenarios that we will use to evaluate all the
proposed "solutions"?  Since people are ready to jump into the "how",
they must have the "what" readily available.


Regards,
Alan



Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Bill Stoddard
In reply to this post by Geir Magnusson Jr.
Geir Magnusson Jr. wrote:
> Can we agree that we need to somehow construct the stable, unstable  and
> sandbox codebases?
>
> If so, can we move on to how?
>
>
> geir

Check out the httpd project:

http://svn.apache.org/repos/asf/httpd/httpd/

essential features:
'trunk' is 'development' (unstable) reporitory. It is constantly moving forward under loose rules for what can
be committed.

'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x) constantly move forward but under a
'review-then-commit' policy. All code that goes into the stable branch must be reviewed and voted on before it
can come into the stable branch.

'tags' contains all the tagged releases
http://svn.apache.org/repos/asf/httpd/httpd/branches/

So using this model, one of the geronimo branches could be 1.0.x. When 1.0 is 'done', tag the release and
continue on the next 'stable' drop, migrating function out of trunk and into 1.x using whatever process you
like (RTC, CTR, votes, whatever). The RTC + vote policy httpd 2.0.x uses may be too restrictive for geronimo
1.0.x, so do whatever makes sense for this project.

There will come a day when you want another stable branch of geronimo (presumably forked from trunk). When
that day comes, just create a new tree under 'branches', named differently (maybe 2.0.x or 1.2.x, whatever).

I know this doesn't really answer the more interesting question about how to structure the repository to
support assemblying components into a 'custom' install.

Bill

Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Geir Magnusson Jr.

On May 31, 2005, at 1:37 PM, Bill Stoddard wrote:

> Geir Magnusson Jr. wrote:
>
>> Can we agree that we need to somehow construct the stable,  
>> unstable  and sandbox codebases?
>> If so, can we move on to how?
>> geir
>>
>
> Check out the httpd project:
>
> http://svn.apache.org/repos/asf/httpd/httpd/
>
> essential features:
> 'trunk' is 'development' (unstable) reporitory. It is constantly  
> moving forward under loose rules for what can be committed.
>
> 'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x)  
> constantly move forward but under a 'review-then-commit' policy.  
> All code that goes into the stable branch must be reviewed and  
> voted on before it can come into the stable branch.
>
> 'tags' contains all the tagged releases
> http://svn.apache.org/repos/asf/httpd/httpd/branches/
>
> So using this model, one of the geronimo branches could be 1.0.x.  
> When 1.0 is 'done', tag the release and continue on the next  
> 'stable' drop, migrating function out of trunk and into 1.x using  
> whatever process you like (RTC, CTR, votes, whatever). The RTC +  
> vote policy httpd 2.0.x uses may be too restrictive for geronimo  
> 1.0.x, so do whatever makes sense for this project.
>
> There will come a day when you want another stable branch of  
> geronimo (presumably forked from trunk). When that day comes, just  
> create a new tree under 'branches', named differently (maybe 2.0.x  
> or 1.2.x, whatever).
>
> I know this doesn't really answer the more interesting question  
> about how to structure the repository to support assemblying  
> components into a 'custom' install.

I'm not sure that's important here - we should be able to assemble  
any custom install from parts wherever they are - we can have  
assemblies in both stable an unstable...  The key is that the code in  
stable remain so.

I'm not sure I'm a fan of going to the full degree of "review-then-
commit" right now (but probably in the future when we run 70% of the  
worlds J2EE app server installations ;)  but now a "propose then  
commit" for stable branch might be nice.

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

David Blevins
In reply to this post by Geir Magnusson Jr.
On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
> Can we agree that we need to somehow construct the stable, unstable  
> and sandbox codebases?

I don't think we have agreed on what is stable and what is unstable.  We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications.  That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION."

Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable.  How is that at all fair?

-David
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

David Blevins
On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote:
> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
> > Can we agree that we need to somehow construct the stable, unstable  
> > and sandbox codebases?
>
> I don't think we have agreed on what is stable and what is unstable.  We were having a discussion on the fact that it is now impossible to offer a stable upgrade/patch path for applications.  That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION."
>
> Now Jeremy has proposed that we ignore that discussion and begin cementing what we currently have as stable.  How is that at all fair?
>


Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it.

-David
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Brian K. Wallace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Blevins wrote:
|
| Just going to throw out that I think the only goal we can all agree on
is to not regress on certification once we achieve it.
|
| -David
|
Combined with not slowing down progress on attaining that certification. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCnPbfaCoPKRow/gARAotlAKCpKqZNTRBvUz4yJENzXSYgZM6pAACeOXNn
/Qaa/eRFdNLRRT0ozT02pDc=
=Qex9
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

David Jencks
In reply to this post by David Blevins
(reordered)
> Just going to throw out that I think the only goal we can all agree on
> is to not regress on certification once we achieve it.

I certainly hope we agree on this :-) but hope we can find more to
agree on.

On May 31, 2005, at 4:40 PM, David Blevins wrote:

> On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote:
>> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
>>> Can we agree that we need to somehow construct the stable, unstable
>>> and sandbox codebases?
>>
>> I don't think we have agreed on what is stable and what is unstable.  
>> We were having a discussion on the fact that it is now impossible to
>> offer a stable upgrade/patch path for applications.  That thread was
>> killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION."
>>
>> Now Jeremy has proposed that we ignore that discussion and begin
>> cementing what we currently have as stable.  How is that at all fair?
>>

I don't know about fair, but I am finding this discussion nearly as
distracting as the previous one that we put on hold.  I still don't see
what exotic svn tricks might buy us over normal svn usage, and don't
want to spend a lot of time thinking about it until we pass all the
tests.  I still think everyones perspective may change once we are
passing all the tests and have fixed the few egregious architectural
problems that crept in.

I would like to put this discussion on hold until we pass all the tests

thanks
david jencks

>
>
>
> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Brian K. Wallace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Jencks wrote:
|
| I don't know about fair, but I am finding this discussion nearly as
| distracting as the previous one that we put on hold.  I still don't see
| what exotic svn tricks might buy us over normal svn usage, and don't
| want to spend a lot of time thinking about it until we pass all the
| tests.  I still think everyones perspective may change once we are
| passing all the tests and have fixed the few egregious architectural
| problems that crept in.
|
| I would like to put this discussion on hold until we pass all the tests
|
| thanks
| david jencks

Agreed. I'm still in favor of 'modification of structure' in the
interests of ease of localized maintenance and possible
deployment/deliverable options not currently available, but I'd much
rather put that on a "TODO" list for after certification than take more
time now to discuss it. Very difficult to advocate "certification first"
and "restructure thoughts now" when those involved in the certification
process would undoubtedly need to be in on the restructure thoughts process.

First things first.

My .02

Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCnP38aCoPKRow/gARAuJCAKC6Abi1oUVMJA7Gq9wRAJyUsQo1DgCgprU0
nUtdvbP7y8vvNN4vvQvwVZk=
=7+VS
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Bruce Snyder
In reply to this post by David Jencks
On 5/31/05, David Jencks <[hidden email]> wrote:

> >> I don't think we have agreed on what is stable and what is unstable.
> >> We were having a discussion on the fact that it is now impossible to
> >> offer a stable upgrade/patch path for applications.  That thread was
> >> killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER CERTIFICATION."
> >>
> >> Now Jeremy has proposed that we ignore that discussion and begin
> >> cementing what we currently have as stable.  How is that at all fair?
> >>
>
> I don't know about fair, but I am finding this discussion nearly as
> distracting as the previous one that we put on hold.  I still don't see
> what exotic svn tricks might buy us over normal svn usage, and don't
> want to spend a lot of time thinking about it until we pass all the
> tests.  I still think everyones perspective may change once we are
> passing all the tests and have fixed the few egregious architectural
> problems that crept in.

If you're referring to the circular dependency between Geronimo and
OpenEJB, I agree. This needs to be fixed ASAP.

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/
Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Geir Magnusson Jr.
In reply to this post by David Blevins

On May 31, 2005, at 7:21 PM, David Blevins wrote:

> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
>
>> Can we agree that we need to somehow construct the stable, unstable
>> and sandbox codebases?
>>
>
> I don't think we have agreed on what is stable and what is unstable.

Fair enough - but can we agree that we need the *distinction* and  
then decide what goes *in*?

> We were having a discussion on the fact that it is now impossible  
> to offer a stable upgrade/patch path for applications.  That thread  
> was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL AFTER  
> CERTIFICATION."
>
> Now Jeremy has proposed that we ignore that discussion and begin  
> cementing what we currently have as stable.  How is that at all fair?

I think that what Jeremy has proposed actually fixes that, doesn't it?

We can have a stable area that we focus on going for cert and then  
version 1.0, and a unstable area where innovation and change (like  
the serialization experimentation) can happen - then things that work  
can be brought to stable, w/o affecting the work for cert and 1.0

geir


--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Geir Magnusson Jr.
In reply to this post by David Blevins

On May 31, 2005, at 7:40 PM, David Blevins wrote:

> On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote:
>
>> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
>>
>>> Can we agree that we need to somehow construct the stable, unstable
>>> and sandbox codebases?
>>>
>>
>> I don't think we have agreed on what is stable and what is  
>> unstable.  We were having a discussion on the fact that it is now  
>> impossible to offer a stable upgrade/patch path for applications.  
>> That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL  
>> AFTER CERTIFICATION."
>>
>> Now Jeremy has proposed that we ignore that discussion and begin  
>> cementing what we currently have as stable.  How is that at all fair?
>>
>>
>
>
> Just going to throw out that I think the only goal we can all agree  
> on is to not regress on certification once we achieve it.

I think that's a requirement, certainly in the "stable" tree :)


geir

>
> -David
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

Geir Magnusson Jr.
In reply to this post by David Jencks

On May 31, 2005, at 8:10 PM, David Jencks wrote:

> (reordered)
>
>> Just going to throw out that I think the only goal we can all  
>> agree on is to not regress on certification once we achieve it.
>>
>
> I certainly hope we agree on this :-) but hope we can find more to  
> agree on.
>
> On May 31, 2005, at 4:40 PM, David Blevins wrote:
>
>
>> On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote:
>>
>>> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
>>>
>>>> Can we agree that we need to somehow construct the stable, unstable
>>>> and sandbox codebases?
>>>>
>>>
>>> I don't think we have agreed on what is stable and what is  
>>> unstable.  We were having a discussion on the fact that it is now  
>>> impossible to offer a stable upgrade/patch path for  
>>> applications.  That thread was killed with "PLEASE CAN WE PUT IT  
>>> ON HOLD UNTIL AFTER CERTIFICATION."
>>>
>>> Now Jeremy has proposed that we ignore that discussion and begin  
>>> cementing what we currently have as stable.  How is that at all  
>>> fair?
>>>
>>>
>
> I don't know about fair, but I am finding this discussion nearly as  
> distracting as the previous one that we put on hold.  I still don't  
> see what exotic svn tricks might buy us over normal svn usage, and  
> don't want to spend a lot of time thinking about it until we pass  
> all the tests.  I still think everyones perspective may change once  
> we are passing all the tests and have fixed the few egregious  
> architectural problems that crept in.
>
> I would like to put this discussion on hold until we pass all the  
> tests

if that happens, w/o a stable area, we have to put all changes except  
certification related changes on hold until we pass.

right?

geir

>
> thanks
> david jencks
>
>
>>
>>
>>
>> -David
>>
>>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Stable/Unstable/Sandbox

David Jencks

On May 31, 2005, at 5:55 PM, Geir Magnusson Jr. wrote:

>
> On May 31, 2005, at 8:10 PM, David Jencks wrote:
>
>> (reordered)
>>
>>> Just going to throw out that I think the only goal we can all agree
>>> on is to not regress on certification once we achieve it.
>>>
>>
>> I certainly hope we agree on this :-) but hope we can find more to
>> agree on.
>>
>> On May 31, 2005, at 4:40 PM, David Blevins wrote:
>>
>>
>>> On Tue, May 31, 2005 at 04:21:21PM -0700, David Blevins wrote:
>>>
>>>> On Tue, May 31, 2005 at 11:50:43AM -0400, Geir Magnusson Jr. wrote:
>>>>
>>>>> Can we agree that we need to somehow construct the stable, unstable
>>>>> and sandbox codebases?
>>>>>
>>>>
>>>> I don't think we have agreed on what is stable and what is
>>>> unstable.  We were having a discussion on the fact that it is now
>>>> impossible to offer a stable upgrade/patch path for applications.  
>>>> That thread was killed with "PLEASE CAN WE PUT IT ON HOLD UNTIL
>>>> AFTER CERTIFICATION."
>>>>
>>>> Now Jeremy has proposed that we ignore that discussion and begin
>>>> cementing what we currently have as stable.  How is that at all
>>>> fair?
>>>>
>>>>
>>
>> I don't know about fair, but I am finding this discussion nearly as
>> distracting as the previous one that we put on hold.  I still don't
>> see what exotic svn tricks might buy us over normal svn usage, and
>> don't want to spend a lot of time thinking about it until we pass all
>> the tests.  I still think everyones perspective may change once we
>> are passing all the tests and have fixed the few egregious
>> architectural problems that crept in.
>>
>> I would like to put this discussion on hold until we pass all the
>> tests
>
> if that happens, w/o a stable area, we have to put all changes except
> certification related changes on hold until we pass.
>
> right?

Not really, I think anything we agree should be in our actual first
certified release can be added.  For instance I'd like to see Jeremy's
configuration and assembly plugins get to a working state and be used
for the build.  There are a couple of other changes I have in mind that
dont affect tests passing but improve the structure or usability.  
There's at least one patch (servlet start order) I want to apply soon.

thanks
david jencks

>
> geir
>
>>
>> thanks
>> david jencks
>>
>>
>>>
>>>
>>>
>>> -David
>>>
>>>
>>
>>
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> [hidden email]
>
>