Keiron Liddle wrote:
Actually projects like mozilla have branches for maintanence but the key
is that they are short lived, this didn't work out like that.
I don't know this, but I'll bet that the maintenance branch that you refer
to here is for bug fixes, while the main development line
Victor Mote wrote:
If it is not feasible to unify significant portions of the two branches,
either by switching them in the repository or by putting them into one
branch, then I propose that we clarify our terminology by using the term
rewrite instead of redesign. This would signal that we
On Saturday 02 November 2002 10:35, Victor Mote wrote:
. . .I would also recommend that, in the above case,
we actually put the code into two different projects.
. . .
+1, I like the idea.
How about moving the new code (HEAD) to a separate (xml-fop2) CVS project
to clarify things, and maybe
Victor,
Keiron has responded to specifics, so I will make a couple of general
points below...
Victor Mote wrote:
...
I realize that I am jumping into this conversation in the middle. I am
ignorant of the history of how we got where we are, so **please** understand
that I am not being
Chuck, Oleg,
You may be interested in the modifications I have checked in to
conf/xml-lang.xml under the FOP_0-20-0_Alt-Design tag. These were
prompted by the changes to the handling of ISO 639 language tags in the
Errata, although these changes had been flagged some time ago.
I had been
Bertrand Delacretaz wrote:
How about moving the new code (HEAD) to a separate (xml-fop2) CVS project
to clarify things, and maybe name the new version fop 2 instead of 1.0x?
Although the current version is 0.20.x, it *is* used in production at a
number of sites, so going directly to version
Victor,
...
Victor Mote wrote:
Victor Mote wrote:
If it is not feasible to unify significant portions of the two branches,
either by switching them in the repository or by putting them into one
branch, then I propose that we clarify our terminology by using the term
rewrite instead of
Peter B. West wrote:
(Aside: I disagree with the only model that seems to work bit. Not
everyone has a short attention span.)
Well, there is probably a reason that I see you frequently checking code
into the repository. Even when I am working with code that is torn apart and
spread out all
Peter B. West wrote:
Victor Mote wrote:
Victor Mote wrote:
If it is not feasible to unify significant portions of the two branches,
either by switching them in the repository or by putting them into one
branch, then I propose that we clarify our terminology by using the term
rewrite
Oleg Tkachenko wrote:
and contributors efforts. Maintenance branch, as you correctly noted, is
in production at many sites therefore making it a project on its own
will lead to a strengthening of its meaning and this way we'll encourage
many existing and future contributors to work on it,
Victor Mote wrote:
Branches imply
eventual merging,
Not necessarily.
I'll be happy to consider this point if someone will name even one benefit
to keeping code that will never be merged in the same tree.
Well, the main idea of branches is just to split development, e.g. for
the sake of
On Friday 01 November 2002 16:51, Keiron Liddle wrote:
. . .Maybe the simplest is to move the old layout to the trunk, get that
working and put the new layout in a branch. But it needs to be agreed
upon.
. . .
It would be great if the layout engine could be factored out as a component
with a
Oooh - an inspired idea.
At 06:24 AM 11/2/02, you wrote:
On Saturday 02 November 2002 10:35, Victor Mote wrote:
. . .I would also recommend that, in the above case,
we actually put the code into two different projects.
. . .
+1, I like the idea.
How about moving the new code (HEAD) to a
Victor Mote wrote:
Oleg Tkachenko wrote:
Victor Mote wrote:
Branches imply
eventual merging,
Not necessarily.
I'll be happy to consider this point if someone will name even
one benefit
to keeping code that will never be merged in the same tree.
Well, the main idea of branches is
Peter B. West wrote:
If you took offence from the short attention span comment, I am sorry.
No such offence was intended. The comment concerns the general
approach to development that you mentioned.
No offence taken I am sure none was intended.
Victor Mote
15 matches
Mail list logo
