You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2002/10/30 11:08:05 UTC
handling patches
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 process goes smoothly and promptly
with causing further confusion and fragmentation.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 over the place, knowing that I have 1000 changes that I need
to make, I still want to frequently check in incremental improvements to
that code. I use it partly as a safety net, and partly as a way to delineate
logical progression of thought. If there is an abundant supply of
programmers out there who have attention spans that preclude the need for
that, then there would be no need at all for source code control.
> An important point to make about FOP is that a conscious decision was
> made some time ago that the redesign would stick with the existing
> framework and not be a ground-up reworking. The methodological changes
> now being discussed are only possible because of that decision, strongly
> argued by Keiron, I believe.
It is not hard to see that the new code came out of the old. The question
still remains whether the two are now so far apart that they cannot or
should not be merged. Since you write more about this in a later posting,
please see my reply to that posting, which will follow.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by "Peter B. West" <pb...@powerup.com.au>.
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. My first exposure to an open-source project
> was when I started monitoring this list on July, and I have no idea how
> other projects operate. However, I have done some reading on the subject,
> and my reading generally agrees with my own intuition. I think we are in
> danger of violating a cardinal principle of open source development, and
> indeed of software development in general
Indeed indeed. There's nothing particular to OSS development here.
> -- that you operate as much as
> possible with code that works.
However,
1) its can't always be done, and
2) doing it can be digging yourself an even deeper hole.
One of the greatest OSS projects of them all. Mozilla, had a large and
successful code base to work from, but started from scratch.
> Unless you have massive amounts of resources
> (and probably there as well), the only model of software development that
> seems to work is an immediate feedback loop. The sequence is
> 1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the
> question, "Is the code better with this than it was before?" 5) iff "yes",
> check it in.
(Aside: I disagree with the "only model that seems to work" bit. Not
everyone has a short attention span.)
The main line development is not working from existing code and
functionality; it's trying to get new functionality which is frustrated
by the existing design and code. That's not the whole story. A lot of
things can be and have been improved within the existing framework. A
lot of this discussion is about the difference between the two, and
whether that difference requires different handling.
> Now, I understand that sometimes you come to a chasm like the redesign. (I
> am not yet smart enough to understand the issues, but I will take the gurus'
> collective word for it). It is not practical to complete the entire work in
> one step, yet you still need a place to record the incremental changes as
> you move along. In other words, first you break it in some radical way, then
> begin to fix that break around the new design -- again, with immediate
> feedback. I think this is what branches were designed for. You can
> break-and-fix as much as you want in the branch without hurting the code in
> the trunk.
An important point to make about FOP is that a conscious decision was
made some time ago that the redesign would stick with the existing
framework and not be a ground-up reworking. The methodological changes
now being discussed are only possible because of that decision, strongly
argued by Keiron, I believe.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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 clean interface, so as to be able to switch between "current engine,
not perfect but usable", and "new engine, not finished but testable".
I have a feeling that working on the layout engine requires fairly
specialized skills, whereas other parts of the code are more general in
nature (logging, Driver, config, Avalonizing, etc.). IMHO the layout engine
is the most "risky" component of FOP, so a good candidate for a component
with a thin interface.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Jeremias Maerki <de...@greenmail.ch>.
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, 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 Concerns). These are two completely different design and
> > I don't see a chance of properly doing what you propose. The new design
> > however really supports plugging in different implementations but I
> > don't see an easy way to bring over the old layout code.
>
> I understand the point, but I am still skeptical. Here is what I propose. I
> will set up a CVS project on my local machine here that will mimic the real
> FOP repository, and go to work on bringing the two branches back together,
> completely if possible, but with a bare minimum of branching at any rate.
> This will no doubt require some refactoring on the maintenance branch, and
> some merging between the branches. At some point, if my head gets too sore
> (from pounding it against the wall), I will humbly admit defeat and go to
> work on the trunk. A big chunk of this work has to be done eventually
> anyway, and IMHO the sooner it gets done the better. For those who think
> this is diversion of resources away from the real task, my answer is that I
> will probably get up to speed more quickly on the trunk code by doing this
> project than by merely reviewing lines of code.
>
> If the committers tell me up front that a successful effort here will not be
> considered for commit, and considered reasonably promptly, that would
> dissuade me from trying. Otherwise, I think it will be a useful thing both
> for the project and for my understanding of it. The worst case scenario for
> you guys is that I will learn a little humility, which can't be a bad thing
> either.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 here is SoC
> (Separation of Concerns). These are two completely different design and
> I don't see a chance of properly doing what you propose. The new design
> however really supports plugging in different implementations but I
> don't see an easy way to bring over the old layout code.
I understand the point, but I am still skeptical. Here is what I propose. I
will set up a CVS project on my local machine here that will mimic the real
FOP repository, and go to work on bringing the two branches back together,
completely if possible, but with a bare minimum of branching at any rate.
This will no doubt require some refactoring on the maintenance branch, and
some merging between the branches. At some point, if my head gets too sore
(from pounding it against the wall), I will humbly admit defeat and go to
work on the trunk. A big chunk of this work has to be done eventually
anyway, and IMHO the sooner it gets done the better. For those who think
this is diversion of resources away from the real task, my answer is that I
will probably get up to speed more quickly on the trunk code by doing this
project than by merely reviewing lines of code.
If the committers tell me up front that a successful effort here will not be
considered for commit, and considered reasonably promptly, that would
dissuade me from trying. Otherwise, I think it will be a useful thing both
for the project and for my understanding of it. The worst case scenario for
you guys is that I will learn a little humility, which can't be a bad thing
either.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 Concerns). These are two completely different design and
I don't see a chance of properly doing what you propose. The new design
however really supports plugging in different implementations but I
don't see an easy way to bring over the old layout code.
On 02.11.2002 09:56:48 Victor Mote wrote:
> While we are in a brainstorming mode, please forgive me for throwing out
> another wild hare to consider. (This only makes sense if most of the
> differences are in the second class): Is it at all feasible to maintain both
> layout managers in one set of code? In other words, for the choice to be
> selectable or pluggable? Perhaps put the old logic into an oldlayout
> package. If there is a lot of potential commonality between the code, this
> would give us an opportunity to reunify the two branches right now, and
> simply blow the old stuff away at some point in the future when it is no
> longer needed. It would be worth *a lot* to get the branches unified if at
> all possible.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by "Peter B. West" <pb...@powerup.com.au>.
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 haven't finished work
on properties, but as I proceed, I get more insight into the existing
design and implementation, and more respect for it. A newcomer has no
shortcuts to this situation. There's a Catch-22 here for complex open
source projects. Resources are, by definition, in short supply. No
matter what your working environment, the first thing to suffer from
such shortages is documentation. But open source needs documentation
(and the panoply of skills transfer mechanisms) more than a normal project.
....
> The only realistic merge that I can see is bringing across the following
> to the branch:
> - pdf lib
> - svg
> - image handling
>
> maybe
> - renderers
> - area tree
>
> There isn't really that much on the branch that is relevant to the
> trunk. The thing the branch has is that the layout works (sort of) and
> it is a complex beast to do properly.
>
>
> 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.
How difficult would this be? Would it be you who did most of this, or
could you successfully direct others to assist?
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches (how about "fop 2")
Posted by Ralph LaChance <Ra...@compuserve.com>.
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 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 2.x for a mostly new codebase
>makes sense IMHO.
>
>-Bertrand
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>For additional commands, email: fop-dev-help@xml.apache.org
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches (how about "fop 2")
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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 work on it, instead of helping
> us to get HEAD up.
>. . .
I understand your point, but I was rather thinking that having "fop1" and
"fop2" could discourage people from working on old-fashioned fop1 instead of
new and improved fop2...but it's probably all speculation anyway.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches (how about "fop 2")
Posted by "Matthew L. Avizinis" <ml...@gleim.com>.
Here is one other point to consider: if you expect the redesign when
complete to perform at at least the same level, i.e. with the same coverage
of the specification and as many or fewer defects, when it comes "online"
and replaces the current maintenance release, then I imho the project
should continue on as it currently is.
However, if you expect there to be a significant number of bugs to be
discovered and performance to be initially lower, then the project should
move to perhaps fop2 so that users could more easily know that there could
be problems when they upgrade to a new version of fop. Does this make any
sense?
Matthew L. Avizinis <ma...@gleim.com>
Gleim Publications, Inc.
4201 NW 95th Blvd.
Gainesville, FL 32606
(352)-375-0772
www.gleim.com <http://www.gleim.com>
> -----Original Message-----
> From: Victor Mote [mailto:vic@outfitr.com]
> Sent: Saturday, November 02, 2002 11:27 AM
> To: fop-dev@xml.apache.org
> 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 of its meaning and this way we'll encourage
> > many existing and future contributors to work on it, instead of helping
> > us to get HEAD up.
>
> This is a fair point, but I think it weighs only in the decision about
> whether we have a rewrite or not. In other words, it might weigh into the
> economics of whether it is worth it for us to merge the sections of code
> that can be merged. We might be willing to spend more time and effort
> getting the two branches pulled back together than we would be if
> the above
> were not true. If we really do have a rewrite, then I think it
> will clarify
> everything to split into two projects, and I don't begrudge folks from
> working on the old one instead of the new one any more than I
> would begrudge
> the RenderX guys working on their product instead of FOP, or the
> Batik guys
> working on Batik instead of FOP. The problem that Oleg mentions is already
> the status quo.
>
> Victor Mote
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches (how about "fop 2")
Posted by Victor Mote <vi...@outfitr.com>.
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, instead of helping
> us to get HEAD up.
This is a fair point, but I think it weighs only in the decision about
whether we have a rewrite or not. In other words, it might weigh into the
economics of whether it is worth it for us to merge the sections of code
that can be merged. We might be willing to spend more time and effort
getting the two branches pulled back together than we would be if the above
were not true. If we really do have a rewrite, then I think it will clarify
everything to split into two projects, and I don't begrudge folks from
working on the old one instead of the new one any more than I would begrudge
the RenderX guys working on their product instead of FOP, or the Batik guys
working on Batik instead of FOP. The problem that Oleg mentions is already
the status quo.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches (how about "fop 2")
Posted by Oleg Tkachenko <ol...@multiconn.com>.
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 2.x for a mostly new codebase
> makes sense IMHO.
I believe it doesn't matter actually how to version HEAD or how it's
organized within cvs, what does matter is a dissipation of developers
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, instead of helping
us to get HEAD up.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches (how about "fop 2")
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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 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 2.x for a mostly new codebase
makes sense IMHO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by "Peter B. West" <pb...@powerup.com.au>.
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 just to split development, e.g. for
>>the sake of some release bug handling, but branches are not obliged to
>>be merged eventually. Usual development pattern is to branch a release
>>code and continue development with no care about it (bugs are fixed in
>>the branch) and when a new release is ready all patches and bug fixes in
>>branched code *may be* just irrelevant because of new (e.g. redesigned
>>:) implemention.
>>Following this pattern, development of branched code is just ugly mess
>>as it's first of all *maintenance* release.
>
>
> 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.
I don't have the benefit of seeing the future. Oleg says "*may be*",
and that encapsulates things nicely. Branched code *may be* just
irrelevant, or branched code *may be* just relevant. Who knows? But if
the code shares common ancestry, it's a far bet that at some time in
future useful cross-fertilization may occur. Version control systems
are predicated on uncertainty. If I *just know* that this version of
the code is perfect, there's no need for me to hang on to the old stuff.
In fact, complete records of the development, captured in the
CVS/RCS/SCCS/whatever source trees, have turned out to be
extraordinarily useful in the real world.
As for divergent branches, how else do new divergent versions come
about. A new version starts as an idea for development which is going
to diverge from the existing code. That implies that its starting point
is the existing code. When it develops to the point where it can stand
alone, and take over and extend the existing functionality, you can
create a new tree, based on the divergent branch from the old. Not, of
course, am empty tree.
That new tree will share ancestry and a lost of common code with the old
one, but, because the full functionality exists in the new tree, users
can be told that no further development will occur on the old version.
At this point, only critical bug fixes will be contemplated on the old
branch, and the probability of these being required on a mature product
will be considered low. That low probability extends to the probability
that such changes will have to be manually incorporated into the new
tree. After a while the first tree can be retired, as not even bug fixes
will occur. At that point, two divergent lines of development will
exist in the tree, and will have existed for some time.
Even if you have development resources to burn, you approach things
conservatively. While the branches are in the same tree, it remains
feasible, if increasingly difficult, to perform merging. And, if, like
me, you cannot see the future, you want to keep such options open. We
do not have development resources to burn.
> Usual development pattern would also be that someone makes sure that new
> functionality doesn't get added to the maintenance release. That is
> apparently what Keiron is attempting to do now, and I have no problem with
> that. However, our web site says this:
>
> "If you want to work with the latest and nicest code, you can use the cvs
> version. See the section on AnonCVS in the xml.apache.org documentation for
> details....
>
> "Important: Currently, releases of FOP are coming out of the
> "fop-0_20_2-maintain" branch. The "MAIN" branch is used for the redesign.
> See NEW DESIGN for more information."
>
> I hope I will be forgiven for not correctly interpreting the multitude of
> mixed signals.
Yes, there are a couple of mixed signals which require clarification.
Let me say (re another message) that I am not asserting anything about
the feasibility of any approach. I am stating a preference for the
future direction. Those qualified to assess the feasibility of any
approach are, firstly, Keiron and Karen. Karen is otherwise engaged at
the moment. The people who have taken the next most comprehensive look
into the code are probably Joerg and Jeremias. I hope I haven't
offended anyone here; speak up if I have. These are the people who can
comment about feasibility.
If you are looking for a rewrite, go no further than
FOP_0-20-0_Alt-Design. That's a rewrite, from the ground up. Yet it
contains pieces of the 0.20 code. And it is staying in this tree,
because I plan to do some major, time-consuming, finicky, tedious
merging later on. in order to benefit from a number of recent
developments which I have no intention of writing myself.
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.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Keiron Liddle <ke...@aftexsw.com>.
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
> functionality doesn't get added to the maintenance release. That is
> apparently what Keiron is attempting to do now, and I have no problem with
> that. However, our web site says this:
I'm not trying to make sure functionality doesn't get to the branch, I
am trying to get a focus on something that I consider to be more
efficient use of time.
> "If you want to work with the latest and nicest code, you can use the cvs
> version. See the section on AnonCVS in the xml.apache.org documentation for
> details....
>
> "Important: Currently, releases of FOP are coming out of the
> "fop-0_20_2-maintain" branch. The "MAIN" branch is used for the redesign.
> See NEW DESIGN for more information."
>
> I hope I will be forgiven for not correctly interpreting the multitude of
> mixed signals.
When someone starts quoting the website then it is time to update it :)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 just to split development, e.g. for
> the sake of some release bug handling, but branches are not obliged to
> be merged eventually. Usual development pattern is to branch a release
> code and continue development with no care about it (bugs are fixed in
> the branch) and when a new release is ready all patches and bug fixes in
> branched code *may be* just irrelevant because of new (e.g. redesigned
> :) implemention.
> Following this pattern, development of branched code is just ugly mess
> as it's first of all *maintenance* release.
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
functionality doesn't get added to the maintenance release. That is
apparently what Keiron is attempting to do now, and I have no problem with
that. However, our web site says this:
"If you want to work with the latest and nicest code, you can use the cvs
version. See the section on AnonCVS in the xml.apache.org documentation for
details....
"Important: Currently, releases of FOP are coming out of the
"fop-0_20_2-maintain" branch. The "MAIN" branch is used for the redesign.
See NEW DESIGN for more information."
I hope I will be forgiven for not correctly interpreting the multitude of
mixed signals.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Oleg Tkachenko <ol...@multiconn.com>.
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 some release bug handling, but branches are not obliged to
be merged eventually. Usual development pattern is to branch a release
code and continue development with no care about it (bugs are fixed in
the branch) and when a new release is ready all patches and bug fixes in
branched code *may be* just irrelevant because of new (e.g. redesigned
:) implemention.
Following this pattern, development of branched code is just ugly mess
as it's first of all *maintenance* release.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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" instead of "redesign". This would signal that we are
> not merely
> >>rebuilding an important module, but that the changes are
> >>pervasive, and that
> >>the old code has been effectively abandoned.
> >
> >
> > Upon further consideration, I would also recommend that, in the
> above case,
> > we actually put the code into two different projects.
>
> I don't see that anything would be gained, and much would be lost.
>
> > 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.
>
> > and I think that is part of what has been confusing me. By
> > cutting that tie, it would be clear that there will be no merging. Right
> > now, we are kind of half in and half out, and it would be good to signal
> > whatever decision is reached definitively, mostly for the
> benefit of those
> > of us (me) who are slow to catch on.
>
> I'm sorry, Victor, but this makes no sense to me at all. It's the same
> project, and its future lies with the redesign (not rewrite, as I
> pointed out in an earlier message.) The fact that it was branched has
> meant that development has been able to continue in the maint branch.
I now understand Keiron to be saying that it is a rewrite. By rewrite, I
don't mean from the ground up, but I mean that the old code is abandoned. I
am trying to get clarification of this very point.
>
> I agree that the major layout redevelopment should occur on a branch.
> There has already been a lot of time spent on it, and it will take some
> considerable time yet, during which the layout will be pretty much
> broken. So yes, I think that the effort should be made to switch the
> branches. A lot of the useful improvements (the redesign of logging,
> the new configuration mechanisms, etc.) can equally well be applied to
> the existing code, and FOP gives the appearance of being constantly
> improved.
This is what I assumed as well, and I have been operating on the idea that
the two branches would eventually be merged, with any conflicts resolved at
that time. I am now hearing (I think) that one of the following (perhaps
both) have occurred: 1) the redesign changes have become pervasive, or 2)
because we forked code that was really common to both branches, we now have
artificial differences that will be difficult to bring back together.
>
> Meanwhile, the new layout engine can be developed fairly independently
> of the plumbing. It doesn't matter what logger, or configuration
> mechanism or image handling the new layout engine uses in development.
> When it is complete, the merging of all the applicable changes to the
> maint branch would occur. How would this be done from another project?
>
> One of the problems that Keiron may have foreseen with this is that most
> development effort would focus on the maintenance branch for short-term
> results (and kudos) while the new layout engine languished for want of
> love and attention. It's a real concern, made all the more real by the
> tenor of these suggestions.
Please note that my proposal was carefully predicated as follows: "If it is
not feasible to unify significant portions of the two branches, ...". You
are arguing that it is feasible. If that is true, then I agree that we do
not need another project. It is abusive to argue against the proposal
outside of its context.
Here is the algorithm:
1. if the two layout mechanisms can be runtime-selectable
and coexist in the same set of source code:
a. merge the two branches to accomplish this
b. return, break, stop, whatever -- you are done
2. if the two layout mechanisms need to live in separate
source code branches, and there is a lot of common
code between them, and that code can be efficiently
merged:
a. decide where the reunified portions should live,
trunk or branch
b. merge the common code to that location
c. fix the branch tags for the common code so that
anyone checking out or committing code to
either branch will always
get exactly the same piece of code
d. update doc as necessary to support the mechanics
and to explain the logic
e. return, break, stop, whatever -- you are done
3. If benefit can be shown to leaving code that will
never be merged in the same tree:
a. update doc to explain
b. return, break, stop, whatever -- you are done
4. Split the code into two projects
5. Update the doc to explain
5. Return, break, stop
I hope this helps.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by "Peter B. West" <pb...@powerup.com.au>.
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 "redesign". This would signal that we are not merely
>>rebuilding an important module, but that the changes are
>>pervasive, and that
>>the old code has been effectively abandoned.
>
>
> Upon further consideration, I would also recommend that, in the above case,
> we actually put the code into two different projects.
I don't see that anything would be gained, and much would be lost.
> Branches imply
> eventual merging,
Not necessarily.
> and I think that is part of what has been confusing me. By
> cutting that tie, it would be clear that there will be no merging. Right
> now, we are kind of half in and half out, and it would be good to signal
> whatever decision is reached definitively, mostly for the benefit of those
> of us (me) who are slow to catch on.
I'm sorry, Victor, but this makes no sense to me at all. It's the same
project, and its future lies with the redesign (not rewrite, as I
pointed out in an earlier message.) The fact that it was branched has
meant that development has been able to continue in the maint branch.
I agree that the major layout redevelopment should occur on a branch.
There has already been a lot of time spent on it, and it will take some
considerable time yet, during which the layout will be pretty much
broken. So yes, I think that the effort should be made to switch the
branches. A lot of the useful improvements (the redesign of logging,
the new configuration mechanisms, etc.) can equally well be applied to
the existing code, and FOP gives the appearance of being constantly
improved.
Meanwhile, the new layout engine can be developed fairly independently
of the plumbing. It doesn't matter what logger, or configuration
mechanism or image handling the new layout engine uses in development.
When it is complete, the merging of all the applicable changes to the
maint branch would occur. How would this be done from another project?
One of the problems that Keiron may have foreseen with this is that most
development effort would focus on the maintenance branch for short-term
results (and kudos) while the new layout engine languished for want of
love and attention. It's a real concern, made all the more real by the
tenor of these suggestions.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 are not merely
> rebuilding an important module, but that the changes are
> pervasive, and that
> the old code has been effectively abandoned.
Upon further consideration, I would also recommend that, in the above case,
we actually put the code into two different projects. Branches imply
eventual merging, and I think that is part of what has been confusing me. By
cutting that tie, it would be clear that there will be no merging. Right
now, we are kind of half in and half out, and it would be good to signal
whatever decision is reached definitively, mostly for the benefit of those
of us (me) who are slow to catch on.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 progresses
*incrementally* on the trunk. The reason why ours didn't work out that way
(I suspect) is because we tried to do a chasm-type change on the trunk,
where we had to break the code to go forward. With 20/20 hindsight, it is
easy to see that the chasm change would have been more convenient to manage
on a branch. In this respect, it is no different from a normal patch. For a
normal patch, your sandbox is a kind of branch. Only after the code is
completed and tested do you commit it. The only difference with a chasm-type
change is that, because it is so big, you want to be able to put incremental
changes into source code control so that can keep a history. The principle
still remains that only after it is completed and tested should it be merged
(committed, if you will) to the trunk. As you correctly point out elsewhere,
this is all water under the bridge. I mention it only because I suspect that
it explains the difference with mozilla.
> I think you have misunderstood something. There has been a great number
> of changes across many packages and classes in trunk. The reason being
> that the code was (and still is in the branch) in a bad way, this
> occured gradually more because it wasn't prevented from hapenning.
> For example the link support, pdf library, image handling.
> It becomes quite obvious when you understand why there are so many bugs
> with link positioning, image handling and further causes of memory
> leaks, excess memory usage.
I think I understand. However, the question is not the quantity or even
location of the changes that have been made, but the scope. The real
question is how many of the changes that have taken place in the trunk are
changes that were applicable only to the trunk -- in other words, are a lot
of them changes that would have helped or at least not hurt the maintenance
branch?
> This is what seems to be the real problem. You think that the branch is
> mostly okay and only some of it has changed in the trunk. This isn't
> really the case.
I didn't mean to imply that the branch is mostly OK, but I understand your
point.
> The code in the trunk is more advanced in a number of ways. Such as
> transparency, link handling, image handling, gstate, graphic state.
> Now if you are to improve the code in the branch it will mean either it
> has already been done or that the changes will need to be brought across
> from old code to new changed code. In some cases the changes will
> compound old problems (for example you used the MessageHandler).
> Now if the improvements are made in trunk this is more likely to be
> handled better, the code could then go across to improve the branch.
This seems to support my point that some of the files were unnecessarily
forked, but I sure might be missing something again.
Also, it is possible that, even if the unnecessary forks could have been
prevented in the past, the fact that they took place has led to unfixable
differences. For example, if one branch was refactored for X, and the other
was not, it will be more difficult to merge them now. I suspect that your
MessageHandler citation is such an example, as I was imitating other
maintenance branch code.
> There isn't really that much on the branch that is relevant to the
> trunk. The thing the branch has is that the layout works (sort of) and
> it is a complex beast to do properly.
>
>
> 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.
The key here is to divide the differences between the two branches into two
groups: 1) those that *must* be different between the branches or that
cannot be efficiently reconciled, 2) those that can (efficiently) be merged
without breaking either branch. If the differences are heavily in the first
class, we should just continue on from where we are. If they fall
substantially in the second class, then the plan you propose above makes a
lot of sense.
While we are in a brainstorming mode, please forgive me for throwing out
another wild hare to consider. (This only makes sense if most of the
differences are in the second class): Is it at all feasible to maintain both
layout managers in one set of code? In other words, for the choice to be
selectable or pluggable? Perhaps put the old logic into an oldlayout
package. If there is a lot of potential commonality between the code, this
would give us an opportunity to reunify the two branches right now, and
simply blow the old stuff away at some point in the future when it is no
longer needed. It would be worth *a lot* to get the branches unified if at
all possible.
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 are not merely
rebuilding an important module, but that the changes are pervasive, and that
the old code has been effectively abandoned.
Keiron, I'm sorry to keep asking you to answer the same question over and
over again. I guess I've never had to totally abandon useful code before
(however moderate the usefulness might be). If, after considering the above
points, you are sure that we are on the right track, I'll do what I can to
be useful on the trunk. Unless you have a better idea, I'll continue with
the font work -- just understand that the refactoring work will be much more
likely to introduce bugs when I am flying blind than it would be with
working code.
Thanks for your patience.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Keiron Liddle <ke...@aftexsw.com>.
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 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. My first exposure to an open-source project
> was when I started monitoring this list on July, and I have no idea how
> other projects operate. However, I have done some reading on the subject,
> and my reading generally agrees with my own intuition. I think we are in
> danger of violating a cardinal principle of open source development, and
> indeed of software development in general -- that you operate as much as
> possible with code that works. Unless you have massive amounts of resources
> (and probably there as well), the only model of software development that
> seems to work is an immediate feedback loop. The sequence is
> 1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the
> question, "Is the code better with this than it was before?" 5) iff "yes",
> check it in.
That sounds very good and is probably works almost all the time. The
fact is that it was not working.
And as they say, "It seemed like a good idea at the time". Circumstances
change and we need to deal with what is now.
Actually projects like mozilla have branches for maintanence but the key
is that they are short lived, this didn't work out like that.
> Now, I understand that sometimes you come to a chasm like the redesign. (I
> am not yet smart enough to understand the issues, but I will take the gurus'
> collective word for it). It is not practical to complete the entire work in
> one step, yet you still need a place to record the incremental changes as
> you move along. In other words, first you break it in some radical way, then
> begin to fix that break around the new design -- again, with immediate
> feedback. I think this is what branches were designed for. You can
> break-and-fix as much as you want in the branch without hurting the code in
> the trunk.
>
> This leads to a discussion of our CVS repository. If what I said above is
> correct, we essentially have our trunk and branch reversed. This was
> probably done with good intentions, but there are some perverse effects.
> Chief among these is the effect it has on the amount of code that has been
> branched. If I understood Keiron correctly, the redesign only really affects
> code in a limited number of packages. The FO tree and renderers, for
> example, I think should not be affected.
I think you have misunderstood something. There has been a great number
of changes across many packages and classes in trunk. The reason being
that the code was (and still is in the branch) in a bad way, this
occured gradually more because it wasn't prevented from hapenning.
For example the link support, pdf library, image handling.
It becomes quite obvious when you understand why there are so many bugs
with link positioning, image handling and further causes of memory
leaks, excess memory usage.
> However, changes to the working
> code branch are much more widespread. By putting the working code on a
> branch, we have forked a whole bunch of files that really don't need to be
> forked. The merging aspects of this are minimal, but it basically means that
> people working on the trunk (the redesign) can't see changes that are made
> to the working code until that merge takes place. The way we are set up now,
> the same set of changes need to be submitted twice, or else need to be
> merged at some future date. If we had these branches positioned properly,
> changes made to common code would be seen by everyone. (I am not a CVS
> expert, so please correct me if I am wrong -- I am assuming here that people
> working on a branch should use checkout -f to get files that are not on the
> branch from the default branch. That way they get a complete sandbox, even
> of files that are not on the branch). This includes all of the style work
> and refactoring work that is currently going on. In most cases, it only
> needs to be done once, with no merging.
I think it is the opposite, that changes on trunk are much more
widespread.
> Another bad effect of our current arrangement is the false unification of
> documentation. This discussion, however, is probably big enough to require a
> different thread.
>
> There are some pernicious psychological effects at work here as well. If
> making working code better is causing fragmentation (I am unclear about
> whether this is what Keiron meant), then we have really shot ourselves in
> the foot. I understand that there is a cost associated with reviewing and
> disposing of patches. However, I don't think that is the real issue here.
> The real issue appears to be that when we have people working on areas of
> the project apart from the redesign, some assume that those are resources
> that really ought to be spent on the redesign. Jeremias has already pointed
> out one instance where this is a false assumption (an employer that is
> willing to have him work on working code, but is unwilling to have him work
> on redesign). My situation is another. I don't know enough yet to be of help
> in the redesign. I must crawl before I can walk, and working with code that
> works is the only way I have devised to learn what is going on. I will learn
> this stuff ten times faster if I can work on real issues. If patches that
> are submitted to working code are a distraction, I can build a separate
> local repository and commit my changes there. However, this frankly seems to
> be much more fragmentary, and to violate the usefulness of open source.
>
> I guess in summary, I have to respectfully disagree with the idea that
> working on the maintenance branch is a "dead end". Work on the maintenance
> branch in areas that the redesign addresses is probably dead end, but I see
> no reason why that must be true for the project as a whole, except for the
> mechanical problem that exists in our repository.
This is what seems to be the real problem. You think that the branch is
mostly okay and only some of it has changed in the trunk. This isn't
really the case.
Now lets take the PDF library for example (it applies just about
everywhere in the branch due to code being linked all over the place).
The code in the trunk is more advanced in a number of ways. Such as
transparency, link handling, image handling, gstate, graphic state.
Now if you are to improve the code in the branch it will mean either it
has already been done or that the changes will need to be brought across
from old code to new changed code. In some cases the changes will
compound old problems (for example you used the MessageHandler).
Now if the improvements are made in trunk this is more likely to be
handled better, the code could then go across to improve the branch.
> I propose that we stop & take the time to reverse the two lines of
> development in the repository, merging where necessary along the way so that
> our code is reunified to the extent possible. Alternatively, perhaps a CVS
> guru can see a better way to accomplish the same thing. I hope that no one
> views this as a lack of confidence in the work being done on the redesign --
> I simply don't know enough yet to comment one way or the other. Also, I
> apologize in advance for breaking this hornet's nest open -- this is
> probably an old discussion. If it is a settled issue, I'll try to adapt
> myself to it, but I think the effect of this tends to freeze out new
> developers until the existing ones complete the redesign work. This seems to
> me to be a risky and unnecessary strategy, an attempt to force behavior that
> realistically can't happen.
The only realistic merge that I can see is bringing across the following
to the branch:
- pdf lib
- svg
- image handling
maybe
- renderers
- area tree
There isn't really that much on the branch that is relevant to the
trunk. The thing the branch has is that the layout works (sort of) and
it is a complex beast to do properly.
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.
Keiron
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 the only thing we can do is live with the facts but make everyone
> see how working on the maintenance branch is a dead end.
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. My first exposure to an open-source project
was when I started monitoring this list on July, and I have no idea how
other projects operate. However, I have done some reading on the subject,
and my reading generally agrees with my own intuition. I think we are in
danger of violating a cardinal principle of open source development, and
indeed of software development in general -- that you operate as much as
possible with code that works. Unless you have massive amounts of resources
(and probably there as well), the only model of software development that
seems to work is an immediate feedback loop. The sequence is
1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the
question, "Is the code better with this than it was before?" 5) iff "yes",
check it in.
Now, I understand that sometimes you come to a chasm like the redesign. (I
am not yet smart enough to understand the issues, but I will take the gurus'
collective word for it). It is not practical to complete the entire work in
one step, yet you still need a place to record the incremental changes as
you move along. In other words, first you break it in some radical way, then
begin to fix that break around the new design -- again, with immediate
feedback. I think this is what branches were designed for. You can
break-and-fix as much as you want in the branch without hurting the code in
the trunk.
This leads to a discussion of our CVS repository. If what I said above is
correct, we essentially have our trunk and branch reversed. This was
probably done with good intentions, but there are some perverse effects.
Chief among these is the effect it has on the amount of code that has been
branched. If I understood Keiron correctly, the redesign only really affects
code in a limited number of packages. The FO tree and renderers, for
example, I think should not be affected. However, changes to the working
code branch are much more widespread. By putting the working code on a
branch, we have forked a whole bunch of files that really don't need to be
forked. The merging aspects of this are minimal, but it basically means that
people working on the trunk (the redesign) can't see changes that are made
to the working code until that merge takes place. The way we are set up now,
the same set of changes need to be submitted twice, or else need to be
merged at some future date. If we had these branches positioned properly,
changes made to common code would be seen by everyone. (I am not a CVS
expert, so please correct me if I am wrong -- I am assuming here that people
working on a branch should use checkout -f to get files that are not on the
branch from the default branch. That way they get a complete sandbox, even
of files that are not on the branch). This includes all of the style work
and refactoring work that is currently going on. In most cases, it only
needs to be done once, with no merging.
Another bad effect of our current arrangement is the false unification of
documentation. This discussion, however, is probably big enough to require a
different thread.
There are some pernicious psychological effects at work here as well. If
making working code better is causing fragmentation (I am unclear about
whether this is what Keiron meant), then we have really shot ourselves in
the foot. I understand that there is a cost associated with reviewing and
disposing of patches. However, I don't think that is the real issue here.
The real issue appears to be that when we have people working on areas of
the project apart from the redesign, some assume that those are resources
that really ought to be spent on the redesign. Jeremias has already pointed
out one instance where this is a false assumption (an employer that is
willing to have him work on working code, but is unwilling to have him work
on redesign). My situation is another. I don't know enough yet to be of help
in the redesign. I must crawl before I can walk, and working with code that
works is the only way I have devised to learn what is going on. I will learn
this stuff ten times faster if I can work on real issues. If patches that
are submitted to working code are a distraction, I can build a separate
local repository and commit my changes there. However, this frankly seems to
be much more fragmentary, and to violate the usefulness of open source.
I guess in summary, I have to respectfully disagree with the idea that
working on the maintenance branch is a "dead end". Work on the maintenance
branch in areas that the redesign addresses is probably dead end, but I see
no reason why that must be true for the project as a whole, except for the
mechanical problem that exists in our repository.
I propose that we stop & take the time to reverse the two lines of
development in the repository, merging where necessary along the way so that
our code is reunified to the extent possible. Alternatively, perhaps a CVS
guru can see a better way to accomplish the same thing. I hope that no one
views this as a lack of confidence in the work being done on the redesign --
I simply don't know enough yet to comment one way or the other. Also, I
apologize in advance for breaking this hornet's nest open -- this is
probably an old discussion. If it is a settled issue, I'll try to adapt
myself to it, but I think the effect of this tends to freeze out new
developers until the existing ones complete the redesign work. This seems to
me to be a risky and unnecessary strategy, an attempt to force behavior that
realistically can't happen.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
eliminate multi-threading issues in the maintenance branch and bringing
the PostScript renderer to production quality. I've told them a number
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 the only thing we can do is live with the facts but make everyone
see how working on the maintenance branch is a dead end.
Anyway, things are in the works so I get more time (maybe even paid) to
work on FOP redesign. But that won't go without my doing a few things in
the maintenance branch, if I'm not overruled by you guys. I'll get to
you with details as soon as they're nailed down.
> 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 process goes smoothly and promptly
> with causing further confusion and fragmentation.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: handling patches
Posted by Oleg Tkachenko <ol...@multiconn.com>.
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 returning pure bug data in rdf
format instead of presentational html, so we could embed styled patch queue
somewhere on dev pages. But unfortunately it seems nagoya.apache.org/bugzilla
doesn't support rdf.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: handling patches
Posted by Victor Mote <vi...@outfitr.com>.
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 for a period of time -- ie. that they would place this at
the highest priority in their FOP work for, perhaps, a month. With the
volume of patches that is coming in right now, that should (I think) be
pretty light duty. At one time, both Arved & Karen had agreed to
more-or-less do that. 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.
I still like the above idea, but I realize that there are other priorities.
I do think having the queue is a huge improvement. Under the previous
system, there was no way of knowing whether a submission had gone into a
black hole.
> And of course the other issue, where are these patches eventually
> leading to. What I want is that this process goes smoothly and promptly
> with causing further confusion and fragmentation.
If this question has to do with submitting patches to the maintenance
branch, I do have some comments on that. If not, then what is meant by
"confusion and fragmentation"?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org