lto:vic@;outfitr.com]
> Sent: Saturday, 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 producti
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
>
I can hear a distant pounding already. :-) No seriously, good luck. I
don't think anyone will turn your offer down. And as you say, if
anything goes wrong you get to know FOP a lot better.
On 03.11.2002 20:29:34 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > The problem with this is really, th
Jeremias Maerki wrote:
> The problem with this is really, that the old layout code is scattered
> around in the FO tree (look for layout() methods). The redesign
> introduces the layout managers which is a move to separate the logic
> (layout code) from the data structure (FO tree). The keyword he
The problem with this is really, that the old layout code is scattered
around in the FO tree (look for layout() methods). The redesign
introduces the layout managers which is a move to separate the logic
(layout code) from the data structure (FO tree). The keyword here is SoC
(Separation of Concern
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
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
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
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 still
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
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 thi
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
eli
Victor Mote wrote:
At the time, and for some time afterward, there was
nothing in the queue, and they might very well have gotten out of the habit
of looking -- also I am not sure that there was a way to conveniently see
the contents of the queue.
Newest bugzilla builds have a nice feature of r
Keiron Liddle wrote:
> 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.
My previous suggestion was to have one of the committers volunteer to
monitor the queue
27 matches
Mail list logo
