Re: Release Process Improvements, Versioning etc
On Tue, 14 Aug 2001 05:27:26 Weiqi Gao wrote: I have not used the testing framework. I tried ./build.sh test once and it threw me some error message. It would be benefitial if the testing frame work can be made to work in a way similar to the make; make check sequence for GNU projects. That way more people would run the test. All you need to do to get it working is follow the suggestion in the error message, ie. put a reference jar in test/reference/. It also must be the right version. If this is too much then the only other option is to put that into cvs. If feasible, solicit donations to the test case .fo files directory from other applications, authors of XML books, the W3C recommendation authors, and FOP users in general. The idea is to build a formidable set of real world examples of .fo files, and .xml/.xslt files so as to 1) test FOP, and 2) show case FOP's capabilities. Wouldn't it be nice if after building and testing FOP from a source download, the user gets a subset of the W3C XSL 1.0 Recommendation (or a section of the DocBook Definitive Guide, or Chapter 17 of the XML Bible) in PDF format ready to be viewed, searched, and printed. It is quite simple to test fop with all the w3c testing examples. THere are a LOT of tests there, but again it requires some effort on the users side (this cannot be put into cvs). I suppose if people read the website they might find out about it :). The only problem is that fop has some serious errors with some of the examples. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Release Process Improvements, Versioning etc
On Tue, 14 Aug 2001 00:08:50 Arved Sandstrom wrote: Hi, all I invite everyone to submit ideas as to how we can improve the release process: versioning, builds and testing. It seems like almost everytime a 0.X.0 release comes out, there is almost instantaneously a showstopper bug that necessitates a 0.X.1 release, as happened this time. Indeed, I think we need to realise that this project is vast and testing covers quite a number of different things: - each renderer (usually only done by from use, difficult to do) - interaction with external data (fonts, images, svg) - interaction with other projects/api (xerces, xalan, cocoon, batik etc.) Gump helps alot here (Thanks Sam) - reading in xml data (generally handled but has occasional problems) - layout fo objects So if we keep the interaction between these then it should make the task easier (changing one thing doesn't break others) I think it is too difficult to test all of this at this stage BUT we can try to improve areas like font embedding, external images. I am sure there is other stuff also. My goal here is to develop a formal process document that describes exactly what I do, so that anyone with commit privileges can easily duplicate the complete release process. I noticed that batik has a release type document MAINTAIN which has info about releasing and website updating. Another point is of course the website. It is difficult to update, not to mention that stylebook has bugs, and it should be easy to do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Release Process Improvements, Versioning etc
From: Weiqi Gao [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 14 August, 2001 05:27 To: [EMAIL PROTECTED] Subject: Re: Release Process Improvements, Versioning etc On 13 Aug 2001 22:08:50 +, Arved Sandstrom wrote: I invite everyone to submit ideas as to how we can improve the release process: versioning, builds and testing. It seems like almost everytime a 0.X.0 release comes out, there is almost instantaneously a showstopper bug that necessitates a 0.X.1 release, as happened this time. If making a release reveals bugs, then there should be more releases. Release early, release often is one of the tenets of Open Source. I don't want to dictate how things would work - we have a lot of good developers here who do configuration management, source control and testing in real life just as I do - but here are a few obvious ideas. 1) Believe it or not I can actually guarantee to do builds on a given date, now that I have a system for doing the CHANGES file rather rapidly. So once we have decided on a given date for a release, I suggest that we mandate a code freeze starting N days before the release. At the start of the freeze I build a pre-release distro, and it will be labelled as a pre-release (PR suffix maybe?) During those N days (2 days, 3 days?) everyone will have an opportunity to test the release, and find those bad bugs that somehow never showed up before. That sounds like a very good idea. And I have seen other Apache projects doing it. (Except that they are not calling it PR. This is another instance where Apache management should probably dictate all sub projects to use a uniform name for the pre-releases.) How about beta releases ? like they do for Tomcat, Cocoon, ... The beta cycle would be nice for bug fixes, user feedback, and integration with other projects. For examples I think Cocoon 2 will be hit by the same problem as I had (removed methods, NullPointerException when using the ContentHandler), and for which I submitted a patch (Ok, it was not a diff) 2) More comprehensive build tests. I am not so much concerned with how the PDF looks as just making sure we get no exceptions. Petr Andrs' font embedding examples, if used as build tests, would have caught a bad bug, for example. This testing is complementary to the testing Keiron Liddle has laid the groundwork for, which is oriented towards conformance testing. I have not used the testing framework. I tried ./build.sh test once and it threw me some error message. It would be benefitial if the testing frame work can be made to work in a way similar to the make; make check sequence for GNU projects. That way more people would run the test. Make it a rule that absolutely nothing will be committed without clearing all the tests. If feasible, solicit donations to the test case .fo files directory from other applications, authors of XML books, the W3C recommendation authors, and FOP users in general. The idea is to build a formidable set of real world examples of .fo files, and .xml/.xslt files so as to 1) test FOP, and 2) show case FOP's capabilities. Wouldn't it be nice if after building and testing FOP from a source download, the user gets a subset of the W3C XSL 1.0 Recommendation (or a section of the DocBook Definitive Guide, or Chapter 17 of the XML Bible) in PDF format ready to be viewed, searched, and printed. That would really be great. 3) Versioning and build numbers: I hate putting up FOP-0.20.0, and 24 hours later putting up FOP-0.20.1, just for a bug fix. Granted, it was an important defect, and needed to be addressed right away, but I don't think it rates that kind of revision increment. I don't have any good suggestions (I know how I do things at work, but that's different). Any thoughts? 0.20.1 is fine. I don't have any issues with it. If another bug was found and fixed tomorrow, I would be glad to use a 0.20.2. As it is right now, I don't think that we are making a full use of the third number anyway. That could be avoided using a beta cycle... however that should not prevent a 0.20.1 or 0.20.2 to happen. I am sure there is other stuff also. My goal here is to develop a formal process document that describes exactly what I do, so that anyone with commit privileges can easily duplicate the complete release process. A pre-release communication with other Open Source projects, like Cocoon2, about API changes and other changes that may potentially impact them is also critical. Again a beta cycle would be nice. and last, how about a zip file for windows users (I know winzip can handle .tar.gz), I would be easier and would not put off normal windows users. Michel Lehon [EMAIL PROTECTED] Partner, Outwares sprl. SAS Data Warehousing and Web Enablement. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Release Process Improvements, Versioning etc
On 13 Aug 2001 22:08:50 +, Arved Sandstrom wrote: I invite everyone to submit ideas as to how we can improve the release process: versioning, builds and testing. It seems like almost everytime a 0.X.0 release comes out, there is almost instantaneously a showstopper bug that necessitates a 0.X.1 release, as happened this time. If making a release reveals bugs, then there should be more releases. Release early, release often is one of the tenets of Open Source. I don't want to dictate how things would work - we have a lot of good developers here who do configuration management, source control and testing in real life just as I do - but here are a few obvious ideas. 1) Believe it or not I can actually guarantee to do builds on a given date, now that I have a system for doing the CHANGES file rather rapidly. So once we have decided on a given date for a release, I suggest that we mandate a code freeze starting N days before the release. At the start of the freeze I build a pre-release distro, and it will be labelled as a pre-release (PR suffix maybe?) During those N days (2 days, 3 days?) everyone will have an opportunity to test the release, and find those bad bugs that somehow never showed up before. That sounds like a very good idea. And I have seen other Apache projects doing it. (Except that they are not calling it PR. This is another instance where Apache management should probably dictate all sub projects to use a uniform name for the pre-releases.) 2) More comprehensive build tests. I am not so much concerned with how the PDF looks as just making sure we get no exceptions. Petr Andrs' font embedding examples, if used as build tests, would have caught a bad bug, for example. This testing is complementary to the testing Keiron Liddle has laid the groundwork for, which is oriented towards conformance testing. I have not used the testing framework. I tried ./build.sh test once and it threw me some error message. It would be benefitial if the testing frame work can be made to work in a way similar to the make; make check sequence for GNU projects. That way more people would run the test. Make it a rule that absolutely nothing will be committed without clearing all the tests. If feasible, solicit donations to the test case .fo files directory from other applications, authors of XML books, the W3C recommendation authors, and FOP users in general. The idea is to build a formidable set of real world examples of .fo files, and .xml/.xslt files so as to 1) test FOP, and 2) show case FOP's capabilities. Wouldn't it be nice if after building and testing FOP from a source download, the user gets a subset of the W3C XSL 1.0 Recommendation (or a section of the DocBook Definitive Guide, or Chapter 17 of the XML Bible) in PDF format ready to be viewed, searched, and printed. 3) Versioning and build numbers: I hate putting up FOP-0.20.0, and 24 hours later putting up FOP-0.20.1, just for a bug fix. Granted, it was an important defect, and needed to be addressed right away, but I don't think it rates that kind of revision increment. I don't have any good suggestions (I know how I do things at work, but that's different). Any thoughts? 0.20.1 is fine. I don't have any issues with it. If another bug was found and fixed tomorrow, I would be glad to use a 0.20.2. As it is right now, I don't think that we are making a full use of the third number anyway. I am sure there is other stuff also. My goal here is to develop a formal process document that describes exactly what I do, so that anyone with commit privileges can easily duplicate the complete release process. A pre-release communication with other Open Source projects, like Cocoon2, about API changes and other changes that may potentially impact them is also critical. -- Weiqi Gao [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
