RE: handling patches
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
RE: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about fop 2)
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
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 [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
New xml-lang.xml
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 using the ISO 639-1 2-letter language codes, as is common usage; e.g. in en_US. The spec has moved to the ISO 639-2 3-letter codes. Unfortunately, there are two sets of 639-2 codes; the terminology and the bibliographic sets, which have a number of differences. The spec defines the terminology set as normative for XSL, but allows for valid 639-2B and 639-1 codes, which are converted to 639-2T. I have extended the language elements of xml-lang.xml to look like: !ELEMENT language EMPTY !ATTLIST language terminology ID #REQUIRED bibliographic NCNAME #IMPLIED iso639-1 NCNAME #IMPLIED EnglishName CDATA #REQUIRED FrenchName CDATA #REQUIRED xml-lang.xsl is used to generate CountryLanguageScript.java, the class against which all new CountryType, LanguageType and ScriptType PropertyValues are validated. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about fop 2)
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
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 [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about fop 2)
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
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.
RE: handling patches
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
