Re: Preparing for the first release
Hi Jeremias, Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 10:52:51 AM: > Don't take what I wrote too much by the letter. Always add a little > common sense. See below. The problem is that when talking about processes it isn't good to count on 'common sense'. Just to be clear we are talking about 'theoretical' issues here not something that is currently an issue. > On 15.11.2005 15:49:39 thomas.deweese wrote: > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 08:28:11 AM: > > > > > In terms of the Apache bylaws the PMC is the only body that can do > > > project decisions [1]. > > > >It appears that they are the 'binding body' from the ASF point of > > view, but as a PMC member I would really like to see an invitation > > for the collection of other points of view (i.e. a vote on dev/user > > for a release). In this case I'm sure it will be greeted with > > enthusiasm, but I'm really hesitant to set precedent based on the > > 'best case' situation. > > I've always intended to CC fop-dev for the release vote, but the vote > will happen on [EMAIL PROTECTED] Everyone from the project is invited > to vote and to express their opinion. If one of the non-PMC committers > has a justified objection, nobody is ever going to ignore that. Then it should be written in the 'By-laws' of the PMC, otherwise when things 'go bad' they may be. In the end if things go very wrong things could potentially be escalated to the Board, and that may be enough of an escape clause. > At least, I will see to that. As long as you are head of the PMC. > In the end, though, and from a legal POV, it's the PMC's call. That's > also why I sent out another note that all committers who care about > the project are invited to join the PMC. It's what the board > encourages nowadays. This is good of course. > > As chair it appears that this is your call, so I'll just provide my > > 2 cents. > > It's not my call, it's the PMC's. It's only my call when I see something > go extremely wrong like it happened in the Avalon project. Well some of the talk on legal seemed to indicate that from an ASF point of view the chair of the PMC (as an officer of Apache) was the primary controlling party and policy setting entity. However in normal circumstances I agree the PMC as a whole should be the one setting policy. > If we as a PMC want to establish such an additional requirement, > we can of course do that. Every PMC member is free to propose > something like that. We'll then discuss it on the [EMAIL PROTECTED] > list and if necessary vote on it. I may try and do that (free time permitting, as I said I don't consider this an issue right now it's more of a 'what if' concern). > But as I said, adding some common sense, an objection from a committer > won't be ignored, so I don't think such an additional rule is strictly > necessary. These things are never an problem until they are a problem. ;) > > > Where did you read this that a vote has to run a full week? AFAIK, > > > the normal period is 72 hours [3]. > > > >I think reading 'at least 72 hours' as 'normal period' is a little > > misleading. It is far to common for people to disappear for a week's > > vacation meaning that with just 72hrs an issue can come up be voted > > before someone sipping margarita's in the Bahamas even knows what has > > happened. I know that Batik always used 1 week for important votes > > for exactly this reason. It can of course be terminated earlier if > > all binding voters reply before the time is up. > > Fair enough. It's certainly a bad sign if somebody would want to rush > through a vote when someone who will certainly object to the matter at > hand was away. On the other side, you have to keep the project alive and > always having to wait on the last person holds things up unnecessarily. Actually for a release holding a week long vote seems entirely appropriate to me, and I would challenge the notion that 'holding up' a release 4-5 extra days for a proper vote has an impact on anything. How long has it been since FOP was last released? does 4-5 days really matter? > That's why it's good if committers drop a short note to the list when > they are away for a longer period. Sure, but even if they do it's doesn't protect them from the 72hr rule if someone chooses to exploit it (yes this would be a bad sign). > >I think a clear distinction should be made between the minimum > > required by the ASF and what we think is reasonable. > > Of course. My current focus is to go towards the rules the board wants > to see followed, foremost of all: better oversight. Right but what the board wants I think has to be viewed as a minimum. > > Especially because in my mind the constituent projects under the > > XML-Graphics PMC are probably more independent than many. > > Please explain. I'm a little worried about that comment. Don't read too much into it. I'm just sa
Re: Preparing for the first release
Hi Thomas Don't take what I wrote too much by the letter. Always add a little common sense. See below. On 15.11.2005 15:49:39 thomas.deweese wrote: > Hi Jeremias, > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 08:28:11 AM: > > > In terms of the Apache bylaws the PMC is the only body that can do > > project decisions [1]. > >It appears that they are the 'binding body' from the ASF point of > view, but as a PMC member I would really like to see an invitation > for the collection of other points of view (i.e. a vote on dev/user > for a release). In this case I'm sure it will be greeted with > enthusiasm, but I'm really hesitant to set precedent based on the > 'best case' situation. I've always intended to CC fop-dev for the release vote, but the vote will happen on [EMAIL PROTECTED] Everyone from the project is invited to vote and to express their opinion. If one of the non-PMC committers has a justified objection, nobody is ever going to ignore that. At least, I will see to that. In the end, though, and from a legal POV, it's the PMC's call. That's also why I sent out another note that all committers who care about the project are invited to join the PMC. It's what the board encourages nowadays. > > BTW, this is a topic that's currently discussed on legal-discuss [2]. > >From a quick read I take away that the ASF requires 3 +1 from PMC > members (oddly unvetoable), but that individual PMC's can have > additional requirements, such as a positive vote from committers. As > chair it appears that this is your call, so I'll just provide my > 2 cents. It's not my call, it's the PMC's. It's only my call when I see something go extremely wrong like it happened in the Avalon project. If we as a PMC want to establish such an additional requirement, we can of course do that. Every PMC member is free to propose something like that. We'll then discuss it on the [EMAIL PROTECTED] list and if necessary vote on it. But as I said, adding some common sense, an objection from a committer won't be ignored, so I don't think such an additional rule is strictly necessary. > > Where did you read this that a vote has to run a full week? AFAIK, > > the normal period is 72 hours [3]. > >I think reading 'at least 72 hours' as 'normal period' is a little > misleading. It is far to common for people to disappear for a week's > vacation meaning that with just 72hrs an issue can come up be voted > before someone sipping margarita's in the Bahamas even knows what has > happened. I know that Batik always used 1 week for important votes > for exactly this reason. It can of course be terminated earlier if > all binding voters reply before the time is up. Fair enough. It's certainly a bad sign if somebody would want to rush through a vote when someone who will certainly object to the matter at hand was away. On the other side, you have to keep the project alive and always having to wait on the last person holds things up unnecessarily. That's why it's good if committers drop a short note to the list when they are away for a longer period. > > I think it would be worthwhile if everybody here would reread the pages > > about how the ASF works. There have been quite a few improvements on > > these pages lately. The board and the members also made up their minds > > some more aboute certain topics. > >I think a clear distinction should be made between the minimum > required by the ASF and what we think is reasonable. Of course. My current focus is to go towards the rules the board wants to see followed, foremost of all: better oversight. > Especially > because in my mind the constituent projects under the XML-Graphics PMC > are probably more independent than many. Please explain. I'm a little worried about that comment. > To be honest it makes me > quite uncomfortable that at least in theory Batik could be 'forced' > to have a release by FOP (even in spite of strong objections from the > Batik community). Now I don't consider this a serious concern right now > but the fact that the passability exists is IMHO bad. Seriously, Thomas, such a thing will never happen. You know that the PMC members theoretically have write access to the Batik codebase but no non-Batik PMC member is ever going to touch the Batik codebase without invitation. It's a matter of respect. If this would be a real problem we would need to split up XML Graphics into two projects. > > Even I should probably reread them > > again, although as a member I get a lot of that through the members list > > already. Reading those pages shows, for example, why the XML project had > > to split up. > > > > While we're at it: There are even voices that projects shouldn't > > micromanage committer sets anymore. For us, that would mean: All Batik > > committers become FOP committers and vice-versa. But that's for later. > > So far, it was just a stray comment on one of the lists. > >Well, once again I think that having shared c
Re: Preparing for the first release
Hi Jeremias, Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 08:28:11 AM: > In terms of the Apache bylaws the PMC is the only body that can do > project decisions [1]. It appears that they are the 'binding body' from the ASF point of view, but as a PMC member I would really like to see an invitation for the collection of other points of view (i.e. a vote on dev/user for a release). In this case I'm sure it will be greeted with enthusiasm, but I'm really hesitant to set precedent based on the 'best case' situation. > BTW, this is a topic that's currently discussed on legal-discuss [2]. From a quick read I take away that the ASF requires 3 +1 from PMC members (oddly unvetoable), but that individual PMC's can have additional requirements, such as a positive vote from committers. As chair it appears that this is your call, so I'll just provide my 2 cents. > Where did you read this that a vote has to run a full week? AFAIK, > the normal period is 72 hours [3]. I think reading 'at least 72 hours' as 'normal period' is a little misleading. It is far to common for people to disappear for a week's vacation meaning that with just 72hrs an issue can come up be voted before someone sipping margarita's in the Bahamas even knows what has happened. I know that Batik always used 1 week for important votes for exactly this reason. It can of course be terminated earlier if all binding voters reply before the time is up. > I think it would be worthwhile if everybody here would reread the pages > about how the ASF works. There have been quite a few improvements on > these pages lately. The board and the members also made up their minds > some more aboute certain topics. I think a clear distinction should be made between the minimum required by the ASF and what we think is reasonable. Especially because in my mind the constituent projects under the XML-Graphics PMC are probably more independent than many. To be honest it makes me quite uncomfortable that at least in theory Batik could be 'forced' to have a release by FOP (even in spite of strong objections from the Batik community). Now I don't consider this a serious concern right now but the fact that the passability exists is IMHO bad. > Even I should probably reread them > again, although as a member I get a lot of that through the members list > already. Reading those pages shows, for example, why the XML project had > to split up. > > While we're at it: There are even voices that projects shouldn't > micromanage committer sets anymore. For us, that would mean: All Batik > committers become FOP committers and vice-versa. But that's for later. > So far, it was just a stray comment on one of the lists. Well, once again I think that having shared committership among the xml-graphics-commons packages is a good thing (it's a set of code that is needed/used fairly heavily by both projects), however I think it would be a poor choice to have a common set of committers for the core of FOP and Batik, one would essentially have to 'trust' the other projects committers to have good judgement, and what to do if they violate that trust? They may make good/useful contributions to the other project, so revoking committership may overly harsh (at least for one project). > [1] http://www.apache.org/foundation/how-it-works.html#pmc-members > [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ > [3] http://www.apache.org/foundation/voting.html > > On 15.11.2005 13:59:45 thomas.deweese wrote: > > Hi Jeremias, > > > > Not to rain on your parade, but doesn't there need to be a vote on > > fop-dev by committers on the release before > > bringing it to the PMC? Also doesn't a formal vote need to run at least > > one full week? I understand your > > desire to get the release out but... > > > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/14/2005 05:48:36 PM: > > > > > BTW, I think I'm through with all the things I wanted to do. What's left > > > now: > > > - write the README/release notes > > > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > > > - do the (PMC) vote on the release. > > > - tag and release > > > > > > If it's possible I'd like to start the vote tomorrow and do the release > > > around Thursday/Friday. That reasonable? > > > > Jeremias Maerki >
Re: Preparing for the first release
Oh, I got sunshine outside. Not even fog today. :-) No, there's no need for a committer vote prior to the PMC vote. In terms of the Apache bylaws the PMC is the only body that can do project decisions [1]. BTW, this is a topic that's currently discussed on legal-discuss [2]. Where did you read this that a vote has to run a full week? AFAIK, the normal period is 72 hours [3]. I think it would be worthwhile if everybody here would reread the pages about how the ASF works. There have been quite a few improvements on these pages lately. The board and the members also made up their minds some more aboute certain topics. Even I should probably reread them again, although as a member I get a lot of that through the members list already. Reading those pages shows, for example, why the XML project had to split up. While we're at it: There are even voices that projects shouldn't micromanage committer sets anymore. For us, that would mean: All Batik committers become FOP committers and vice-versa. But that's for later. So far, it was just a stray comment on one of the lists. [1] http://www.apache.org/foundation/how-it-works.html#pmc-members [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [3] http://www.apache.org/foundation/voting.html On 15.11.2005 13:59:45 thomas.deweese wrote: > Hi Jeremias, > > Not to rain on your parade, but doesn't there need to be a vote on > fop-dev by committers on the release before > bringing it to the PMC? Also doesn't a formal vote need to run at least > one full week? I understand your > desire to get the release out but... > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/14/2005 05:48:36 PM: > > > BTW, I think I'm through with all the things I wanted to do. What's left > > now: > > - write the README/release notes > > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > > - do the (PMC) vote on the release. > > - tag and release > > > > If it's possible I'd like to start the vote tomorrow and do the release > > around Thursday/Friday. That reasonable? Jeremias Maerki
Re: Preparing for the first release
Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/14/2005 05:48:36 PM: > BTW, I think I'm through with all the things I wanted to do. What's left > now: > - write the README/release notes > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > - do the (PMC) vote on the release. > - tag and release > > If it's possible I'd like to start the vote tomorrow and do the release > around Thursday/Friday. That reasonable?
Re: Preparing for the first release
On 15.11.2005 11:42:31 Christian Geisert wrote: > Jeremias Maerki schrieb: > > On 15.11.2005 10:50:07 Christian Geisert wrote: > > [..] > > >>I don't think we need to vote on alpha/preview release (preview release > >>as in "will be available on cvs.apache.org/builds/fop and not on the > >>official www.apache.org/dist") but should do it nevertheless. > > > > But that won't make infrastructure very happy because that will create a > > lot of traffic on Apache infrastructure if the release isn't mirrored. > > Furthermore, we want to give out a signal that we're back in the > > business and that means an announcement through various channels. And > > that in turn will create traffic. I would strongly suggest we send it > > out through the distribution system, i.e. a vote is necessary. > > But an official release means it will be available "forever" on > http://archive.apache.org/dist/xml/fop/ Is that so bad? > And http://www.apache.org/dev/mirrors.html says: > "Essentially, any release that you do not consider ready for prime time > should go here. [people.apache.org:/www/cvs.apache.org/]" Sure, but we want people to try the software and that's kind of "prime time". The part you're quoting also says: "pre-releases aimed at the developer community, but not at end users". I'd like to aim at end users. I want their feedback. Some people will only start looking at the new code when we provide them with a precompiled binary. > I agree with you on the traffic issue. > > -- > Christian Jeremias Maerki
Re: Preparing for the first release
Jeremias Maerki schrieb: > On 15.11.2005 10:50:07 Christian Geisert wrote: [..] >>I don't think we need to vote on alpha/preview release (preview release >>as in "will be available on cvs.apache.org/builds/fop and not on the >>official www.apache.org/dist") but should do it nevertheless. > > But that won't make infrastructure very happy because that will create a > lot of traffic on Apache infrastructure if the release isn't mirrored. > Furthermore, we want to give out a signal that we're back in the > business and that means an announcement through various channels. And > that in turn will create traffic. I would strongly suggest we send it > out through the distribution system, i.e. a vote is necessary. But an official release means it will be available "forever" on http://archive.apache.org/dist/xml/fop/ And http://www.apache.org/dev/mirrors.html says: "Essentially, any release that you do not consider ready for prime time should go here. [people.apache.org:/www/cvs.apache.org/]" I agree with you on the traffic issue. -- Christian
Re: Preparing for the first release
Christian Geisert wrote:
Chris Bowditch schrieb:
Sorry to be picky, but the word "alpha" gives the impression that the
release is alpha quality. I'd say it was beta quality by now. Anyway, I
thought in the past we had agreed on calling it 0.90pr1, with "pr"
meaning preview, which in IMHO sounds better than "alpha"
And I thought we agreed on alpha ;-)
Not that I care that much but I think alpha is clearer ("not ready for
production") and imagine some people might not know what "pr" means.
OK. I guess you are right. Alpha it is then.
Chris
Re: Preparing for the first release
Jeremias Maerki wrote: On 15.11.2005 10:28:19 Chris Bowditch wrote: Sorry to be picky, but the word "alpha" gives the impression that the release is alpha quality. I'd say it was beta quality by now. Anyway, I thought in the past we had agreed on calling it 0.90pr1, with "pr" meaning preview, which in IMHO sounds better than "alpha" On the release plan we had "0.90 alpha 1" [1]. True, I didn't notice it until now. It's the first release of a totally new codebase so without more (positive) feedback from users (so far we only have bug reports) I'm more inclined to an alpha release right now, soon followed by a beta release when we have more feedback. I don't feel that strongly about this, but I do think the word "alpha" will put a lot of people off using it. By naming it "beta" or "preview", I think we are putting the message out that its ready for testing by the public. For example, we don't have any experience of FOP working in a multi-threaded environment. I haven't had time to do testing in this area lately. Furthermore, memory is still quickly eaten up in the current state. It would make me very uneasy to use something like this in a production environment right now. I agree, from the feature POV, it's at least beta quality but that only covers the layout engine due to its many tests. But if the majority believes a "beta" is better, that's fine with me. Most sensible folks wouldn't use a "beta" or "preview" release in production either. But there are always exceptions to the rule. Chris
Re: Preparing for the first release
On 15.11.2005 10:50:07 Christian Geisert wrote: > Jeremias Maerki schrieb: > > I agree with you two. Therefore, I've resurrected status.xml, added it > > to our website again and prepared it so we can start using it after the > > release. > > > > BTW, I think I'm through with all the things I wanted to do. What's left > > now: > > - write the README/release notes > > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > > - do the (PMC) vote on the release. > > I don't think we need to vote on alpha/preview release (preview release > as in "will be available on cvs.apache.org/builds/fop and not on the > official www.apache.org/dist") but should do it nevertheless. But that won't make infrastructure very happy because that will create a lot of traffic on Apache infrastructure if the release isn't mirrored. Furthermore, we want to give out a signal that we're back in the business and that means an announcement through various channels. And that in turn will create traffic. I would strongly suggest we send it out through the distribution system, i.e. a vote is necessary. > > - tag and release > > > > If it's possible I'd like to start the vote tomorrow and do the release > > around Thursday/Friday. That reasonable? > > Ok. > > Christian Jeremias Maerki
Re: Preparing for the first release
Chris Bowditch schrieb:
> Jeremias Maerki wrote:
[..]
>> - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1.
>
> Sorry to be picky, but the word "alpha" gives the impression that the
> release is alpha quality. I'd say it was beta quality by now. Anyway, I
> thought in the past we had agreed on calling it 0.90pr1, with "pr"
> meaning preview, which in IMHO sounds better than "alpha"
And I thought we agreed on alpha ;-)
Not that I care that much but I think alpha is clearer ("not ready for
production") and imagine some people might not know what "pr" means.
--
Christian
Re: Preparing for the first release
Jeremias Maerki schrieb: > I agree with you two. Therefore, I've resurrected status.xml, added it > to our website again and prepared it so we can start using it after the > release. > > BTW, I think I'm through with all the things I wanted to do. What's left > now: > - write the README/release notes > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > - do the (PMC) vote on the release. I don't think we need to vote on alpha/preview release (preview release as in "will be available on cvs.apache.org/builds/fop and not on the official www.apache.org/dist") but should do it nevertheless. > - tag and release > > If it's possible I'd like to start the vote tomorrow and do the release > around Thursday/Friday. That reasonable? Ok. Christian
Re: Preparing for the first release
On 15.11.2005 10:28:19 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > I agree with you two. Therefore, I've resurrected status.xml, added it > > to our website again and prepared it so we can start using it after the > > release. > > > > BTW, I think I'm through with all the things I wanted to do. What's left > > now: > > - write the README/release notes > > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > > Sorry to be picky, but the word "alpha" gives the impression that the > release is alpha quality. I'd say it was beta quality by now. Anyway, I > thought in the past we had agreed on calling it 0.90pr1, with "pr" > meaning preview, which in IMHO sounds better than "alpha" On the release plan we had "0.90 alpha 1" [1]. It's the first release of a totally new codebase so without more (positive) feedback from users (so far we only have bug reports) I'm more inclined to an alpha release right now, soon followed by a beta release when we have more feedback. For example, we don't have any experience of FOP working in a multi-threaded environment. I haven't had time to do testing in this area lately. Furthermore, memory is still quickly eaten up in the current state. It would make me very uneasy to use something like this in a production environment right now. I agree, from the feature POV, it's at least beta quality but that only covers the layout engine due to its many tests. But if the majority believes a "beta" is better, that's fine with me. [1] http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR > > - do the (PMC) vote on the release. > > - tag and release > > > > If it's possible I'd like to start the vote tomorrow and do the release > > around Thursday/Friday. That reasonable? > > Sounds good. > > Chris Jeremias Maerki
Re: Preparing for the first release
Jeremias Maerki wrote: I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. Sorry to be picky, but the word "alpha" gives the impression that the release is alpha quality. I'd say it was beta quality by now. Anyway, I thought in the past we had agreed on calling it 0.90pr1, with "pr" meaning preview, which in IMHO sounds better than "alpha" - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Sounds good. Chris
Re: Preparing for the first release
On Tue, 15 Nov 2005 06:48 am, Jeremias Maerki wrote: > I agree with you two. Therefore, I've resurrected status.xml, added > it to our website again and prepared it so we can start using it > after the release. > > BTW, I think I'm through with all the things I wanted to do. What's > left now: > - write the README/release notes > - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. > - do the (PMC) vote on the release. > - tag and release I suggest to add to this list: Compliance page: Remove reference to Trunk and replace by 'Latest Release'. That is the compliance page to compare the old fop 0.20.5 release against the latest released version of fop. Deltas between the latest release and the current trunk version are tracked using status.xml. On every new release compliance changes to be transferred from status.xml to compliance.ihtml. > > If it's possible I'd like to start the vote tomorrow and do the > release around Thursday/Friday. That reasonable? > Fine with me. > > Jeremias Maerki Manuel
Re: Preparing for the first release
I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? On 14.11.2005 18:12:22 Christian Geisert wrote: > Manuel Mall schrieb: > > [..] > > >>IMHO there should be a changes document (as part of the > >>distribution), at least starting after the 1.0 release. > > > > Yes there should - but for now: Just remove CHANGES and update README? > > I'd say yes. > > -- > Christian Jeremias Maerki
Re: Preparing for the first release
Manuel Mall a écrit : As the project hasn't done a release for a long time and especially no release of the new codebase we should test probably a bit more extensively than usual that the distribution builds actually are working and don't contain any 'cheap' errors. To that effect I have build binary and source distributions from the current svn and made them available for download from http://people.apache.org/~manuel/fop/disttest. In the top level directory are the source and the java 1.4+ binary distributions. In the java1.3.1 directory are only binary distributions. I'm on a Debian GNU/Linux environment with both java 1.4.2 and java 1.5. I have encountered no particular problem by running the binary version on a few sample fo files. The source distribution also seems to build and run fine. My 2 cents... Vincent
Re: Preparing for the first release - Examples
On 13.11.2005 19:53:32 Andreas L Delmelle wrote: > On Nov 13, 2005, at 18:00, Andreas L Delmelle wrote: > > > On Nov 13, 2005, at 17:36, Jeremias Maerki wrote: > > > > > >> The other question is: > >> What's the "box"? The containing area? > > > > Yep. I think this is answered in the definition of absolute- > > position="absolute": > > > > First, for the value of "absolute" > > "The area's position (and possibly size) is specified with the > > 'left', 'right', 'top', and 'bottom' properties. These properties > > specify offsets with respect to the area's containing area." > > In XSL-FO 1.1, the wording is slightly different BTW: > "These properties specify offsets with respect to the area's nearest > ancestor reference area." > > Does this make it simpler or more difficult? Wouldn't this mean that > I wasn't confused at all? And me, neither. My checks wouldn't be so wrong. But it means that the spec changed in a backwards-incompatible way. And we will have to change the meaning/implementation of the "top" property. Right now it offsets the b-c relative to the top of the containing box, AFAICS. Well, I'll leave this for after the release. Thanks for digging into the 1.1 draft! Jeremias Maerki
Re: Preparing for the first release
Manuel Mall schrieb: [..] >>IMHO there should be a changes document (as part of the >>distribution), at least starting after the 1.0 release. > > Yes there should - but for now: Just remove CHANGES and update README? I'd say yes. -- Christian
Re: Preparing for the first release
On Mon, 14 Nov 2005 09:56 am, Christian Geisert wrote: > Manuel Mall schrieb: > > [..] > > >>No hurry, I just meant to prepare everything (still problems with > >>forrest) - and Manuel is already doing a lot of the work - the > >> actual release isn't that much work and can be done later ... > > > > Sorry, didn't intend to steal your work Christian. > > Heh, I like it when others do my work ;-) > > [..] > > > BTW, I am aware the the files CHANGES and README in the top level > > of all distributions are outdated and need revising before a proper > > release. > > The CHANGES file was used only in the maintenance branch, for the > trunk there was a status.xml which got nicely rendered into the > website but this has been deleted sometime ago and then (some) > changes where documented on the wiki. > > IMHO there should be a changes document (as part of the > distribution), at least starting after the 1.0 release. Yes there should - but for now: Just remove CHANGES and update README? Manuel
Re: Preparing for the first release
Manuel Mall schrieb: [..] >>No hurry, I just meant to prepare everything (still problems with >>forrest) - and Manuel is already doing a lot of the work - the actual >>release isn't that much work and can be done later ... > > Sorry, didn't intend to steal your work Christian. Heh, I like it when others do my work ;-) [..] > BTW, I am aware the the files CHANGES and README in the top level of all > distributions are outdated and need revising before a proper release. The CHANGES file was used only in the maintenance branch, for the trunk there was a status.xml which got nicely rendered into the website but this has been deleted sometime ago and then (some) changes where documented on the wiki. IMHO there should be a changes document (as part of the distribution), at least starting after the 1.0 release. -- Christian
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 18:00, Andreas L Delmelle wrote: On Nov 13, 2005, at 17:36, Jeremias Maerki wrote: The other question is: What's the "box"? The containing area? Yep. I think this is answered in the definition of absolute- position="absolute": First, for the value of "absolute" "The area's position (and possibly size) is specified with the 'left', 'right', 'top', and 'bottom' properties. These properties specify offsets with respect to the area's containing area." In XSL-FO 1.1, the wording is slightly different BTW: "These properties specify offsets with respect to the area's nearest ancestor reference area." Does this make it simpler or more difficult? Wouldn't this mean that I wasn't confused at all? Cheers, Andreas
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 18:36, Jeremias Maerki wrote: On 13.11.2005 18:26:24 Andreas L Delmelle wrote: Ouch indeed! :-/ Seems I'm confusing: "the area generated is a descendant of the page-area" This only tells where the area generated for the b-c is to be added to. It has little to do with the issue here. with "the page-area is the 'containing area' of the generated area" Where does this come from? I haven't found it in the spec. It's not in the Rec. That was exactly the source of my confusion. I took the first to mean the latter, so: the parent->child relationship between areas in the area tree would reflect the relationship of containing->contained area. My mistake. Sorry for being a bit unclear... Cheers, Andreas
Re: Preparing for the first release - Examples
On 13.11.2005 18:26:24 Andreas L Delmelle wrote: > On Nov 13, 2005, at 18:17, Jeremias Maerki wrote: > > > > > I don't think so, if we're talking about the area. Assume a longer > > block > > with several lines which also contains an absolutely positioned b- > > c. If > > there's a page break in the middle of this block and the vertical size > > of the b-c is determined using the "top" and "bottom" properties, the > > size of the b-c would be different depending on the position of the > > break, since the box would be the area (or probably more accurate: the > > first area generated by the formatting object) and depending on the > > break's position this area may be bigger or smaller. > > Ouch indeed! :-/ > Seems I'm confusing: > "the area generated is a descendant of the page-area" This only tells where the area generated for the b-c is to be added to. It has little to do with the issue here. > with > "the page-area is the 'containing area' of the generated area" Where does this come from? I haven't found it in the spec. > Or not? Sorry, but I'm not sure what you mean here. Jeremias Maerki
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 18:17, Jeremias Maerki wrote: I don't think so, if we're talking about the area. Assume a longer block with several lines which also contains an absolutely positioned b- c. If there's a page break in the middle of this block and the vertical size of the b-c is determined using the "top" and "bottom" properties, the size of the b-c would be different depending on the position of the break, since the box would be the area (or probably more accurate: the first area generated by the formatting object) and depending on the break's position this area may be bigger or smaller. Ouch indeed! :-/ Seems I'm confusing: "the area generated is a descendant of the page-area" with "the page-area is the 'containing area' of the generated area" Or not? Cheers, Andreas
Re: Preparing for the first release - Examples
On 13.11.2005 18:00:33 Andreas L Delmelle wrote: > On Nov 13, 2005, at 17:36, Jeremias Maerki wrote: > > > > The other question is: > > What's the "box"? The containing area? > > Yep. I think this is answered in the definition of absolute- > position="absolute": > > First, for the value of "absolute" > "The area's position (and possibly size) is specified with the > 'left', 'right', 'top', and 'bottom' properties. These properties > specify offsets with respect to the area's containing area." > > And a bit further on (specific for paged presentations) > "The area generated is a descendant of the page-area where the first > area from the object would have been placed had the object had > absolute-position='auto' specified." > > > If yes, that means that the block-container might look different > > depending on break decisions. > > That may indeed be the case, but IMO, only when top/bottom/left/right > are specified as percentages. If they're just lengths (mm, in or pt) > the dimensions of the block-container would obviously remain > constant, regardless of which page they eventually end up on. I don't think so, if we're talking about the area. Assume a longer block with several lines which also contains an absolutely positioned b-c. If there's a page break in the middle of this block and the vertical size of the b-c is determined using the "top" and "bottom" properties, the size of the b-c would be different depending on the position of the break, since the box would be the area (or probably more accurate: the first area generated by the formatting object) and depending on the break's position this area may be bigger or smaller. Jeremias Maerki
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 17:36, Jeremias Maerki wrote: The other question is: What's the "box"? The containing area? Yep. I think this is answered in the definition of absolute- position="absolute": First, for the value of "absolute" "The area's position (and possibly size) is specified with the 'left', 'right', 'top', and 'bottom' properties. These properties specify offsets with respect to the area's containing area." And a bit further on (specific for paged presentations) "The area generated is a descendant of the page-area where the first area from the object would have been placed had the object had absolute-position='auto' specified." If yes, that means that the block-container might look different depending on break decisions. That may indeed be the case, but IMO, only when top/bottom/left/right are specified as percentages. If they're just lengths (mm, in or pt) the dimensions of the block-container would obviously remain constant, regardless of which page they eventually end up on. Cheers, Andreas
Re: Preparing for the first release - Examples
Right, it looks like I wrote the checks and some of the code in terms of the containing reference area, not the containing box. It's probably best to disable the warnings for now and to look at how to fix the behaviour after the release, because it looks like a potentially bigger problem. The size of the containing box is only known after it is fully through with all its children. That means that the layout of absolutely positioned block-containers has to be deferred until after thatunless I again misunderstood something. The other question is: What's the "box"? The containing area? If yes, that means that the block-container might look different depending on break decisions. I get a head-ache when I start thinking about it. On 13.11.2005 16:45:26 Andreas L Delmelle wrote: > On Nov 13, 2005, at 16:14, Andreas L Delmelle wrote: > > >> So, the values of these properties need to be changed to reflect > >> the reference-orientation specified on the block-container in > >> question... > > > > FWIW: tried to change these, but I'm still getting warnings... No > > idea yet on how to proceed next. > > Been playing around some more with this example, and one of the > warnings is caused by the block-container that has default reference- > orientation, so there definitely seems to be something buggy in the > interpretation of absolute coordinates. It seems they are interpreted > relative to each other (? remote guess). > > Example: > For a nominal available height of 742000mpt, the maximum value of > "bottom" may at most be "342pt" according to the current implementation. > 342pt = 742pt (available) - 400pt (value for top) > > I'm still not sure. Does this mean that currently, the b-c is > considered to be its own containing block? > > Cheers, > > Andreas Jeremias Maerki
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 16:14, Andreas L Delmelle wrote: So, the values of these properties need to be changed to reflect the reference-orientation specified on the block-container in question... FWIW: tried to change these, but I'm still getting warnings... No idea yet on how to proceed next. Been playing around some more with this example, and one of the warnings is caused by the block-container that has default reference- orientation, so there definitely seems to be something buggy in the interpretation of absolute coordinates. It seems they are interpreted relative to each other (? remote guess). Example: For a nominal available height of 742000mpt, the maximum value of "bottom" may at most be "342pt" according to the current implementation. 342pt = 742pt (available) - 400pt (value for top) I'm still not sure. Does this mean that currently, the b-c is considered to be its own containing block? Cheers, Andreas
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 15:21, Andreas L Delmelle wrote: [Manuel] 1. The blockcontainer.fo examples spits out heaps of warnings. I have not looked into those. May be someone with a better understanding of this whole area could have a look please. Had a very quick look, and IIC, this is related to the fact that the reference-orientation is set to 180 (meaning upside-down), and 'top' is being interpreted as 'bottom' (and vice versa). Same for 'left' and 'right'. So, the values of these properties need to be changed to reflect the reference-orientation specified on the block-container in question... FWIW: tried to change these, but I'm still getting warnings... No idea yet on how to proceed next. Cheers, Andreas
Re: Preparing for the first release - Examples
On Nov 13, 2005, at 12:37, Manuel Mall wrote: Hi Manuel, I went through the examples in examples/basic/fo, that is the examples processed by: ant examples and updated them to better match 0.90 and to eliminate most warnings. Thanks a lot for taking care of that. While doing so I noticed a few things: 1. The blockcontainer.fo examples spits out heaps of warnings. I have not looked into those. May be someone with a better understanding of this whole area could have a look please. Had a very quick look, and IIC, this is related to the fact that the reference-orientation is set to 180 (meaning upside-down), and 'top' is being interpreted as 'bottom' (and vice versa). Same for 'left' and 'right'. IMO, this interpretation seems to be correct. See XSL-FO Rec 1.0 7.20.3 reference-orientation: "The 'reference-orientation' property is applied only on formatting objects that establish a reference-area. Each value of 'reference- orientation' sets the absolute direction for 'top', 'left', 'bottom', and 'right';" So, the values of these properties need to be changed to reflect the reference-orientation specified on the block-container in question... Do the other team-members agree with this assessment? Cheers, Andreas
Preparing for the first release - Examples
I went through the examples in examples/basic/fo, that is the examples processed by: ant examples and updated them to better match 0.90 and to eliminate most warnings. While doing so I noticed a few things: 1. The blockcontainer.fo examples spits out heaps of warnings. I have not looked into those. May be someone with a better understanding of this whole area could have a look please. 2. In border.fo the main central table has a yellow border. But it doesn't render correctly. However, borders on other tables (see table.fo) work fine. There must be something wrong in the context of this specific example. 3. In leader.fo the use-content leaders don't render. In our testcases use-content works. I'll look into this one. As these examples are exposed to the 'downloading public' I would appreciate if others could review them as well. Just build the latest FOP version and run 'ant examples' and check the generated pdfs in build/examples and report anything unusual please. Thanks Manuel
Re: Preparing for the first release
On Sat, 12 Nov 2005 10:10 pm, Christian Geisert wrote: > Jeremias Maerki schrieb: > > Cool, thanks! Let's hope I can squeeze everything in until then. > > No hurry, I just meant to prepare everything (still problems with > forrest) - and Manuel is already doing a lot of the work - the actual > release isn't that much work and can be done later ... > Sorry, didn't intend to steal your work Christian. As the project hasn't done a release for a long time and especially no release of the new codebase we should test probably a bit more extensively than usual that the distribution builds actually are working and don't contain any 'cheap' errors. To that effect I have build binary and source distributions from the current svn and made them available for download from http://people.apache.org/~manuel/fop/disttest. In the top level directory are the source and the java 1.4+ binary distributions. In the java1.3.1 directory are only binary distributions. NOTE / DISCLAIMER: These are test builds only to verify our build procedures and DO NOT constitute an official or sanctioned or approved release from the FOP project My usual development / test environment is RedHat Linux ES 3 with Java 1.5. If you have a different environment please grab one or more of the distributions and check them out and leave feedback on this list (even if its all good please). When I say 'check them out' I mean: does the distribution work, are all required files there, does fop run 'out of the box', ...? For a source distribution: does fop build without problems...? What I don't mean is to check FOP's XSL-FO compliance or to try and find bugs in FOP itself. While that is also very useful I am asking here for help with verifying the distribution build mechanism. BTW, I am aware the the files CHANGES and README in the top level of all distributions are outdated and need revising before a proper release. > Christian Manuel
Re: Preparing for the first release
Jeremias Maerki schrieb: Cool, thanks! Let's hope I can squeeze everything in until then. No hurry, I just meant to prepare everything (still problems with forrest) - and Manuel is already doing a lot of the work - the actual release isn't that much work and can be done later ... Christian
Re: Preparing for the first release
Just for the record - The current version of fop (r332584) builds and passes all JUnit tests under RedHat ES 3 for: jdk1.3.1_16 (1.3.1_16-b06) j2sdk1.4.2_06 (1.4.2_06-b03) java-1.5.0 (1.5.0_03-b07) Manuel
Re: Preparing for the first release
Cool, thanks! Let's hope I can squeeze everything in until then. On 11.11.2005 12:03:52 Christian Geisert wrote: > Jeremias Maerki schrieb: > > [..] > > > Christian, are you available for managing the actual release (build plus > > deployment)? > > Yes, should have some time on the weekend. > > -- > Christian Jeremias Maerki
Re: Preparing for the first release
Jeremias Maerki schrieb: [..] > Christian, are you available for managing the actual release (build plus > deployment)? Yes, should have some time on the weekend. -- Christian
Re: Preparing for the first release
Took the liberty to actually do this and followed Jeremias advice to KISS. The new directory layout is just: test |---layoutengine |-- standard-testcases |-- hyphenation-testcases To select a group set the fop.layoutengine.testset system property to either "standard" or "hyphenation". It defaults to "standard". I also modified the build.xml to not stop on any Junit errors or failures. Instead Ant properties are set and the junit target will print a BIG notice that something went wrong or was skipped if one of those properties is set. As the junit target is pretty much the last target usually run its easy to visually check the result and be alerted if something went wrong even if the actual error has scrolled off the screen. I hope this will address some of the concerns raised in http://marc.theaimsgroup.com/?t=11291489064&r=1&w=2. I am sure all this can be further improved upon but I hope useability has moved at least a little bit forward. Manuel On Thu, 10 Nov 2005 06:00 pm, Jeremias Maerki wrote: > As I already told Manuel via IM, I agree with this, although I don't > quite see the benefit in the "bugs" directory. But I guess it won't > hurt, either. > > On 10.11.2005 08:59:55 Manuel Mall wrote: > > On Wed, 9 Nov 2005 10:05 pm, Jeremias Maerki wrote: > > > > > > > Are there any objections on doing the first release within the > > > next few days? Is there anything that needs to be done which is > > > not on the release plan [1] besides the sandbox proposal? Does > > > anyone see any outstanding legal issues preventing the release as > > > is? Anything else? > > > > I think before the release we need to do something about this: > > http://marc.theaimsgroup.com/?t=11291489064&r=1&w=2 > > > > However, I don't feel like re-opening the discussion as it appeared > > rather pointless to me. Here is what I suggest to do as a quick fix > > to the problem: > > > > 1. Instead of having 1 directory (test/layoutengine/testcases) > > containing all layout engine tests split them up according to the > > resources they require: > > > > test > > |---layoutengine > > |-- default (our normal set of layoutengine > > testcases which do not require any special resources) |-- > > hyphenation (those testcases which depend on hyphenation resources) > > |-- fonts (testcases which depend on font > > resources - none yet so this directory will > > not really exist) > > |-- bugs (BugZilla related testcases - I see > > those only as temporary as these should be integrated > > into the above once fixed) > > > > Note: The disabled-testcases.txt file will remain in > > test/layoutengine and apply to all subdirectories (keep it simple). > > > > 2. Create separate targets in build.xml for these. > > > > 3. The normal build will only include the targets default and > > hyphenation (and fonts). hyphenation (and fonts) will be skipped > > (with a warning) if the resources are not available. > > > > I know we could (and should) control all this by adding to the > > testcase XML, because ideally each testcase should declare the > > resources it wants (and don't wants) and the testcase engine should > > check/setup the environment accordingly. But I want to get the > > release out and the above can be done fairly quickly. > > > > WDYT > > > > Manuel > > > > > > > > > Jeremias Maerki > > Jeremias Maerki
Re: Preparing for the first release
As I already told Manuel via IM, I agree with this, although I don't quite see the benefit in the "bugs" directory. But I guess it won't hurt, either. On 10.11.2005 08:59:55 Manuel Mall wrote: > On Wed, 9 Nov 2005 10:05 pm, Jeremias Maerki wrote: > > > Are there any objections on doing the first release within the next > > few days? Is there anything that needs to be done which is not on the > > release plan [1] besides the sandbox proposal? Does anyone see any > > outstanding legal issues preventing the release as is? Anything else? > > > I think before the release we need to do something about this: > http://marc.theaimsgroup.com/?t=11291489064&r=1&w=2 > > However, I don't feel like re-opening the discussion as it appeared > rather pointless to me. Here is what I suggest to do as a quick fix to > the problem: > > 1. Instead of having 1 directory (test/layoutengine/testcases) > containing all layout engine tests split them up according to the > resources they require: > > test > |---layoutengine > |-- default (our normal set of layoutengine testcases > which do not require any special resources) > |-- hyphenation (those testcases which depend on > hyphenation resources) > |-- fonts (testcases which depend on font > resources - none yet so this directory will > not really exist) > |-- bugs (BugZilla related testcases - I see those > only as temporary as these should be integrated > into the above once fixed) > > Note: The disabled-testcases.txt file will remain in test/layoutengine > and apply to all subdirectories (keep it simple). > > 2. Create separate targets in build.xml for these. > > 3. The normal build will only include the targets default and > hyphenation (and fonts). hyphenation (and fonts) will be skipped (with a > warning) if the resources are not available. > > I know we could (and should) control all this by adding to the testcase > XML, because ideally each testcase should declare the resources it wants > (and don't wants) and the testcase engine should check/setup the > environment accordingly. But I want to get the release out and the above > can be done fairly quickly. > > WDYT > > Manuel > > > > Jeremias Maerki Jeremias Maerki
Re: Preparing for the first release
On Wed, 9 Nov 2005 10:05 pm, Jeremias Maerki wrote: > Are there any objections on doing the first release within the next > few days? Is there anything that needs to be done which is not on the > release plan [1] besides the sandbox proposal? Does anyone see any > outstanding legal issues preventing the release as is? Anything else? > I think before the release we need to do something about this: http://marc.theaimsgroup.com/?t=11291489064&r=1&w=2 However, I don't feel like re-opening the discussion as it appeared rather pointless to me. Here is what I suggest to do as a quick fix to the problem: 1. Instead of having 1 directory (test/layoutengine/testcases) containing all layout engine tests split them up according to the resources they require: test |---layoutengine |-- default (our normal set of layoutengine testcases which do not require any special resources) |-- hyphenation (those testcases which depend on hyphenation resources) |-- fonts (testcases which depend on font resources - none yet so this directory will not really exist) |-- bugs (BugZilla related testcases - I see those only as temporary as these should be integrated into the above once fixed) Note: The disabled-testcases.txt file will remain in test/layoutengine and apply to all subdirectories (keep it simple). 2. Create separate targets in build.xml for these. 3. The normal build will only include the targets default and hyphenation (and fonts). hyphenation (and fonts) will be skipped (with a warning) if the resources are not available. I know we could (and should) control all this by adding to the testcase XML, because ideally each testcase should declare the resources it wants (and don't wants) and the testcase engine should check/setup the environment accordingly. But I want to get the release out and the above can be done fairly quickly. WDYT Manuel > Jeremias Maerki
Preparing for the first release
The time has come and we need to push FOP out to the public again, at least IMO. I'm currently seeing through the last few things (patches, docs, bugs etc.). Are there any objections on doing the first release within the next few days? Is there anything that needs to be done which is not on the release plan [1] besides the sandbox proposal? Does anyone see any outstanding legal issues preventing the release as is? Anything else? I think I can live with the current API for now (after my imminent changes as announced) although I would not see it as fixed for the first production-ready release, yet. I will want a big disclaimer about the API stability in the release notes. Remember the first preview release doesn't need to be perfect. It should do something reasonable and not crash with every second document. But many people will only start playing with the new code when we release it. Christian, are you available for managing the actual release (build plus deployment)? [1] http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR Jeremias Maerki
