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 Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/08/14 00:08:50 UTC
Release Process Improvements, Versioning etc
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.
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.
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.
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?
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.
Thanks.
Arved
--
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Release Process Improvements, Versioning etc
Posted by Michel Lehon <Mi...@Outwares.com>.
[SNIP]
> > At 10:42 AM 8/14/01 +0200, Michel Lehon wrote:
> > >> From: Weiqi Gao [mailto:weiqigao@networkusa.net]
> > >> On 13 Aug 2001 22:08:50 +0000, Arved Sandstrom wrote:
> > >> > ...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.
> >
> > I don't want to call these things "betas" or "alphas", since
> they aren't.
> > The purpose isn't really different, though, so I'm not
> religious over it.
> > Open-source has fuzzied the meanings up anyway.
> >
> > The pre-release period is meant to be quite short. Weiqi points
> > out that we
> > should RERO (Release Early, Release Often); he's quite right.
> > We've tried to
> > release at least once a month, and maybe even every 2 weeks,
> without much
> > success to date. But if we were releasing once a month I
> wouldn't want to
> > see more than 3 or 4 days allocated to a pre-release code
> freeze, myself.
>
> I think it would be nice to have something like
> code freeze + release, lets call it CF (like code freeze)
> have one week to test it, integrate with other projects...
> do a release without the CF suffix ?
>
even better how about using the same convention as Xalan2
they do Developer releases just for that purpose...
Developer feedback and early user comments...
and it seems to work.
Michel.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Release Process Improvements, Versioning etc
Posted by Michel Lehon <Mi...@Outwares.com>.
Arved,
> -----Original Message-----
> From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
> Sent: Wednesday, 15 August, 2001 10:24
> To: fop-dev@xml.apache.org
> Subject: RE: Release Process Improvements, Versioning etc
>
>
> At 10:42 AM 8/14/01 +0200, Michel Lehon wrote:
> >> From: Weiqi Gao [mailto:weiqigao@networkusa.net]
> >> On 13 Aug 2001 22:08:50 +0000, Arved Sandstrom wrote:
> >> > ...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.
>
> I don't want to call these things "betas" or "alphas", since they aren't.
> The purpose isn't really different, though, so I'm not religious over it.
> Open-source has fuzzied the meanings up anyway.
>
> The pre-release period is meant to be quite short. Weiqi points
> out that we
> should RERO (Release Early, Release Often); he's quite right.
> We've tried to
> release at least once a month, and maybe even every 2 weeks, without much
> success to date. But if we were releasing once a month I wouldn't want to
> see more than 3 or 4 days allocated to a pre-release code freeze, myself.
I think it would be nice to have something like
code freeze + release, lets call it CF (like code freeze)
have one week to test it, integrate with other projects...
do a release without the CF suffix ?
>
> >> 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.
>
> Well, we have a whole whack of JBoss documentation to play
> with...that's a
> project begging for a volunteer. We could also independently showcase the
> use of DocBook, for example.
>
> Finally, all of our own docs should be amenable to FOP processing.
Indeed, it of this sounds great.
>
> >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.
>
> I simply do not understand this point. How is a ZIP file easier?
>
OK, let's call this .2 euro psychology, I know many Windows users that
are put off by .tar.gz files, they think these files are for Unix dist.
So having a .zip as a file format for the distibution (at least the bin)
helps to get those users try and use FOP.
And last every other project as both distibutions, .zip and .tar.gz
Michel Lehon
Michel.Lehon@Outwares.com
Partner, Outwares sprl.
SAS Data Warehousing and Web Enablement.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Release Process Improvements, Versioning etc
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 10:42 AM 8/14/01 +0200, Michel Lehon wrote:
>> From: Weiqi Gao [mailto:weiqigao@networkusa.net]
>> On 13 Aug 2001 22:08:50 +0000, Arved Sandstrom wrote:
>> > ...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.
I don't want to call these things "betas" or "alphas", since they aren't.
The purpose isn't really different, though, so I'm not religious over it.
Open-source has fuzzied the meanings up anyway.
The pre-release period is meant to be quite short. Weiqi points out that we
should RERO (Release Early, Release Often); he's quite right. We've tried to
release at least once a month, and maybe even every 2 weeks, without much
success to date. But if we were releasing once a month I wouldn't want to
see more than 3 or 4 days allocated to a pre-release code freeze, myself.
>> 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.
Well, we have a whole whack of JBoss documentation to play with...that's a
project begging for a volunteer. We could also independently showcase the
use of DocBook, for example.
Finally, all of our own docs should be amenable to FOP processing.
>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.
I simply do not understand this point. How is a ZIP file easier?
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Release Process Improvements, Versioning etc
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Release Process Improvements, Versioning etc
Posted by Michel Lehon <Mi...@Outwares.com>.
> From: Weiqi Gao [mailto:weiqigao@networkusa.net]
> Sent: Tuesday, 14 August, 2001 05:27
> To: fop-dev@xml.apache.org
> Subject: Re: Release Process Improvements, Versioning etc
>
>
> On 13 Aug 2001 22:08:50 +0000, 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
Michel.Lehon@Outwares.com
Partner, Outwares sprl.
SAS Data Warehousing and Web Enablement.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Release Process Improvements, Versioning etc
Posted by Weiqi Gao <we...@networkusa.net>.
On 13 Aug 2001 22:08:50 +0000, 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
weiqigao@networkusa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Release Process Improvements, Versioning etc
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org