On Sat, 2002-11-02 at 21:31, Victor Mote wrote:
I agree that maintenance branches are not obliged to be merged eventually,
but you still have not shown any benefit to keeping them in the same tree if
they are not.
Usual development pattern would also be that someone makes sure that new
, November 02, 2002 11:27 AM
To: [EMAIL PROTECTED]
Subject: RE: handling patches (how about fop 2)
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
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
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
Hi Victor,
I'm lost for ideas.
I'm getting the feeling that this project is simply too large for this
situation. Which is why I want the effort to be focused and not wasting
time sorting out things that don't get us anywhere.
On Thu, 2002-10-31 at 20:30, Victor Mote wrote:
I realize that I am
Keiron Liddle wrote:
Hi Victor,
I'm lost for ideas.
I'm getting the feeling that this project is simply too large for this
situation. Which is why I want the effort to be focused and not wasting
time sorting out things that don't get us anywhere.
It's a big task. Tangentially speaking, I
Hi Keiron
Are you referring to the work still being done on the maintenance branch
as a whole? I see that we're facing reality here. You know I'm a strong
supporter of the redesign even if I can't spend a lot of effort on it
ATM. But even I am confronted again with the wishes of my employer to
Jeremias Maerki wrote:
...
ATM. But even I am confronted again with the wishes of my employer to
...
of times that this will be a lost effort. But the fact that we currently
can't bring together enough manpower to make a 1.0 developer release a
reality soon gets in the way again.
I think
Hi All,
Since we now have some patches lining up in bugzilla I was wondering
how/who these should be handled.
Victor how do you suggest that we approach this, what do you see
hapenning.
And of course the other issue, where are these patches eventually
leading to. What I want is that this
21 matches
Mail list logo
