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 Vincent Hennebert <vh...@gmail.com> on 2009/08/05 12:07:55 UTC
Re: Status report for August 2009
Hi Simon,
The report looks good. Just a thing about the ChangingIPD hack: actually
it is still undecided whether it should be merged back to Trunk or not.
My main concern about that is that it will get in the way when
implementing the new approach. I will basically have to start with
reverting all the changes made for the hack.
My idea was to actively maintain the branch in sync with the Trunk.
Releases could then be made from the branch. But this may actually turn
out to be more work than reverting all the changes in one go. Plus it
has been mentioned to me that this may create difficulties for users who
regularly take snapshots of the Trunk (the branch will always lag
a little bit behind).
Any opinion about this is welcome. Meanwhile, I’ll modify the status
report.
Thanks,
Vincent
Simon Pepping wrote:
> The August report needs to be submitted by 16 August. I've
> written an initial draft. Please add/fix/update/improve until Friday
> 15 August night (CET).
>
> http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2009
>
> I tried to get some numbers on activity. I have come up with the
> activity on the mailing lists during May, June and July, as can be
> derived from the Apache archives:
>
> fop commits: 88
> batik commits: 5
> xmlgraphics commits: 15 (minus deployment of the web site)
> fop-dev: 311
> fop-users: 610
> batik-dev: 112
> batik-users: 243
> general: 48
>
> Nice graphs can be seen at markmail: http://fop.markmail.org/,
> http://fop-dev.markmail.org/, http://fop-user.markmail.org/,
> http://batik.markmail.org/, http://batik-dev.markmail.org/,
> http://batik-user.markmail.org/,
> http://xmlgraphics.markmail.org/search/?q=#query:list%3Aorg.apache.xmlgraphics.general+page:1+state:facets
>
> Regards, Simon
>
Re: Status report for August 2009
Posted by Chris Bowditch <bo...@hotmail.com>.
Vincent Hennebert wrote:
> Hi Simon,
Hi Simon, Vincent,
>
> The report looks good. Just a thing about the ChangingIPD hack: actually
> it is still undecided whether it should be merged back to Trunk or not.
>
> My main concern about that is that it will get in the way when
> implementing the new approach. I will basically have to start with
> reverting all the changes made for the hack.
>
> My idea was to actively maintain the branch in sync with the Trunk.
> Releases could then be made from the branch. But this may actually turn
> out to be more work than reverting all the changes in one go. Plus it
> has been mentioned to me that this may create difficulties for users who
> regularly take snapshots of the Trunk (the branch will always lag
> a little bit behind).
>
> Any opinion about this is welcome. Meanwhile, I’ll modify the status
> report.
Thanks for bringing this up Vincent. I am a little reluctant to be
working off a branch as we regularly take build snapshots from trunk.
This creates a lot of extra work keeping the branch in sync.
I think we all acknowledge that the changing IPD hack is just that and
therefore code quality may be sub optimal. However, since Vincent is
working on a totally new layout engine then we expect this code to be
replaced a year or so down the line anyway. Therefore if the only reason
for not putting this change into trunk is to save effort at the point
when the new layout algorithm is introduced then I think this hack
should be merged with trunk. This is because it will be more time
consuming to do a 100 or so merges over a 1-2 year period than to remove
changes from trunk in a one time exercise.
Thanks,
Chris
>
> Thanks,
> Vincent
>
>
> Simon Pepping wrote:
>
>>The August report needs to be submitted by 16 August. I've
>>written an initial draft. Please add/fix/update/improve until Friday
>>15 August night (CET).
>>
>>http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2009
>>
>>I tried to get some numbers on activity. I have come up with the
>>activity on the mailing lists during May, June and July, as can be
>>derived from the Apache archives:
>>
>>fop commits: 88
>>batik commits: 5
>>xmlgraphics commits: 15 (minus deployment of the web site)
>>fop-dev: 311
>>fop-users: 610
>>batik-dev: 112
>>batik-users: 243
>>general: 48
>>
>>Nice graphs can be seen at markmail: http://fop.markmail.org/,
>>http://fop-dev.markmail.org/, http://fop-user.markmail.org/,
>>http://batik.markmail.org/, http://batik-dev.markmail.org/,
>>http://batik-user.markmail.org/,
>>http://xmlgraphics.markmail.org/search/?q=#query:list%3Aorg.apache.xmlgraphics.general+page:1+state:facets
>>
>>Regards, Simon
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status report for August 2009
Posted by Chris Bowditch <bo...@hotmail.com>.
Vincent Hennebert wrote:
> Hi Simon,
Hi Simon, Vincent,
>
> The report looks good. Just a thing about the ChangingIPD hack: actually
> it is still undecided whether it should be merged back to Trunk or not.
>
> My main concern about that is that it will get in the way when
> implementing the new approach. I will basically have to start with
> reverting all the changes made for the hack.
>
> My idea was to actively maintain the branch in sync with the Trunk.
> Releases could then be made from the branch. But this may actually turn
> out to be more work than reverting all the changes in one go. Plus it
> has been mentioned to me that this may create difficulties for users who
> regularly take snapshots of the Trunk (the branch will always lag
> a little bit behind).
>
> Any opinion about this is welcome. Meanwhile, I’ll modify the status
> report.
Thanks for bringing this up Vincent. I am a little reluctant to be
working off a branch as we regularly take build snapshots from trunk.
This creates a lot of extra work keeping the branch in sync.
I think we all acknowledge that the changing IPD hack is just that and
therefore code quality may be sub optimal. However, since Vincent is
working on a totally new layout engine then we expect this code to be
replaced a year or so down the line anyway. Therefore if the only reason
for not putting this change into trunk is to save effort at the point
when the new layout algorithm is introduced then I think this hack
should be merged with trunk. This is because it will be more time
consuming to do a 100 or so merges over a 1-2 year period than to remove
changes from trunk in a one time exercise.
Thanks,
Chris
>
> Thanks,
> Vincent
>
>
> Simon Pepping wrote:
>
>>The August report needs to be submitted by 16 August. I've
>>written an initial draft. Please add/fix/update/improve until Friday
>>15 August night (CET).
>>
>>http://wiki.apache.org/xmlgraphics/StatusReports/StatusReportForMay2009
>>
>>I tried to get some numbers on activity. I have come up with the
>>activity on the mailing lists during May, June and July, as can be
>>derived from the Apache archives:
>>
>>fop commits: 88
>>batik commits: 5
>>xmlgraphics commits: 15 (minus deployment of the web site)
>>fop-dev: 311
>>fop-users: 610
>>batik-dev: 112
>>batik-users: 243
>>general: 48
>>
>>Nice graphs can be seen at markmail: http://fop.markmail.org/,
>>http://fop-dev.markmail.org/, http://fop-user.markmail.org/,
>>http://batik.markmail.org/, http://batik-dev.markmail.org/,
>>http://batik-user.markmail.org/,
>>http://xmlgraphics.markmail.org/search/?q=#query:list%3Aorg.apache.xmlgraphics.general+page:1+state:facets
>>
>>Regards, Simon
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
>
Re: Status report for August 2009
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Aug 05, 2009 at 11:37:34AM +0100, Chris Bowditch wrote:
> Vincent Hennebert wrote:
> >Hi Simon,
>
> Hi Simon, Vincent,
>
> >
> >The report looks good. Just a thing about the ChangingIPD hack: actually
> >it is still undecided whether it should be merged back to Trunk or not.
> >
> >My main concern about that is that it will get in the way when
> >implementing the new approach. I will basically have to start with
> >reverting all the changes made for the hack.
> >
> >My idea was to actively maintain the branch in sync with the Trunk.
> >Releases could then be made from the branch. But this may actually turn
> >out to be more work than reverting all the changes in one go. Plus it
> >has been mentioned to me that this may create difficulties for users who
> >regularly take snapshots of the Trunk (the branch will always lag
> >a little bit behind).
> >
> >Any opinion about this is welcome. Meanwhile, I???ll modify the status
> >report.
>
> Thanks for bringing this up Vincent. I am a little reluctant to be
> working off a branch as we regularly take build snapshots from
> trunk. This creates a lot of extra work keeping the branch in sync.
>
> I think we all acknowledge that the changing IPD hack is just that
> and therefore code quality may be sub optimal. However, since
> Vincent is working on a totally new layout engine then we expect
> this code to be replaced a year or so down the line anyway.
> Therefore if the only reason for not putting this change into trunk
> is to save effort at the point when the new layout algorithm is
> introduced then I think this hack should be merged with trunk. This
> is because it will be more time consuming to do a 100 or so merges
> over a 1-2 year period than to remove changes from trunk in a one
> time exercise.
I appreciate your point of view. I expect you will announce your
intention to merge the changing IPD branch with trunk when the time is
there. Then it is a good time to hear everyone's opinion.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu