You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/08/13 11:38:45 UTC
[RT] Starting 2.2
Hi, as 2.1 is now out, we should think about starting 2.2.
Here is my idea about how to start 2.2 (I wrote this already some
days ago):
We create a new repository cocoon-2.2 and copy (while preserving
history) only the real required parts from the 2.1 repo:
this should be the core src and the build system. Everything else
can be fetched from the 2.1 repo during the build.
In addition I think we should make a "components block" in the 2.1 repo
where we move all components of the core, like all actions, generators etc.
If we do this we really separate the core from everything else and
we don't need to copy the components into 2.2 as well.
This reduces duplicate code to the minimum which should imho make
bootstrapping
2.2 much easier.
What do you think?
Carsten
Re: [RT] Starting 2.2
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
> ...
>
>> Hmm, yes, but we could start the 2.2 repo with the current core
>> source, so we have a starting point. I expect that blocks will
>> require longer discussions and I personally don't want to wait with
>> 2.2 for this.
>
> I'm wondering. What are you personally planning which requires 2.2
> repo and can not be done in the current repo?
>
> /me feels that you are trying to solve some problem without stating
> what the problem is
/me feels the same ;-)
/me thinks we should continue with the 2.1 repo until either someone
comes with a change that obviously doesn't fit with 2.1.1 or until we
have precise plans for what should go in the 2.2 repo.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>Carsten Ziegeler wrote:
>>...
>>
>>
>>
>>>Hmm, yes, but we could start the 2.2 repo with the current core source,
>>>so we have a starting point. I expect that blocks will require longer
>>>discussions and I personally don't want to wait with 2.2 for this.
>>>
>>>
>>>
>>I'm wondering. What are you personally planning which requires 2.2 repo
>>and can not be done in the current repo?
>>
>>/me feels that you are trying to solve some problem without stating what
>>the problem is
>>
>>
>>
>Secret plans something like "world domination" ... :) (just kidding)
>
>I have several smaller RTs that require major changes in the core, so I
>think they are targetted for a 2.2 release rather than 2.1.1. And the
>blocks require a major version change, so I thought about merging them.
>
>I will write the RTs as soon as we have the repository.
>
Let's do the other way around -- send in RT first and let's hear about
those major changes :)
Vadim
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
> ...
>
> >Hmm, yes, but we could start the 2.2 repo with the current core source,
> >so we have a starting point. I expect that blocks will require longer
> >discussions and I personally don't want to wait with 2.2 for this.
> >
>
> I'm wondering. What are you personally planning which requires 2.2 repo
> and can not be done in the current repo?
>
> /me feels that you are trying to solve some problem without stating what
> the problem is
>
Secret plans something like "world domination" ... :) (just kidding)
I have several smaller RTs that require major changes in the core, so I
think they are targetted for a 2.2 release rather than 2.1.1. And the
blocks require a major version change, so I thought about merging them.
I will write the RTs as soon as we have the repository.
Carsten
Re: [RT] Starting 2.2
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
...
>Hmm, yes, but we could start the 2.2 repo with the current core source,
>so we have a starting point. I expect that blocks will require longer
>discussions and I personally don't want to wait with 2.2 for this.
>
I'm wondering. What are you personally planning which requires 2.2 repo
and can not be done in the current repo?
/me feels that you are trying to solve some problem without stating what
the problem is
Vadim
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Ah, so we'll have a 2.2 repo containing only those parts whose structure
> will change, and keep the 2.1 repo as a "fallback" for those parts whose
> structure is the same (but who may have been upgraded since 2.1.0) ?
>
> But how do we decide that some modifications should occur in 2.2 and not
> in 2.1 ?
>
Yupp.
> >As I expect that we will end in a different structure when we
> have real blocks (e.g. perhaps a blocks repository etc.) this
> would be imho an easier migration strategy.
> >
>
> That's right. With real blocks, we'll have several distinct CVS
> repositories. But will we have distinct "kernel" and "core component"
> blocks ? Should the kernel be really naked (in which case it may even
> contain only the block manager and the main interfaces but nothing
> else), or should it provide the common services used by every
> application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ?
>
I'm not sure if we will have this distinction, so I thought perhaps moving
them (generators etc) out and later move them into the core again is less
pain then having to maintain two branches. Perhaps the latter one is easier,
I honestly don't know.
> >Does this make sense?
> >
>
> Yep. But the granularity has to be found. Maybe we should wait for
> Stefano's RT so that everybody has a common understanding of the
> consequences of blocks on the Cocoon organisation.
>
Hmm, yes, but we could start the 2.2 repo with the current core source,
so we have a starting point. I expect that blocks will require longer
discussions and I personally don't want to wait with 2.2 for this.
Carsten
Re: [RT] Starting 2.2
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>I don't clearly understand what you want to achieve...
>>
>>
>It's plain simple :) Now, the usual way would be to create a new repository (cocoon-2.2) and copy everything from 2.1 in there.
>Then we have two "branches" which require syncing which can be a real pita. My approach is to sync as less as possible by only copying those parts that we will change in the near future. And this should be the core sources, but not the documentation or any block.
>
Ah, so we'll have a 2.2 repo containing only those parts whose structure
will change, and keep the 2.1 repo as a "fallback" for those parts whose
structure is the same (but who may have been upgraded since 2.1.0) ?
But how do we decide that some modifications should occur in 2.2 and not
in 2.1 ?
>As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy.
>
That's right. With real blocks, we'll have several distinct CVS
repositories. But will we have distinct "kernel" and "core component"
blocks ? Should the kernel be really naked (in which case it may even
contain only the block manager and the main interfaces but nothing
else), or should it provide the common services used by every
application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ?
>Does this make sense?
>
Yep. But the granularity has to be found. Maybe we should wait for
Stefano's RT so that everybody has a common understanding of the
consequences of blocks on the Cocoon organisation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Tony Collen wrote:
> Joerg Heinicke wrote:
>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
>>
>> Stefano:
>> "the road to real blocks: how to build it minimizing the impact on
>> the existing code and with complete back compatibility (yes, it's
>> possible!)"
>
>
> Here's my own Mini-RT:
<snip/>
> Now, imagine this applied to Cocoon and blocks. If we distributed a
> "core" Cocoon, we could dramatically cut down the typical amount of
> code that gets distributed. If we wanted the PDF block installed, all
> we would do is go to $cocoon_src/blocks/pdf/ and type build install.
> It would download the PDFSerializer, and realize that the FOP jars are
> required, and download them. We could also come up with some "block
> packages" that are geared towards some basic tasks, i.e. blocks which
> are grouped together to accomplish some goal.. sort of how the more
> popular Linux distros have a "workstation", "server", "basic",
> "everything" install.
>
> That's my RT, I hope I didn't spoil anything anybody was saving :)
You did ;-)
The idea behind blocks uses similar concepts but goes even further by
relying on a discovery system that can ask a server for the location of
dependencies. This means you won't even need a local list of the
available blocks.
But let's not steal Stefano's pleasure of explaining us the results of
his worldwide discussions !
Stefano, seems like a lot of people are ready and waiting ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 13, 2003, at 22:04 Europe/Rome, Tony Collen wrote:
> Joerg Heinicke wrote:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
>> Stefano:
>> "the road to real blocks: how to build it minimizing the impact on
>> the existing code and with complete back compatibility (yes, it's
>> possible!)"
>
> Here's my own Mini-RT:
>
> If you've used a BSD, you've quite possibly run into what's known as
> _ports_. Ports is really cool, and for anyone who doesn't know what
> it is, here's a little description.
Yes. BSD ports or Debian APT has been influencing the design of blocks
since day one.
> Ports is a big directory skeleton which usually sits in /usr/ports.
> It is organized in a hierarchy, so you end up with a directory
> structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc.
I strongly dislike the taxonomy approach. Because finding agreement on
where to place a block will be hard in several cases. But this is an
issue that will be addressed by the block librarian.
> Under each category is another directory for each program which
> belongs to it, so /usr/ports/games/fortune, etc. Now the cool thing
> is that each program directory contains a makefile, unified diffs, and
> a list of repositories where the software resides. (FTP, WWW, etc)
I have presented a much more abstract way of achiving the same
functionality using pluggable locators and non-locating identifiers.
> When you run make, it automatically downloads the software from the
> repository, and patches the software specifically for BSD. Even
> cooler, is that it automatically takes care of dependencies
> recursively. Once all the dependencies are done, the software is
> built. There are several other commands, such as "make install" or
> "make clean" which does the usual expected chores.
We (luckily!) don't need all this. java can be shipped precompiled and
blocks will be configured by the block deployer.
> The only downfall is that you have to keep the directory skeleton up
> to date. FreeBSD does this over CVS. Very handy.
Handy, but painful because it mixes concerns between cataloging and
location. We should avoid this.
> Now, imagine this applied to Cocoon and blocks. If we distributed a
> "core" Cocoon, we could dramatically cut down the typical amount of
> code that gets distributed.
absolutely, this is one of the goals.
> If we wanted the PDF block installed, all we would do is go to
> $cocoon_src/blocks/pdf/ and type build install.
that would be an improvement on what we have today, but it's poor
compared to what I want to achieve with blocks (see my latest RT on
this)
> It would download the PDFSerializer, and realize that the FOP jars
> are required, and download them. We could also come up with some
> "block packages" that are geared towards some basic tasks, i.e. blocks
> which are grouped together to accomplish some goal.. sort of how the
> more popular Linux distros have a "workstation", "server", "basic",
> "everything" install.
Yes, "block bundles" will be available and will be the preferred way of
downloading complex software (say forrest, linotype or lenya) on top of
cocoon.
> That's my RT, I hope I didn't spoil anything anybody was saving :)
Not at all. Thanks much for the info, but everything you want will be
there and much more ;-)
--
Stefano.
Re: [RT] Starting 2.2
Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
>
> Stefano:
> "the road to real blocks: how to build it minimizing the impact on
> the existing code and with complete back compatibility (yes, it's
> possible!)"
Here's my own Mini-RT:
If you've used a BSD, you've quite possibly run into what's known as _ports_. Ports is really cool,
and for anyone who doesn't know what it is, here's a little description.
Ports is a big directory skeleton which usually sits in /usr/ports. It is organized in a hierarchy,
so you end up with a directory structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc,
etc. Under each category is another directory for each program which belongs to it, so
/usr/ports/games/fortune, etc. Now the cool thing is that each program directory contains a
makefile, unified diffs, and a list of repositories where the software resides. (FTP, WWW, etc)
When you run make, it automatically downloads the software from the repository, and patches the
software specifically for BSD. Even cooler, is that it automatically takes care of dependencies
recursively. Once all the dependencies are done, the software is built. There are several other
commands, such as "make install" or "make clean" which does the usual expected chores.
The only downfall is that you have to keep the directory skeleton up to date. FreeBSD does this
over CVS. Very handy.
Now, imagine this applied to Cocoon and blocks. If we distributed a "core" Cocoon, we could
dramatically cut down the typical amount of code that gets distributed. If we wanted the PDF block
installed, all we would do is go to $cocoon_src/blocks/pdf/ and type build install. It would
download the PDFSerializer, and realize that the FOP jars are required, and download them. We
could also come up with some "block packages" that are geared towards some basic tasks, i.e. blocks
which are grouped together to accomplish some goal.. sort of how the more popular Linux distros have
a "workstation", "server", "basic", "everything" install.
That's my RT, I hope I didn't spoil anything anybody was saving :)
Tony
Re: [RT] Starting 2.2
Posted by Joerg Heinicke <jo...@gmx.de>.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
Stefano:
"the road to real blocks: how to build it minimizing the impact on
the existing code and with complete back compatibility (yes, it's
possible!)"
So let's wait for his RTs.
Joerg
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>Carsten Ziegeler wrote:
>>
>>
>>>Ok, let's do simple steps perhaps:
>>>
>>>Do you think that we should start a new repository? This is
>>>equivalent to saying "we start a new major version (2.2)".
>>>
>>>(if the answer is yes, we can talk about the layout).
>>>
>>>
>>
>>You ask for the solution to a problem that's not defined... Why do you
>>need the 2.2 repo to be created before writing your RTs ?
>>
>
>
> Ok, it has nothing to do with my RT's, I had the impression that blocks
> required a major version changes and that we want to start with it asap.
> If I'm wrong here, let's stop this RT.
>
> Carsten
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Ok, let's do simple steps perhaps:
> >
> >Do you think that we should start a new repository? This is
> >equivalent to saying "we start a new major version (2.2)".
> >
> >(if the answer is yes, we can talk about the layout).
> >
> >
>
> You ask for the solution to a problem that's not defined... Why do you
> need the 2.2 repo to be created before writing your RTs ?
>
Ok, it has nothing to do with my RT's, I had the impression that blocks
required a major version changes and that we want to start with it asap.
If I'm wrong here, let's stop this RT.
Carsten
Re: [RT] Starting 2.2
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Ok, let's do simple steps perhaps:
>
>Do you think that we should start a new repository? This is
>equivalent to saying "we start a new major version (2.2)".
>
>(if the answer is yes, we can talk about the layout).
>
>
You ask for the solution to a problem that's not defined... Why do you
need the 2.2 repo to be created before writing your RTs ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Posted by Gianugo Rabellino <gi...@apache.org>.
Jay Freeman (saurik) wrote:
>
> Has any thought been put into "the next time we have to create another new
> repository should be the day we look into better version control"?
Amen! Personally I'd +1 the subversion switch in any moment.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Sep 18, 2003, at 05:12 Europe/Rome, Geoff Howard wrote:
> Stefano Mazzocchi wrote:
>> All right, what the hell, you are right, let's move out of the
>> "impasse".
>
> I thought we'd come to some agreement that no option was without
> problems but that splitting to a separate cocoon-2.2 module was
> probably the least bad option.
Yes, this seems to be the consensus.
>> let's do a quick poll: who would be absolutely against using
>> Subversion for the Cocoon 2.2 tree (granted that we can safely import
>> the existing CVS tree into it)?
>> state your reasons and try to be as less inertial and defensive on
>> your status quo as possible.
>
> Did Niclas' comment about the unreleased status kill this?
Yes, it did. We will consider moving to Subversion only when they
release a public final version that will not move under our feet. It's
a defensive attitude, admittedly, but we don't want any more problems.
--
Stefano.
Re: [RT] Starting 2.2
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
>
> All right, what the hell, you are right, let's move out of the "impasse".
I thought we'd come to some agreement that no option was without
problems but that splitting to a separate cocoon-2.2 module was probably
the least bad option.
> let's do a quick poll: who would be absolutely against using Subversion
> for the Cocoon 2.2 tree (granted that we can safely import the existing
> CVS tree into it)?
>
> state your reasons and try to be as less inertial and defensive on your
> status quo as possible.
Did Niclas' comment about the unreleased status kill this?
Geoff
Re: [RT] Starting 2.2
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 13 September 2003 18:40, Stefano Mazzocchi wrote:
> let's do a quick poll: who would be absolutely against using Subversion
> for the Cocoon 2.2 tree (granted that we can safely import the existing
> CVS tree into it)?
>
> state your reasons and try to be as less inertial and defensive on your
> status quo as possible.
Subversion is not final. They say themselves that it is reliable, but not
stable, i.e. there will be additional data migration issues prior to ver 1.0.
Niclas
Re: [RT] Starting 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Aug 29, 2003, at 20:27 Europe/Rome, Jay Freeman ((saurik))
wrote:
> Stefano:
>
> I totally agree on the "evolution" thing. To start, the process of
> moving to
> Subversion would be a repository import, not starting from scratch.
>
> As for tools:
>
> http://subclipse.tigris.org/
> (Subversion plugin for Eclipse, although only on Win32 currently,
> haven't
> tried it as I hate Eclipse; it seems like it could be gotten to work
> on Unix
> easily, just would require compiling the JNI stubs on your platform
> yourself
> and dropping them in as the subclipse people are currently relying on
> some
> precompiled binaries)
>
> http://ankhsvn.tigris.org/
> (Subversion plugin for VS.NET, a little slow at times, but usable)
>
> They already have it integrated into ViewCVS (which is what I thought
> Apache
> used, might be wrong; there was a lot of impetus to do it as the guy
> who
> originally forked ViewCVS from CVSWeb is one of the lead Subversion
> developers). I've been working with the Chora (another web interface)
> people
> and we have it working in that as well.
>
> What I think would be more productive, both for Cocoon and for
> Subversion,
> is to have more than a flat out "no, stick with something that works"
> but
> instead to put forward a list of requirements from a revision control
> system
> for it to be considered an "evolutionary move". Then people who work on
> version control know where to apply effort and people working on
> Cocoon have
> a roadmap for their evolution (rather than just getting stuck with
> existing
> systems and never moving).
>
> It's somewhat like deciding to switch to a different underlying
> framework
> for component/block management; one wouldn't want to just say "hey,
> this is
> newer and has one better feature, let's do it", but if that one
> feature is
> crucial enough you'd want to have a list of requirements of a new
> system
> (one that obviously includes everything important from the old system)
> so
> that you'd know when you _would_ be able to move to it and when it
> would be
> worth it.
All right, what the hell, you are right, let's move out of the
"impasse".
let's do a quick poll: who would be absolutely against using Subversion
for the Cocoon 2.2 tree (granted that we can safely import the existing
CVS tree into it)?
state your reasons and try to be as less inertial and defensive on your
status quo as possible.
[as win2k->macosx/mozilla->Mail.app switcher I can attest that
sometimes changing your habits is dramatic and painful, but can help
you a lot down the road and you never look back. This sounds another
one of those situations]
--
Stefano.
Re: [RT] Starting 2.2
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Stefano:
I totally agree on the "evolution" thing. To start, the process of moving to
Subversion would be a repository import, not starting from scratch.
As for tools:
http://subclipse.tigris.org/
(Subversion plugin for Eclipse, although only on Win32 currently, haven't
tried it as I hate Eclipse; it seems like it could be gotten to work on Unix
easily, just would require compiling the JNI stubs on your platform yourself
and dropping them in as the subclipse people are currently relying on some
precompiled binaries)
http://ankhsvn.tigris.org/
(Subversion plugin for VS.NET, a little slow at times, but usable)
They already have it integrated into ViewCVS (which is what I thought Apache
used, might be wrong; there was a lot of impetus to do it as the guy who
originally forked ViewCVS from CVSWeb is one of the lead Subversion
developers). I've been working with the Chora (another web interface) people
and we have it working in that as well.
What I think would be more productive, both for Cocoon and for Subversion,
is to have more than a flat out "no, stick with something that works" but
instead to put forward a list of requirements from a revision control system
for it to be considered an "evolutionary move". Then people who work on
version control know where to apply effort and people working on Cocoon have
a roadmap for their evolution (rather than just getting stuck with existing
systems and never moving).
It's somewhat like deciding to switch to a different underlying framework
for component/block management; one wouldn't want to just say "hey, this is
newer and has one better feature, let's do it", but if that one feature is
crucial enough you'd want to have a list of requirements of a new system
(one that obviously includes everything important from the old system) so
that you'd know when you _would_ be able to move to it and when it would be
worth it.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <de...@cocoon.apache.org>
Sent: Friday, August 29, 2003 5:36 AM
Subject: Re: [RT] Starting 2.2
...
> Yes, you are right, CVS sucks, but the way it's integrated with the
> apache infrastructure and with tools that people use is not.
>
> there is a huge inertia there. greatly underestimated by the subversion
> people, expecially for people used to IDEs like eclipse that hide CVS
> stuff under the hood and do things automatically.
>
> I'm sick of this thread. It's stopping evolution.
>
> Carsten, forget beauty of versioning and let's start working on
> cocoon-2.1 HEAD, this will:
>
> 1) reduce effort and duplication
> 2) keep people sane since every commit will have to keep the tree in
> shape (it's entirely possible to implement real blocks with what we
> have, without moving things around, even turning the current static
> blocks into real ones).
>
> So, my vote is: cut the crap, let's work on the thing right here and
> right now, we'll think about what to do later.
>
> Evolution is always prefered to revolution.
>
> [believe me, I've made this mistake so many times that I learned my way
> thru]
>
> --
> Stefano.
Re: [RT] Starting 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 29/08/2003 16.11:
> Berin Loritsch wrote:
>
>>><joke>
>>>Ah, btw. I will replace ECM with fortress over the weekend. Any problems
>>>with that?
>>></joke>
>>>
>>
>>Don't tease me... Want I should do it?
>
> Hey, great!
>
> I'm definitly +5 for this! So if you want to do it, you could start a vote
> and see what will happen next...
Pleeeease! :-)
It will be fun to do some statistics to see if it's a faster plugin
replacement, I'm really really curious!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Starting 2.2
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 29 Aug 2003, Carsten Ziegeler wrote:
>
> Berin Loritsch wrote:
> > >
> > > <joke>
> > > Ah, btw. I will replace ECM with fortress over the weekend. Any problems
> > > with that?
> > > </joke>
> > >
> >
> >
> > Don't tease me... Want I should do it?
> >
> Hey, great!
>
> I'm definitly +5 for this! So if you want to do it, you could start a vote
> and see what will happen next...
Go ahead +1
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> >
> > <joke>
> > Ah, btw. I will replace ECM with fortress over the weekend. Any problems
> > with that?
> > </joke>
> >
>
>
> Don't tease me... Want I should do it?
>
Hey, great!
I'm definitly +5 for this! So if you want to do it, you could start a vote
and see what will happen next...
Carsten
Re: [RT] Starting 2.2
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> <joke>
> Ah, btw. I will replace ECM with fortress over the weekend. Any problems
> with that?
> </joke>
>
Don't tease me... Want I should do it?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Starting 2.2
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
><joke>
>Ah, btw. I will replace ECM with fortress over the weekend. Any problems
>with that?
>
>
Yep. Aren't we supposed to use Merlin instead? I'm checking in the code
as we speak...
></joke>
>
>
Vadim
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> Carsten, forget beauty of versioning and let's start working on
> cocoon-2.1 HEAD, this will:
>
> 1) reduce effort and duplication
> 2) keep people sane since every commit will have to keep the tree in
> shape (it's entirely possible to implement real blocks with what we
> have, without moving things around, even turning the current static
> blocks into real ones).
>
This is a very optimistic assumption, which I personally doubt. But,
ok, I can live with doing everything in cocoon-2.1 HEAD, no problem.
I'm absolutely frustrated as well: over the last months people always
said, "Let's get 2.1 out, we want to start 2.2". Now that we can do it,
I'm the only one keeping to it. Great!
Now I can already imagine what will happen. Someday someone checks in
something that is not suitable for a 2.1.x version and then a new
"flame war" against this person will begin.
Ok, agreed. Let's stop the crap and work with the 2.1 repo then.
<joke>
Ah, btw. I will replace ECM with fortress over the weekend. Any problems
with that?
</joke>
Carsten
Re: [RT] Starting 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Aug 28, 2003, at 20:00 Europe/Rome, Jay Freeman ((saurik))
wrote:
> So my eye finally caught on the "Starting 2.2" thread today, it seemed
> interesting, and I went to read through this... and I must say the main
> reaction I ended up having to it is "HUH?!?". :)
>
> Is the reason you need a new repository because CVS doesn't support
> move/copy/rename (especially so on directories?). I guess I've just
> been
> using Subversion so long that some of the solutions people have been
> proposing sound rather terrifying... making a new repository and
> copying all
> of the RCS files into it in order to "preserve history"? But then you'd
> still be maintaining the files in both versions seperately with no
> computer
> way to know "this file is a copy of that one" to try to help you do
> that.
> Then there was the suggestion to have the new repository copy stuff
> from the
> 2.1 repository during build or something...
>
> With Subversion you could just copy the current trunk off to a
> cocoon-2.1
> branch (as you'd likely be doing many less fixes on that over the
> future
> than enhancements to 2.2, so that would be considered the branch) and
> then
> start reorganizing the directories in the trunk by just moving them
> around
> and committing the move operations (so far with no space duplication
> on the
> server as all of these copy/move operations are just references to the
> same
> file data in the repository), files that need to be renamed could
> easily be
> done so, and this entire process would be keeping track of the history
> through all of the move operations... (although merging the 2.1 branch
> changes into 2.2 still wouldn't be entirely automated, but I'm pretty
> sure
> the Subversion people are working on this; 0.28.0, released a few days
> ago,
> has some features that is bringing it a lot closer).
>
> Has any thought been put into "the next time we have to create another
> new
> repository should be the day we look into better version control"?
Yes, you are right, CVS sucks, but the way it's integrated with the
apache infrastructure and with tools that people use is not.
there is a huge inertia there. greatly underestimated by the subversion
people, expecially for people used to IDEs like eclipse that hide CVS
stuff under the hood and do things automatically.
I'm sick of this thread. It's stopping evolution.
Carsten, forget beauty of versioning and let's start working on
cocoon-2.1 HEAD, this will:
1) reduce effort and duplication
2) keep people sane since every commit will have to keep the tree in
shape (it's entirely possible to implement real blocks with what we
have, without moving things around, even turning the current static
blocks into real ones).
So, my vote is: cut the crap, let's work on the thing right here and
right now, we'll think about what to do later.
Evolution is always prefered to revolution.
[believe me, I've made this mistake so many times that I learned my way
thru]
--
Stefano.
Re: [RT] Starting 2.2
Posted by Gianugo Rabellino <gi...@apache.org>.
Berin Loritsch wrote:
>>
>> What's "good"? The Subversion project has a converter, last time
>> I checked they said it still can't convert branches, and that this
>> was *the* killer for declaring SVN to be "production ready". Trunk
>> only CVS repositories seem to work for a long time already
>> (disclaimer: gathered from various messages, I didn't try personally).
>
>
> Hmm. Do we still have a test server available?
>
> The last time I played with SVN, the Windows client was a bit buggy.
> However that was roughly a year ago. I'm sure it has gotten better
> since then.
>
Look at:
http://cvs.apache.org/repos/asf/
On infrastructure@ there was an email describing how to add yourself to
the right passwd file (with htpasswd). I don't know how sensible that
information is, so I'd rather not write it here. Just contact me if you
feel lik playing around. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
subversion test (Was: [RT] Starting 2.2)
Posted by David Crossley <cr...@indexgeo.com.au>.
Jay, i wonder about your test with Subversion and importing Cocoon2 cvs.
The cocoon repositories underwent some upheaval a while ago. Your import
troubles may be related to that. I have found the approximate date when
that occurred ... 2003-02-17
Perhaps that will help with your investigation. ... sure hope so.
Have you had any further progress? Can you tell us what the problem
files were ... someone may recall issues.
--David
Jay Freeman (saurik) wrote:
> Yeah, the Win32 client used to have all kinds of / vs. \ issues and they
> tended to break the build a lot. However, nowadays, the windows client (at
> least the command line one, which is what I first thought you meant) works
> quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still.
> However! TortoiseSVN (a Win32 shell extension) works extremely well. When
> I'm not using the command line client that's what I now use (and what I set
> up the few other developers at Gnostic Labs with when I finally switched us
> over to Subversion a week or two ago).
>
> As for the CVS to Subversion repository importer, it seems to at least
> partially support branches. BUT, it doesn't seem to support the Cocoon2
> repository somehow. *Got it out of rsync earlier and let it sit for an hour
> or something converting.* I'm working on looking at the input, generated
> dump file, and partial output to try to figure out what's going wrong (it
> has something to do with a branch where some files got added to the branch
> later and then got deleted and it doesn't know they weren't int the branch
> to begin with for whatever reason).
>
> Sincerely,
> Jay Freeman (saurik)
> saurik@saurik.com
>
> Berin Loritsch wrote:
> > J.Pietschmann wrote:
> > > Timothy Larson wrote:
> > >
> > >> I also wondered about Subversion when the repositories started
> > >> multiplying :)
> > >> Is this a possibility? Is there a good CVS->Subversion repository
> > >> converter?
> > >
> > > What's "good"? The Subversion project has a converter, last time
> > > I checked they said it still can't convert branches, and that this
> > > was *the* killer for declaring SVN to be "production ready". Trunk
> > > only CVS repositories seem to work for a long time already
> > > (disclaimer: gathered from various messages, I didn't try personally).
> >
> > Hmm. Do we still have a test server available?
> >
> > The last time I played with SVN, the Windows client was a bit buggy.
> > However that was roughly a year ago. I'm sure it has gotten better
> > since then.
Re: [RT] Starting 2.2
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Yeah, the Win32 client used to have all kinds of / vs. \ issues and they
tended to break the build a lot. However, nowadays, the windows client (at
least the command line one, which is what I first thought you meant) works
quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still.
However! TortoiseSVN (a Win32 shell extension) works extremely well. When
I'm not using the command line client that's what I now use (and what I set
up the few other developers at Gnostic Labs with when I finally switched us
over to Subversion a week or two ago).
As for the CVS to Subversion repository importer, it seems to at least
partially support branches. BUT, it doesn't seem to support the Cocoon2
repository somehow. *Got it out of rsync earlier and let it sit for an hour
or something converting.* I'm working on looking at the input, generated
dump file, and partial output to try to figure out what's going wrong (it
has something to do with a branch where some files got added to the branch
later and then got deleted and it doesn't know they weren't int the branch
to begin with for whatever reason).
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: <de...@cocoon.apache.org>
Sent: Thursday, August 28, 2003 3:30 PM
Subject: Re: [RT] Starting 2.2
> J.Pietschmann wrote:
>
> > Timothy Larson wrote:
> >
> >> I also wondered about Subversion when the repositories started
> >> multiplying :)
> >> Is this a possibility? Is there a good CVS->Subversion repository
> >> converter?
> >
> >
> > What's "good"? The Subversion project has a converter, last time
> > I checked they said it still can't convert branches, and that this
> > was *the* killer for declaring SVN to be "production ready". Trunk
> > only CVS repositories seem to work for a long time already
> > (disclaimer: gathered from various messages, I didn't try personally).
>
> Hmm. Do we still have a test server available?
>
> The last time I played with SVN, the Windows client was a bit buggy.
> However that was roughly a year ago. I'm sure it has gotten better
> since then.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
Re: [RT] Starting 2.2
Posted by Berin Loritsch <bl...@apache.org>.
J.Pietschmann wrote:
> Timothy Larson wrote:
>
>> I also wondered about Subversion when the repositories started
>> multiplying :)
>> Is this a possibility? Is there a good CVS->Subversion repository
>> converter?
>
>
> What's "good"? The Subversion project has a converter, last time
> I checked they said it still can't convert branches, and that this
> was *the* killer for declaring SVN to be "production ready". Trunk
> only CVS repositories seem to work for a long time already
> (disclaimer: gathered from various messages, I didn't try personally).
Hmm. Do we still have a test server available?
The last time I played with SVN, the Windows client was a bit buggy.
However that was roughly a year ago. I'm sure it has gotten better
since then.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Starting 2.2
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Timothy Larson wrote:
> I also wondered about Subversion when the repositories started multiplying :)
> Is this a possibility? Is there a good CVS->Subversion repository converter?
What's "good"? The Subversion project has a converter, last time
I checked they said it still can't convert branches, and that this
was *the* killer for declaring SVN to be "production ready". Trunk
only CVS repositories seem to work for a long time already
(disclaimer: gathered from various messages, I didn't try personally).
J.Pietschmann
Re: [RT] Starting 2.2
Posted by Timothy Larson <ti...@yahoo.com>.
I also wondered about Subversion when the repositories started multiplying :)
Is this a possibility? Is there a good CVS->Subversion repository converter?
--Tim Larson
--- "Jay Freeman (saurik)" <sa...@saurik.com> wrote:
...
> Has any thought been put into "the next time we have to create another new
> repository should be the day we look into better version control"?
...
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [RT] Starting 2.2
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
So my eye finally caught on the "Starting 2.2" thread today, it seemed
interesting, and I went to read through this... and I must say the main
reaction I ended up having to it is "HUH?!?". :)
Is the reason you need a new repository because CVS doesn't support
move/copy/rename (especially so on directories?). I guess I've just been
using Subversion so long that some of the solutions people have been
proposing sound rather terrifying... making a new repository and copying all
of the RCS files into it in order to "preserve history"? But then you'd
still be maintaining the files in both versions seperately with no computer
way to know "this file is a copy of that one" to try to help you do that.
Then there was the suggestion to have the new repository copy stuff from the
2.1 repository during build or something...
With Subversion you could just copy the current trunk off to a cocoon-2.1
branch (as you'd likely be doing many less fixes on that over the future
than enhancements to 2.2, so that would be considered the branch) and then
start reorganizing the directories in the trunk by just moving them around
and committing the move operations (so far with no space duplication on the
server as all of these copy/move operations are just references to the same
file data in the repository), files that need to be renamed could easily be
done so, and this entire process would be keeping track of the history
through all of the move operations... (although merging the 2.1 branch
changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure
the Subversion people are working on this; 0.28.0, released a few days ago,
has some features that is bringing it a lot closer).
Has any thought been put into "the next time we have to create another new
repository should be the day we look into better version control"?
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <de...@cocoon.apache.org>
Sent: Tuesday, August 26, 2003 2:18 AM
Subject: RE: [RT] Starting 2.2
> Pier Fumagalli wrote:
> >
> > On 13/8/03 16:37, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> >
> > > Ok, let's do simple steps perhaps:
> > >
> > > Do you think that we should start a new repository? This is
> > > equivalent to saying "we start a new major version (2.2)".
> > >
> > > (if the answer is yes, we can talk about the layout).
> >
> > YES! :-) As I have few [RT]s on my own! :-) :-) :-)
> >
> Great! Combined with the recent RTs, does still someone feel that
> starting 2.2 is the right thing? Or a there still objections?
>
> Carsten
RE: [RT] Starting 2.2
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Carsten Ziegeler dijo:
> "Hello.
> Is there anybody in there?
> Just nod if you can hear me.
> Is there anyone home?"
Great :)
Antonio Gallardo
Re: [RT] Starting 2.2 (was going to be "The Project Formerly Known
As Cocoon")
Posted by Geoff Howard <co...@leverageweb.com>.
Tony Collen wrote:
> Geoff Howard wrote:
>
>> What about renaming the next release to an unpronounceable set of
>> symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#".
>
>
> How about: Cocoon <Interrobang>
>
> It would be pronounced, "Cocoon?!"
Actually, my proposal could be pronounced "bang and pound" which might
not be positive...
>>> In all seriousness, I'm all for 2.2, but what sorts of loose ends are
>>> there that could be tied up for 2.1.x? Howabout a push to clear out
>>> some bugs from bugzilla?
>>
>> Me too, but a push for bug fix (and I'd like to see a docs blitz)
>> wouldn't need to hold up creating the repository and working out the
>> best way of working two trees at once would it?
>
> Hrm, actually a docs push would be more like it, since I was prodded by
> a few people to do up some nice InputModule docs, so I am guilty as
> charged :) I just didn't want to see new stuff get started and have
> older issues unresolved. I don't see why we'd need to postpone a new
> repository, really, I'd just hate to see things forgotten about.
Agreed.
> Side note: Is a build of 2.1.x or 2.2 going to be using the new
> forrest-style skins for the docs anytime soon? It's kind of nasty
> seeing the old site design when I build docs from the current CVS.
I asked about this before and got the impression that some people are
getting the forrest look. Near as I can tell, it falls back to the old
xml.apache "metal" look if forrest is not downloaded at ../xml-forrest
or as specified in build.properties? So far I've been too lazy to
confirm. I'd much rather be able to import the stylesheets, etc. which
would be needed but I've been too lazy for that as well.
>> By the way, I thought we were planning on breaking from ECM in 2.2
>> because it would make blocks easier among other great benefits. Is
>> this still a thought? That would certainly make a new repo an
>> attractive thing.
>
> I'm not a hugely knowledgeable on Avalon, so I'm not sure about the
> issues surrounding it. Just when I thought I'd start to learn Avalon
> stuff, the carpet gets pulled out from under me! :)
Hopefully it's not as bad as that. Avalon's not going away, just the
implementation that's changing...
Geoff
Re: [RT] Starting 2.2 (was going to be "The Project Formerly Known
As Cocoon")
Posted by Tony Collen <co...@umn.edu>.
Geoff Howard wrote:
> What about renaming the next release to an unpronounceable set of
> symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#".
How about: Cocoon <Interrobang>
It would be pronounced, "Cocoon?!"
>> In all seriousness, I'm all for 2.2, but what sorts of loose ends are
>> there that could be tied up for 2.1.x? Howabout a push to clear out
>> some bugs from bugzilla?
>
>
> Me too, but a push for bug fix (and I'd like to see a docs blitz)
> wouldn't need to hold up creating the repository and working out the
> best way of working two trees at once would it?
Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some
nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started
and have older issues unresolved. I don't see why we'd need to postpone a new repository, really,
I'd just hate to see things forgotten about.
Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs
anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS.
> By the way, I thought we were planning on breaking from ECM in 2.2
> because it would make blocks easier among other great benefits. Is this
> still a thought? That would certainly make a new repo an attractive thing.
I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just
when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :)
Regards,
Tony
Re: [RT] Starting 2.2 (was going to be "The Project Formerly Known
As Cocoon")
Posted by Geoff Howard <co...@leverageweb.com>.
Tony Collen wrote:
> Nicola Ken Barozzi wrote:
>
>> Maybe start 2.5, just to be in line with Linux? ;-P
>
> Screw that, let's just skip a couple major versions, everyone's doing it
> now, how does "Cocoon 5.0" look? :)
>
> Better yet, let's just change the name alltogether:
>
> Cocoon XP
> Cocoon MX
> Cocoon MX 2004
>
> I just love Macromedia, at least they admit MX doesn't mean anything:
>
> What does "MX" mean?
> The "MX" moniker is not an acronym and doesn't have a literal
> translation.
What about renaming the next release to an unpronounceable set of
symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#".
> In all seriousness, I'm all for 2.2, but what sorts of loose ends are
> there that could be tied up for 2.1.x? Howabout a push to clear out
> some bugs from bugzilla?
Me too, but a push for bug fix (and I'd like to see a docs blitz)
wouldn't need to hold up creating the repository and working out the
best way of working two trees at once would it?
By the way, I thought we were planning on breaking from ECM in 2.2
because it would make blocks easier among other great benefits. Is this
still a thought? That would certainly make a new repo an attractive thing.
Geoff
Re: [RT] Starting 2.2
Posted by Tony Collen <co...@umn.edu>.
Nicola Ken Barozzi wrote:
> Maybe start 2.5, just to be in line with Linux? ;-P
Screw that, let's just skip a couple major versions, everyone's doing it now, how does "Cocoon 5.0"
look? :)
Better yet, let's just change the name alltogether:
Cocoon XP
Cocoon MX
Cocoon MX 2004
I just love Macromedia, at least they admit MX doesn't mean anything:
What does "MX" mean?
The "MX" moniker is not an acronym and doesn't have a literal translation.
They add the MX, and then they realize they have to release a new version so they tack a "2004" on
the end.
In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up
for 2.1.x? Howabout a push to clear out some bugs from bugzilla?
Regards,
Tony
Re: [RT] Starting 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 28/08/2003 9.18:
> "Hello.
> Is there anybody in there?
> Just nod if you can hear me.
> Is there anyone home?"
> Carsten Ziegeler wrote:
...
>>does still someone feel that
>>starting 2.2 is the right thing?
Maybe start 2.5, just to be in line with Linux? ;-P
No objections == do it or ask for a vote.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Starting 2.2
Posted by Gianugo Rabellino <gi...@apache.org>.
Upayavira wrote:
> I think we should consider the 2.2 repository _only_ when we've got a
> concrete proposal for code that _cannot_ be included in the 2.1 repository.
+1. Or at least only when we've got a concrete proposal for a build
system that cleanly separates (current) blocks from the core sources.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 28 aoû 2003, à 11:22 Europe/Zurich, Upayavira a écrit :
> ...Switching repositories last time was a pain. Switching to a 2.2
> repository will also be a pain, and that pain has to be worth it, and
> at present I do not see any proposals being made (that is, people
> proposing to implement proposals) that actually require this 2.2
> repository...
I see your point - OTOH, we *know* things are going to happen, so
switching during this relatively quiet period might be easier.
-Bertrand
Re: [RT] Starting 2.2
Posted by Upayavira <uv...@upaya.co.uk>.
Bertrand Delacretaz wrote:
> Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit :
>
>>> ...Great! Combined with the recent RTs, does still someone feel that
>>> starting 2.2 is the right thing? Or are there still objections?...
>>
>
> I'm +1 on starting 2.2 given what's going on (or planned) with blocks,
> forms, etc.
>
> -Bertrand
>
I think, as has been said before, we need to discuss _what_ it is that
would require a new repository.
So far, we've had a number of RTs, but to my knowledge, no one is
working on implementing any of these yet, and no one is working on code
that cannot be placed into the 2.1 repository without breaking
interfaces (at least ones that aren't still alpha).
I think we should consider the 2.2 repository _only_ when we've got a
concrete proposal for code that _cannot_ be included in the 2.1 repository.
Switching repositories last time was a pain. Switching to a 2.2
repository will also be a pain, and that pain has to be worth it, and at
present I do not see any proposals being made (that is, people proposing
to implement proposals) that actually require this 2.2 repository.
Therefore, at present I think we should stick with 2.1, until concrete
proposals emerge that make it worth the effort.
Regards, Upayavira
Re: [RT] Starting 2.2
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit :
>> ...Great! Combined with the recent RTs, does still someone feel that
>> starting 2.2 is the right thing? Or are there still objections?...
I'm +1 on starting 2.2 given what's going on (or planned) with blocks,
forms, etc.
-Bertrand
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
"Hello.
Is there anybody in there?
Just nod if you can hear me.
Is there anyone home?"
Carsten Ziegeler wrote:
>
> Pier Fumagalli wrote:
> >
> > On 13/8/03 16:37, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> >
> > > Ok, let's do simple steps perhaps:
> > >
> > > Do you think that we should start a new repository? This is
> > > equivalent to saying "we start a new major version (2.2)".
> > >
> > > (if the answer is yes, we can talk about the layout).
> >
> > YES! :-) As I have few [RT]s on my own! :-) :-) :-)
> >
> Great! Combined with the recent RTs, does still someone feel that
> starting 2.2 is the right thing? Or are there still objections?
>
> Carsten
>
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> On 13/8/03 16:37, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>
> > Ok, let's do simple steps perhaps:
> >
> > Do you think that we should start a new repository? This is
> > equivalent to saying "we start a new major version (2.2)".
> >
> > (if the answer is yes, we can talk about the layout).
>
> YES! :-) As I have few [RT]s on my own! :-) :-) :-)
>
Great! Combined with the recent RTs, does still someone feel that
starting 2.2 is the right thing? Or a there still objections?
Carsten
Re: [RT] Starting 2.2
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 13/8/03 16:37, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> Ok, let's do simple steps perhaps:
>
> Do you think that we should start a new repository? This is
> equivalent to saying "we start a new major version (2.2)".
>
> (if the answer is yes, we can talk about the layout).
YES! :-) As I have few [RT]s on my own! :-) :-) :-)
Pier
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, let's do simple steps perhaps:
Do you think that we should start a new repository? This is
equivalent to saying "we start a new major version (2.2)".
(if the answer is yes, we can talk about the layout).
Carsten
RE: [RT] Starting 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> I don't clearly understand what you want to achieve...
>
It's plain simple :) Now, the usual way would be to create
a new repository (cocoon-2.2) and copy everything from 2.1
in there.
Then we have two "branches" which require syncing which can
be a real pita. My approach is to sync as less as possible
by only copying those parts that we will change in the
near future. And this should be the core sources, but not
the documentation or any block.
As I expect that we will end in a different structure when we
have real blocks (e.g. perhaps a blocks repository etc.) this
would be imho an easier migration strategy.
Does this make sense?
Carsten
Re: [RT] Starting 2.2
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi, as 2.1 is now out, we should think about starting 2.2.
>
>Here is my idea about how to start 2.2 (I wrote this already some days ago):
>
>We create a new repository cocoon-2.2 and copy (while preserving history) only the real required parts from the 2.1 repo:
>this should be the core src and the build system. Everything else can be fetched from the 2.1 repo during the build.
>
Uh? What's the purpose for a 2.2 repo if we fetch sources from the 2.1 one ?
>In addition I think we should make a "components block" in the 2.1 repo where we move all components of the core, like all actions, generators etc.
>
What's the purpose of this ? Do you want to separate the "kernel" (the
very required classes) from the "core" (general-purpose components
unrelated to external libraries) ? If so, what will be part of the
kernel : interfaces, the few statically-accessed classes and the
pipeline/sitemap classes ?
>If we do this we really separate the core from everything else and we don't need to copy the components into 2.2 as well.
>This reduces duplicate code to the minimum which should imho make bootstrapping 2.2 much easier.
>
>What do you think?
>
I don't clearly understand what you want to achieve...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com