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/02/27 09:12:26 UTC
What Cocoon is really doing wrong [was: CVS repository changes... (and what's left to do)]
I just want to keep on the tradition of writing mails
that explain what cocoon is doing wrong :(
We really should avoid "action fast" when this has a great impact
on all developers and all users of cocoon, like renaming cvs repositories
etc. Reverting things like these is more than a pita.
So, we really should come back to the usual open source handling
of things: first a proposal, than a vote, than the action.
And not: making a proposal and during the proposal doing the
action only because one committer that "great". All the other
committers had even no chance to say their opinion.
You have to give other committers at least one day time, because
we don't live all on the same site of the world, but I guess for
such important isuess one week (as it is handled e.g. by the
avalon group) is much better.
Sorry Pier that this time it hits you, but I hope you feel better
when you know that you are not the only one doing things in cocoon
this way. Even I do it sometimes...but it really depends on the
impact of the change. If the change can be simply reverted it might
be seen as "ok".
So as a personal consequence, I will stop my work on cocoon until
this is sorted out, because I'm feeling really unsure on how to
handle any committs and how it will go on.
(The good thing about it is that it gives me some time to finish
things in avalon).
Thanks
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
Re: What Cocoon is really doing wrong [was: CVS repository
changes... (and what's left to do)]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 11:15, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> Ok, Stefano, Pier, all others, I guess we can simply
> stop this thread and go on with the proposal discussion.
> I had the perception that it wasn't revertable and that because
> all karma to the old repos was removed that is had already
> been decided.
>
> So, we had some misunderstandings that we have now cleared
> and we can happily discuss everything in the other thread.
>
> I hope this is ok, and we will meet again in
> "[PROPOSAL] New CVS Repository Names"
+1 :-)
Pier
RE: What Cocoon is really doing wrong [was: CVS repository changes... (and what's left to do)]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, Stefano, Pier, all others, I guess we can simply
stop this thread and go on with the proposal discussion.
I had the perception that it wasn't revertable and that because
all karma to the old repos was removed that is had already
been decided.
So, we had some misunderstandings that we have now cleared
and we can happily discuss everything in the other thread.
I hope this is ok, and we will meet again in
"[PROPOSAL] New CVS Repository Names"
Carsten
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Thursday, February 27, 2003 12:10 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: What Cocoon is really doing wrong [was: CVS repository
> changes... (and what's left to do)]
>
>
> Carsten Ziegeler wrote:
> > I just want to keep on the tradition of writing mails
> > that explain what cocoon is doing wrong :(
> >
> > We really should avoid "action fast" when this has a great impact
> > on all developers and all users of cocoon, like renaming cvs
> repositories
> > etc. Reverting things like these is more than a pita.
>
> Reverting things like these are piece of cake, Carstern. In fact, it's
> just a matter or changing back the access grantes to the module. (the
> fact that it's now a symlink rather than a real module shouldn't
> bother you)
>
> > So, we really should come back to the usual open source handling
> > of things: first a proposal, than a vote, than the action.
>
> We are in the middle of a transition. This community voted to be a
> top-level project and the ASF agreed.
>
> I understand that a transition is always painful, but things are done
> for good.
>
> now, I agree with you that Pier should have done a proposal first, but
> knowing him, nothing he did can't be easily reversed. [he's a 'do first
> apologize later' type of guy... and I like that in a CVS-backedup
> environment]
>
> > And not: making a proposal and during the proposal doing the
> > action only because one committer that "great".
>
> I can't parse this sentence, can you restate?
>
> > All the other
> > committers had even no chance to say their opinion.
>
> You are saying your opinion. I am listening to your opinion. Nothing
> that was done can't be reversed.
>
> > You have to give other committers at least one day time, because
> > we don't live all on the same site of the world, but I guess for
> > such important isuess one week (as it is handled e.g. by the
> > avalon group) is much better.
>
> If we take a week for each vote, we'll be starting to act as a JSR
> working group and will take years to do something :)
>
> I like the 'do first, revert if somebody complains' approach for small
> things.
>
> I like the proposal/lazy-consensus/act things for bigger things.
>
> I agree with you that Pier should have followed the second approach this
> time.
>
> > Sorry Pier that this time it hits you, but I hope you feel better
> > when you know that you are not the only one doing things in cocoon
> > this way. Even I do it sometimes...but it really depends on the
> > impact of the change. If the change can be simply reverted it might
> > be seen as "ok".
>
> Carsten, Pier did nothing that can't be reversed in 15 minutes, as he
> clearly stated.
>
> > So as a personal consequence, I will stop my work on cocoon until
> > this is sorted out, because I'm feeling really unsure on how to
> > handle any committs and how it will go on.
>
> What can we do to change this perception of yours?
>
> > (The good thing about it is that it gives me some time to finish
> > things in avalon).
>
> This is good.
>
> --
> Stefano Mazzocchi <st...@apache.org>
> Pluralitas non est ponenda sine necessitate [William of Ockham]
> --------------------------------------------------------------------
>
>
Re: What Cocoon is really doing wrong [was: CVS repository changes...
(and what's left to do)]
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> I just want to keep on the tradition of writing mails
> that explain what cocoon is doing wrong :(
>
> We really should avoid "action fast" when this has a great impact
> on all developers and all users of cocoon, like renaming cvs repositories
> etc. Reverting things like these is more than a pita.
Reverting things like these are piece of cake, Carstern. In fact, it's
just a matter or changing back the access grantes to the module. (the
fact that it's now a symlink rather than a real module shouldn't bother you)
> So, we really should come back to the usual open source handling
> of things: first a proposal, than a vote, than the action.
We are in the middle of a transition. This community voted to be a
top-level project and the ASF agreed.
I understand that a transition is always painful, but things are done
for good.
now, I agree with you that Pier should have done a proposal first, but
knowing him, nothing he did can't be easily reversed. [he's a 'do first
apologize later' type of guy... and I like that in a CVS-backedup
environment]
> And not: making a proposal and during the proposal doing the
> action only because one committer that "great".
I can't parse this sentence, can you restate?
> All the other
> committers had even no chance to say their opinion.
You are saying your opinion. I am listening to your opinion. Nothing
that was done can't be reversed.
> You have to give other committers at least one day time, because
> we don't live all on the same site of the world, but I guess for
> such important isuess one week (as it is handled e.g. by the
> avalon group) is much better.
If we take a week for each vote, we'll be starting to act as a JSR
working group and will take years to do something :)
I like the 'do first, revert if somebody complains' approach for small
things.
I like the proposal/lazy-consensus/act things for bigger things.
I agree with you that Pier should have followed the second approach this
time.
> Sorry Pier that this time it hits you, but I hope you feel better
> when you know that you are not the only one doing things in cocoon
> this way. Even I do it sometimes...but it really depends on the
> impact of the change. If the change can be simply reverted it might
> be seen as "ok".
Carsten, Pier did nothing that can't be reversed in 15 minutes, as he
clearly stated.
> So as a personal consequence, I will stop my work on cocoon until
> this is sorted out, because I'm feeling really unsure on how to
> handle any committs and how it will go on.
What can we do to change this perception of yours?
> (The good thing about it is that it gives me some time to finish
> things in avalon).
This is good.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: What Cocoon is really doing wrong [was: CVS repository
changes... (and what's left to do)]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 10:30 am, "Gianugo Rabellino" <gi...@apache.org> wrote:
>> Now, call me "fascist" if you want, but to avoid people to commit back
>> to the old repository names, I've removed YOU ALL karma to the old
>> repositories...
>
> (which, BTW, makes perfectly sense from a sysadm POV). Not to mention
> that, if this limitation is going away, I don't think that we want an
> out of sync repository with people committing to different repos...
> don't we? Or am I missing something?
Yes, that was _my_ big mistake and I didn't think much about it yesterday...
I should have not given anyone karma to the new repos names and not removed
karmas to the old... So that basically, you could have _seen_ the proposal,
but not _played_ with it...
Sorry for that... As I said, it was a 2 seconds change and it's now in
place.
Pier
Re: What Cocoon is really doing wrong [was: CVS repository changes...
(and what's left to do)]
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
> My vision is pretty simple, you do it, and you keep it backward compatible,
> exactly as I did. All the old repositories, with all the old branches, with
> all the old names, are _still_ there (the only "unrevertable" change is the
> fact that now they're owned by the "cocoon" group, and not by the XML), but
> there's no difference between yesterday and today, from your point of view,
Hmmm... but you just wrote:
> Now, call me "fascist" if you want, but to avoid people to commit back
> to the old repository names, I've removed YOU ALL karma to the old
> repositories...
(which, BTW, makes perfectly sense from a sysadm POV). Not to mention
that, if this limitation is going away, I don't think that we want an
out of sync repository with people committing to different repos...
don't we? Or am I missing something?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]
Pruning up the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 11:39, "Gianugo Rabellino" <gi...@apache.org> wrote:
>> - Create a new repository called "cocoon-2.0" and copy over the cocoon-2_0_5
>> branch of "xml-cocoon2" (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it contains what
>> it should. All files are down at version 1.1 in this repository)
>
> +1. But what happens from there on? No more branching, I assume, just
> tagging as 2.0.x release happens. Right?
Yessir! :-) That would be just fantastic...
>> - Create a new repository called "cocoon-2.1" and copy over head from the
>> main "xml-cocoon2" repository (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it contains what
>> it should. All files are down at version 1.1 in this repository)
>
> Here I'm not sure. ATM I'd rather have the latest cocoon version in a
> repository such as plain "cocoon" (think CVS HEAD). In this Cocoon
> lifecycle it represents 2.1. When we release 2.1, we can move this repo
> to cocoon-2.1 and start using it (with tagging, no branching) for 2.1.x
> releases, while "cocoon" would become the 2.2 repo. Isn't it cleaner
> from a logical POV?
That's a good idea... How about if we keep the module symlinked... So,
"cocoon" is the current copy, which is a symlink to whatever is the current
version "cocoon-2.1" now, "cocoon-2.2" "cocoon-3.0" and so on in the
future...
Pier
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning
up the CVS tree for real)
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
> - Rename the "xml-cocoon" repository to "cocoon-1"
> (you can see the effect of this as now both repositories are accessible
> with the old and new names: they are an alias one of another)
+1
> - Rename the "xml-cocoon2" repository to "cocoon-2-historic"
> (you can see the effect of this as now both repositories are accessible
> with the old and new names: they are an alias one of another)
+1
> - Create a new repository called "cocoon-2.0" and copy over the cocoon-2_0_5
> branch of "xml-cocoon2" (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it contains what
> it should. All files are down at version 1.1 in this repository)
+1. But what happens from there on? No more branching, I assume, just
tagging as 2.0.x release happens. Right?
> - Create a new repository called "cocoon-2.1" and copy over head from the
> main "xml-cocoon2" repository (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it contains what
> it should. All files are down at version 1.1 in this repository)
Here I'm not sure. ATM I'd rather have the latest cocoon version in a
repository such as plain "cocoon" (think CVS HEAD). In this Cocoon
lifecycle it represents 2.1. When we release 2.1, we can move this repo
to cocoon-2.1 and start using it (with tagging, no branching) for 2.1.x
releases, while "cocoon" would become the 2.2 repo. Isn't it cleaner
from a logical POV?
> I would like to make my point by simply showing how checking out or doing an
> update on new copies of the repository is _much_ faster than the old
> ones... We don't have branches and we don't have empty dirs to process in
> those...
Yes. Too bad we have to resort to a hack (mimick branches via
duplicating repositories) instead than relying on the SCM internals.
Ciao,
--
Gianugo "eagerly waiting for subversion" Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]Pruningup the CVS tree for real)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
> > So, what will happen, if we release 2.0.5 resp. 2.1?
> >
> > Will we create a new repo for 2.0.6 resp. 2.2?
>
> I do not understand what "resp" means, but I will try to explain: versions
> work, if I got it right, by MAJOR.MINOR.PATCHLEVEL, right?
>
Oh, sorry by "resp." I meant respectivly.
> So, we have (now) two MAJOR.MINOR versions: 2.0 and 2.1: those two minor
> versions are two "forks" (branches, the cocoon_2_0_3 branch and
> HEAD branch)
> of the major version 2.
>
Yes.
> When you "branch" then you start working on patchlevels, so, for example,
> 2.0.0, 2.0.1, 2.0.2, 2.0.3 and so on are all in the same "branch" in the
> same "2.0" fork, as, what will happen for 2.1, the different patchlevels
> 2.1.0, 2.1.1, 2.1.2 and so on will live in their own little HEAD
> branch (for
> now, until we start 2.2, and then they will be "branched out" again)...
>
> So, if a "branch" coincides with a MAJOR.MINOR version number,
> and we don't
> have any advantages in keeping those two branches in the same repository
> (are there any that I don't know of?) we can simply have another
> repository
> with a clean copy of our MAJOR.MINOR version, so that we won't
> waste so much
> time everytime we check out, diff, committ or stuff...
>
> Now, PATCHLEVELS: those should be a tag... A tag is a unique
> identifier of a
> given release, but it doesn't "branch" out so that you keep basically
> working on the same MINOR.MAJOR codebase, and at some point in time you
> declare it to be MINOR.MAJOR.PATCHLEVEL...
>
> You don't use a branch for a given patchlevel because you're not
> going to do
> further development in both branches: for example, what is the
> cocoon_2_0_3
> branch? Are we going to have 2.0.3.1, 2.0.3.2 and so on? Why is
> it different
> from the cocoon_20_branch?
>
> So, to sum up:
>
> HEAD: initial -> 2.0 -> 2.1 -> 2.2 -> ...
> | | |
> V V V
> 2.0.1 2.1.1 2.2.1
> | | |
> V V V
> 2.0.2 2.1.3 2.2.3
> | |
> V V
> 2.0.2 2.1.3
> |
> V
> 2.0.2
>
> Vertical lines are "branches", the horizontal line is "head",
> each number is
> a "tag", and some of these tags are also "branching"... This is
> what should
> happen in a nice little world...
>
> Splitting branches into repositories, then, doesn't change much from our
> perspective, but will do from the server standpoint, as it is much much
> faster to have small "tag-only" repositories than one big repository with
> branches and years of history... CVS doesn't scale, we need to hack our
> development process around it to make it work...
>
Thanks for your explanation. I just want to repeat it with two simple
statements in order to see that I did this correct:
- One repository for each MAJOR.MINOR combination
- Inside a repository are all patch levels. Each one tagged, but there
wont be any branching
Hmm, ok I can live with that.
> Now, SVN is another story, it _will_ fix those design bugs that CVS
> introduced and that forced not only us, but everyone, to "hack" around CVS
> to get it working decently...
>
Would something change if we would use SVN now or later-on? Which means,
if we would use SVN right now, would we have only one repository? And if
we use SVN in some months time, would we have to change the number of
repositories again?
Carsten
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]
Pruningup the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 10:51, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> Thanks Pier!
You welcome! :-) Pleased that we're starting to come out of this empasse...
> Pier Fumagalli wrote:
>>
>> [...]
>>
>> - Create a new repository called "cocoon-2.0" and copy over the
>> cocoon-2_0_5
>> branch of "xml-cocoon2" (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it
>> contains what
>> it should. All files are down at version 1.1 in this repository)
>>
>> - Create a new repository called "cocoon-2.1" and copy over head from the
>> main "xml-cocoon2" repository (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it
>> contains what
>> it should. All files are down at version 1.1 in this repository)
>>
> So, what will happen, if we release 2.0.5 resp. 2.1?
>
> Will we create a new repo for 2.0.6 resp. 2.2?
I do not understand what "resp" means, but I will try to explain: versions
work, if I got it right, by MAJOR.MINOR.PATCHLEVEL, right?
So, we have (now) two MAJOR.MINOR versions: 2.0 and 2.1: those two minor
versions are two "forks" (branches, the cocoon_2_0_3 branch and HEAD branch)
of the major version 2.
When you "branch" then you start working on patchlevels, so, for example,
2.0.0, 2.0.1, 2.0.2, 2.0.3 and so on are all in the same "branch" in the
same "2.0" fork, as, what will happen for 2.1, the different patchlevels
2.1.0, 2.1.1, 2.1.2 and so on will live in their own little HEAD branch (for
now, until we start 2.2, and then they will be "branched out" again)...
So, if a "branch" coincides with a MAJOR.MINOR version number, and we don't
have any advantages in keeping those two branches in the same repository
(are there any that I don't know of?) we can simply have another repository
with a clean copy of our MAJOR.MINOR version, so that we won't waste so much
time everytime we check out, diff, committ or stuff...
Now, PATCHLEVELS: those should be a tag... A tag is a unique identifier of a
given release, but it doesn't "branch" out so that you keep basically
working on the same MINOR.MAJOR codebase, and at some point in time you
declare it to be MINOR.MAJOR.PATCHLEVEL...
You don't use a branch for a given patchlevel because you're not going to do
further development in both branches: for example, what is the cocoon_2_0_3
branch? Are we going to have 2.0.3.1, 2.0.3.2 and so on? Why is it different
from the cocoon_20_branch?
So, to sum up:
HEAD: initial -> 2.0 -> 2.1 -> 2.2 -> ...
| | |
V V V
2.0.1 2.1.1 2.2.1
| | |
V V V
2.0.2 2.1.3 2.2.3
| |
V V
2.0.2 2.1.3
|
V
2.0.2
Vertical lines are "branches", the horizontal line is "head", each number is
a "tag", and some of these tags are also "branching"... This is what should
happen in a nice little world...
Splitting branches into repositories, then, doesn't change much from our
perspective, but will do from the server standpoint, as it is much much
faster to have small "tag-only" repositories than one big repository with
branches and years of history... CVS doesn't scale, we need to hack our
development process around it to make it work...
Now, SVN is another story, it _will_ fix those design bugs that CVS
introduced and that forced not only us, but everyone, to "hack" around CVS
to get it working decently...
Pier
RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruningup the CVS tree for real)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Thanks Pier!
Pier Fumagalli wrote:
>
>
> - Rename the "xml-cocoon" repository to "cocoon-1"
> (you can see the effect of this as now both repositories are
> accessible
> with the old and new names: they are an alias one of another)
>
Ok.
> - Rename the "xml-cocoon2" repository to "cocoon-2-historic"
> (you can see the effect of this as now both repositories are
> accessible
> with the old and new names: they are an alias one of another)
>
Ok.
> - Create a new repository called "cocoon-2.0" and copy over the
> cocoon-2_0_5
> branch of "xml-cocoon2" (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it
> contains what
> it should. All files are down at version 1.1 in this repository)
>
> - Create a new repository called "cocoon-2.1" and copy over head from the
> main "xml-cocoon2" repository (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it
> contains what
> it should. All files are down at version 1.1 in this repository)
>
So, what will happen, if we release 2.0.5 resp. 2.1?
Will we create a new repo for 2.0.6 resp. 2.2?
Carsten
[PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning
up the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 10:28 am, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> So can we then simply start a proposal on how to name the repositories?
+1! There we go (from yesterday)
- Rename the "xml-cocoon" repository to "cocoon-1"
(you can see the effect of this as now both repositories are accessible
with the old and new names: they are an alias one of another)
- Rename the "xml-cocoon2" repository to "cocoon-2-historic"
(you can see the effect of this as now both repositories are accessible
with the old and new names: they are an alias one of another)
- Create a new repository called "cocoon-2.0" and copy over the cocoon-2_0_5
branch of "xml-cocoon2" (clean checkout, and re-import)
(this has been created as a part of this proposal, and it contains what
it should. All files are down at version 1.1 in this repository)
- Create a new repository called "cocoon-2.1" and copy over head from the
main "xml-cocoon2" repository (clean checkout, and re-import)
(this has been created as a part of this proposal, and it contains what
it should. All files are down at version 1.1 in this repository)
I would like to make my point by simply showing how checking out or doing an
update on new copies of the repository is _much_ faster than the old
ones... We don't have branches and we don't have empty dirs to process in
those...
Pier
RE: What Cocoon is really doing wrong [was: CVS repositorychanges... (and what's left to do)]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
>
> Maybe I should have pointed out that the change is backward
> compatible? Did
> you try doing "cvs co xml-cocoon2"? It still works...
>
> It's not that things can be "reverted", it's that things, for the eyes who
> doesn't want to see the change, does not exist... The repository name,
> LITERALLY is still there, with the old name and the whole
> thing... The only
> thing you see now are also few new "repositories" which are my proposal to
> this list (it's an infrastructure "diff" with a lot of + and no -
> lines) :-)
>
> Sorry if I wasn't clear from the beginning...
>
So, you created new repositores as part of your proposal?
What will happen if I now check-in something only into the old rep?
What will happen if I now check-in something only into the new rep?
I don't see that it helps to create a repository to discuss how it
should be named.
So can we then simply start a proposal on how to name the repositories?
Thanks
Carsten
Re: What Cocoon is really doing wrong [was: CVS repository
changes... (and what's left to do)]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 8:12 am, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> So, we really should come back to the usual open source handling
> of things: first a proposal, than a vote, than the action.
> And not: making a proposal and during the proposal doing the
> action only because one committer that "great". All the other
> committers had even no chance to say their opinion.
Ok, soory, my bad...
Maybe I should have pointed out that the change is backward compatible? Did
you try doing "cvs co xml-cocoon2"? It still works...
Mine _is_ a proposal: if you want to propose something related to code,
usually you stop sitting on your ass and send out a patch to the mailing
list, how can you do the same when what you wanted to propose is the CVS
repository itself?
My vision is pretty simple, you do it, and you keep it backward compatible,
exactly as I did. All the old repositories, with all the old branches, with
all the old names, are _still_ there (the only "unrevertable" change is the
fact that now they're owned by the "cocoon" group, and not by the XML), but
there's no difference between yesterday and today, from your point of view,
if you want to ignore my proposal, just go ahead and do as you always did
using the old xml-cocoon2 name...
> Sorry Pier that this time it hits you, but I hope you feel better
> when you know that you are not the only one doing things in cocoon
> this way. Even I do it sometimes...but it really depends on the
> impact of the change. If the change can be simply reverted it might
> be seen as "ok".
It's not that things can be "reverted", it's that things, for the eyes who
doesn't want to see the change, does not exist... The repository name,
LITERALLY is still there, with the old name and the whole thing... The only
thing you see now are also few new "repositories" which are my proposal to
this list (it's an infrastructure "diff" with a lot of + and no - lines) :-)
Sorry if I wasn't clear from the beginning...
Pier