You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@costin.dnt.ro on 2000/01/13 19:46:31 UTC
Re: RESET: Proposal for Revolutionaries and Evolutionaries
> 1) Any committer has the right to go start a revolution. They can
> establish a branch or seperate whiteboard directory in which
+1 on everything, but I would like to add - "in a separate whiteboard
directory or if not possible in a branch"
Motivation - if needed:
We are a Java project, where we can use different packages, interfaces,
dynamic loading - you can make a better revolution if you use a
org.apache.tomcat_RED package for the new code ( and maybe use whatever
you feel is not so corupted in the main set of packages).
That also means that if the revolution will be based around components,
it will be easier to integrate - and effort in general areas will be
shared ( like class loading, sessions, etc).
It also mean you'll not have to be an expert in CVS and spend lot of time
joining branches - but fixes will go into one branch and it will be hard
to integrate. I've done few CVS merges, and it's a big, big pain even for
simple cases.
Costin
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/13/00 11:34 PM, Pierpaolo Fumagalli at pier@apache.org wrote:
> Uh... Gotcha... Yes, merging is in 99% of the cases a manual operation,
> and not a trivial one. But we're talking about revolutions here, and I
> think that in such cases no version management software can help us...
Yes... And, as much as I like revolutions, having to go through this
mandates a level of committement to the revolution. If revolutions are too
easy to accomplish, then what's the point? :)
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
costin@costin.dnt.ro wrote:
>
> > Creating a branch on the CVS "IS" stupid... I'm definitely not worried
> > about that, and when times come to "re-merge" the revolutionary branch
> > into the main one, well, I believe this won't happen so often, and
> > advices and/or help can be provided by the most expert of us.
>
> As I said, it's not creating a branch of CVS that worries me, it's
> merging. And I don't know any way you can merge anything but trivial
> changes - CVS will give you a number of "resolve it manually" for still
> simple cases, and you're on your own for big changes.
Uh... Gotcha... Yes, merging is in 99% of the cases a manual operation,
and not a trivial one. But we're talking about revolutions here, and I
think that in such cases no version management software can help us...
> I don't think CVS was designed for revolutions - but I can't claim I'm an
> expert in CVS. But we should better check with an expert first !
Agreed...
> > I don't like the idea of "same branch different package" because, in
> > this way, when one gets the snapshot of CVS, he gets 2/3 versions of the
> > same stuff within the same "box", and it will be difficult to
> > "straighten" it up.
>
> Not true - you can still have src/main with all the sources in the main
> development tree, and src/main_blue with a set of revolutionary packages
> inside.
>
> If you want stable code - you just compile the main tree.
> If you want to work with experimental code - compile both, and configure
> it to use the new stuff.
Ah, ok, so it's not a different package ("org.apache.tomcat.blue"), but
a different directory in the CVS repository... I'm all in favour of
that, it's like a branch, basically, and re-integration must be done
manually!
> That should work if we provide minimal hooks - and will help both the
> revolution ( since it will be able to use the latest, bug-fixed version of
> main modules ) and the main tree - we'll be able to integrate some
> packages that are usefull, even before the revolution is completed.
We can play so many tricks with different directories... Like, if you
have a package (say it "org.apache.tomcat.sessions") and this co-exist
in both the "main" and the "blue" versions. On the server, if you simply
do a symlink between the two directories or files, you can have commits
both in the "main" as in the "blue" version, and seeing them reflected
automatically into the other version.
> See session management - Craig did a great job, and even if we still don't
> use the same interface we have a simple bridge that allows use of either
> the old or the new session management.
Good...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by co...@costin.dnt.ro.
> Creating a branch on the CVS "IS" stupid... I'm definitely not worried
> about that, and when times come to "re-merge" the revolutionary branch
> into the main one, well, I believe this won't happen so often, and
> advices and/or help can be provided by the most expert of us.
As I said, it's not creating a branch of CVS that worries me, it's
merging. And I don't know any way you can merge anything but trivial
changes - CVS will give you a number of "resolve it manually" for still
simple cases, and you're on your own for big changes.
I don't think CVS was designed for revolutions - but I can't claim I'm an
expert in CVS. But we should better check with an expert first !
> I don't like the idea of "same branch different package" because, in
> this way, when one gets the snapshot of CVS, he gets 2/3 versions of the
> same stuff within the same "box", and it will be difficult to
> "straighten" it up.
Not true - you can still have src/main with all the sources in the main
development tree, and src/main_blue with a set of revolutionary packages
inside.
If you want stable code - you just compile the main tree.
If you want to work with experimental code - compile both, and configure
it to use the new stuff.
That should work if we provide minimal hooks - and will help both the
revolution ( since it will be able to use the latest, bug-fixed version of
main modules ) and the main tree - we'll be able to integrate some
packages that are usefull, even before the revolution is completed.
See session management - Craig did a great job, and even if we still don't
use the same interface we have a simple bridge that allows use of either
the old or the new session management.
Costin
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Jason Hunter wrote:
>
> > It also mean you'll not have to be an expert in CVS
>
> I agree with Costin that the downside of the proposal is that any
> revolutionary must be an expert in CVS. To help with this, we should
> make sure that there exists a detailed document describing how to manage
> multiple branches with CVS. We can call it "A Revolutionist's Guide".
> :-)
Creating a branch on the CVS "IS" stupid... I'm definitely not worried
about that, and when times come to "re-merge" the revolutionary branch
into the main one, well, I believe this won't happen so often, and
advices and/or help can be provided by the most expert of us.
> I'm not sure if I agree with Costin's proposal for same-branch
> different-package development. I'm worried that won't scale well and
> may cause dependency problems if people aren't careful. But I do like
> its simplicity! If I were working alone that's how I'd manage my own
> revolution (and how James recently said he did his with Tomcat).
I don't like the idea of "same branch different package" because, in
this way, when one gets the snapshot of CVS, he gets 2/3 versions of the
same stuff within the same "box", and it will be difficult to
"straighten" it up.
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
James Duncan Davidson wrote:
>
> on 1/14/00 12:42 PM, ja@almery.com at ja@almery.com wrote:
>
> > I understand this. But for the case when this does not happen, when
> > the revolutionary branch becomes the de-facto main branch - for
> > whatever reason - there should be a mechanism to formalize the
> > process, IMHO.
>
> imo the process is already clear. if a revolution becomes the de-facto
> branch, then we realize that, make a vote, and the revolution wins and it
> becomes the main as soon as it's stable.
Agreed...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/14/00 12:42 PM, ja@almery.com at ja@almery.com wrote:
> I understand this. But for the case when this does not happen, when
> the revolutionary branch becomes the de-facto main branch - for
> whatever reason - there should be a mechanism to formalize the
> process, IMHO.
imo the process is already clear. if a revolution becomes the de-facto
branch, then we realize that, make a vote, and the revolution wins and it
becomes the main as soon as it's stable.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
RE: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by ja...@almery.com.
Preston L. Bannister writes:
> I think that the assumption here is that the only work going into the
> revolutionary branch is the related to the one aspect being overhauled.
I don't think that is necessarily conveyed by the term "revolution",
and probably needs to be made explicit, if it is indeed the case.
> Any other new features or fixes would go into the main branch.
>
> Part of the notion is to keep the branch in existance not longer than
> is absolutely necessary.
I understand this. But for the case when this does not happen, when
the revolutionary branch becomes the de-facto main branch - for
whatever reason - there should be a mechanism to formalize the
process, IMHO.
-- Jay Doane | doane@acm.org
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/14/00 12:28 PM, Preston L. Bannister at preston@home.com wrote:
> I think that the assumption here is that the only work going into the
> revolutionary branch is the related to the one aspect being overhauled.
Yes, but that aspect could touch all parts of the code.
> Part of the notion is to keep the branch in existance not longer than
> is absolutely necessary.
Definitly. When the revolution is ready, and accepted, it scores.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
RE: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by "Preston L. Bannister" <pr...@home.com>.
I think that the assumption here is that the only work going into the
revolutionary branch is the related to the one aspect being overhauled.
Any other new features or fixes would go into the main branch.
Part of the notion is to keep the branch in existance not longer than
is absolutely necessary.
> -----Original Message-----
> From: ja@almery.com [mailto:ja@almery.com]
> Sent: Friday, January 14, 2000 11:25 AM
> To: general@jakarta.apache.org
> Subject: Re: RESET: Proposal for Revolutionaries and Evolutionaries
>
>
> jon * writes:
> > on 1/13/00 9:07 PM, Jason Hunter <jh...@acm.org> wrote:
> >
> > > I agree with Costin that the downside of the proposal is that any
> > > revolutionary must be an expert in CVS. To help with this, we should
> > > make sure that there exists a detailed document describing how to manage
> > > multiple branches with CVS. We can call it "A Revolutionist's Guide".
> > > :-)
> >
> > RTFM
> >
> > http://cvsbook.red-bean.com/
>
> Agreed. A good revolutionary leader always has a manual, and usually
> knows how to read it.
>
> On a semi-related note, has there been any consideration for the case
> when the revolutionary branch grabs all the development interest, and
> in fact becomes the de-facto main branch?
>
> --
> Jay Doane | doane@acm.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/14/00 11:25 AM, ja@almery.com at ja@almery.com wrote:
> On a semi-related note, has there been any consideration for the case
> when the revolutionary branch grabs all the development interest, and
> in fact becomes the de-facto main branch?
Then it would seem to be natural to have a discussion about voting it into
the primary branch -- at least when it's ready to release. This would be a
situtation where one revolution wins -- and is quite a possible and
desirable scenario I think.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by ja...@almery.com.
jon * writes:
> on 1/13/00 9:07 PM, Jason Hunter <jh...@acm.org> wrote:
>
> > I agree with Costin that the downside of the proposal is that any
> > revolutionary must be an expert in CVS. To help with this, we should
> > make sure that there exists a detailed document describing how to manage
> > multiple branches with CVS. We can call it "A Revolutionist's Guide".
> > :-)
>
> RTFM
>
> http://cvsbook.red-bean.com/
Agreed. A good revolutionary leader always has a manual, and usually
knows how to read it.
On a semi-related note, has there been any consideration for the case
when the revolutionary branch grabs all the development interest, and
in fact becomes the de-facto main branch?
--
Jay Doane | doane@acm.org
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/13/00 9:07 PM, Jason Hunter at jhunter@acm.org wrote:
> I agree with Costin that the downside of the proposal is that any
> revolutionary must be an expert in CVS. To help with this, we should
> make sure that there exists a detailed document describing how to manage
> multiple branches with CVS. We can call it "A Revolutionist's Guide".
> :-)
Maybe so... I'm split on whether or not I'm bothered that a revolutionary
needs to know the tool well. The hard-ass in me says that if you want a
revolution enough, you've got to know how to do to use the weapons of
choice. :)
But seriously, along with these thoughts does come the need for a little bit
more thinking that can be put into a revolutionists guide of sorts.
> I'm not sure if I agree with Costin's proposal for same-branch
> different-package development. I'm worried that won't scale well and
> may cause dependency problems if people aren't careful. But I do like
> its simplicity! If I were working alone that's how I'd manage my own
> revolution (and how James recently said he did his with Tomcat).
Actually, I think that the choices really are:
1) different-branch, different-package development -- this allows
the trunk to be checked out without any overhead from the
revolution until it's ready. Also there's an advantage in that
if the core software is modular and configurable enough, you can
activate new packages / functinality easily. The downside is
that you can run into an explosion of package names.
2) different-dir, who-cares-what-branch -- still allows the trunk
to be built cleanly as the revolution is in
jakarta-tomcat/revolutions/blue/* -- the problem I see with this
one is difficulty of merging -- you gotta use lots of diffs
or really good diffing tools.
3) same-package, different-branch development -- possibly the
hardest to conceptually manage.
At this point, I really hesitate to advocate any single one of these
approaches. My gut tells me that number 3 is the hardest to understand or
manage long term for most developers. I like the idea of number 1. Number 2
isn't bad either.
So I guess that I'd be in a position to say that approaches 1 and 2 are
possibly valid approaches depending on the scale of the revolution being
imagined. I'd not go much further as each revolution will have a unique set
of technical needs. And, the revolutionaries should be comfortable with the
solution at hand -- after all, I think in the scheme of things that when a
revolutionary is ready to commit (and such approval is given) it's the
responsibility of the revolutionary to see the merge / integration all the
way through.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by jon * <jo...@clearink.com>.
on 1/13/00 9:07 PM, Jason Hunter <jh...@acm.org> wrote:
> I agree with Costin that the downside of the proposal is that any
> revolutionary must be an expert in CVS. To help with this, we should
> make sure that there exists a detailed document describing how to manage
> multiple branches with CVS. We can call it "A Revolutionist's Guide".
> :-)
RTFM
http://cvsbook.red-bean.com/
;-)
-jon
--
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by Jason Hunter <jh...@acm.org>.
costin@costin.dnt.ro wrote:
>
> > 1) Any committer has the right to go start a revolution.
>
> +1 on everything, but I would like to add - "in a separate whiteboard
> directory or if not possible in a branch"
>
> Motivation - if needed:
>
> ...
>
> It also mean you'll not have to be an expert in CVS
I agree with Costin that the downside of the proposal is that any
revolutionary must be an expert in CVS. To help with this, we should
make sure that there exists a detailed document describing how to manage
multiple branches with CVS. We can call it "A Revolutionist's Guide".
:-)
I'm not sure if I agree with Costin's proposal for same-branch
different-package development. I'm worried that won't scale well and
may cause dependency problems if people aren't careful. But I do like
its simplicity! If I were working alone that's how I'd manage my own
revolution (and how James recently said he did his with Tomcat).
-jh-
RE: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by "Preston L. Bannister" <pr...@home.com>.
+1 on James original note, with Costin's useful clarification.
I think James did an excellent job writing up what (I believe)
is the group concensus and summary of the proceeding discussion.
From: costin@costin.dnt.ro [mailto:costin@costin.dnt.ro]
>
> > 1) Any committer has the right to go start a revolution. They can
> > establish a branch or seperate whiteboard directory in which
>
> +1 on everything, but I would like to add - "in a separate whiteboard
> directory or if not possible in a branch"
RE: RESET: Proposal for Revolutionaries and Evolutionaries
Posted by "Preston L. Bannister" <pr...@home.com>.
+1 on James original note, with Costin's useful clarification.
I think James did an excellent job writing up what (I believe)
is the group concensus and summary of the proceeding discussion.
From: costin@costin.dnt.ro [mailto:costin@costin.dnt.ro]
>
> > 1) Any committer has the right to go start a revolution. They can
> > establish a branch or seperate whiteboard directory in which
>
> +1 on everything, but I would like to add - "in a separate whiteboard
> directory or if not possible in a branch"