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
--
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 j
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
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
On Saturday 02 November 2002 13:09, Oleg Tkachenko wrote:
>. . .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
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 bran
A link from page A to page B is only rendered in the pdf renderer correctly if page B
is prepared by the renderer before page A is rendered. In the following case page A is
rendered before page B is prepared (PN (X) is the pagenumber of page X):
(i) PN (A) < PN (B)
(ii) if there is a link from
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 so
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,
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 t
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
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 "redes
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 versio
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 usin
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 critical.
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 may
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 tha
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 prog
18 matches
Mail list logo
