Sorry, an unwanted key stroke...

2012/7/2 Pascal Sancho <psancho....@gmail.com>:
> Mehdi,
>
> I speak about post 1.1RC1.
> Your merge will be against the trunk.
> What about the 1.1RC2 or 1.1 final?
> In the current usage, *all* FOP releases are tagged directly from
> trunk (via a branch that is only to set FOP version and lib
> dependencies).
> So, every further RC or final releases are planed to be ma
made from trunk, including further changes.
That will need further tests and RC, so no final release until...?

Perhaps we have to decide now what will be in 1.1 final release.

> 2012/7/2 mehdi houshmand <med1...@gmail.com>:
>> Hi Pascal,
>>
>> I won't be merging this into anything other than trunk. Sorry, maybe I
>> should have made that more explicit.
>>
>> Mehdi
>>
>>
>> On 2 July 2012 12:32, Pascal Sancho <psancho....@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> +1 for merging it to trunk.
>>>
>>> That said, I'm a little puzzled with the release process.
>>> In my mind, a RC should come before a production release, freezing all
>>> features.
>>> Only bugfix should be permitted on RC.
>>> Adding new feature to RC2 is a precedent that allows to add a new
>>> feature after each RC, witch need to release a new... RC, etc.
>>> I humbly suggest that the release process start with a 1.1 branch,
>>> from witch RCx and final release will be tagged, that should allow to
>>> continue merging branches onto trunk without any interaction on branch
>>> release.
>>> WDYT?
>>>
>>> 2012/7/2 Chris Bowditch <bowditch_ch...@hotmail.com>:
>>> > On 26/06/2012 15:39, mehdi houshmand wrote:
>>> >>
>>> >> Sorry, added "[VOTE]" to subject line... My bad
>>> >
>>> >
>>> > +1 from me. Good work Mehdi and Pete.
>>> >
>>> > Chris
>>> >
>>> >
>>> >>
>>> >> On 26 June 2012 15:38, mehdi houshmand <med1...@gmail.com
>>> >> <mailto:med1...@gmail.com>> wrote:
>>> >>
>>> >>     Hi All,
>>> >>
>>> >>     I think we've got to the stage in the URI unification branch where
>>> >>     it's ready to be merged into trunk (not into 1.1RC1). I know there
>>> >>     have been proponents against the inclusion of this feature and/or
>>> >>     those who are concerned the wider implications as it means FOP has
>>> >>     fewer contingency methods when attempting file access. I'll try
>>> >>     and explain how we've addressed those concerns as well as some of
>>> >>     the code improvements we've made.
>>> >>
>>> >>     - Syntactic URI fall-back mechanisms - if a URI is syntactically
>>> >>     erroneous i.e. contains white-space, "\" instead of "/", we do
>>> >>     some validation on to mitigate some of the common mistakes.
>>> >>     However, we don't allow for falling back to 'new File(".")' or
>>> >>     "new URL(...).openStream()" since these can obviously cause
>>> >>     clashes in a highly parallelised multi-tenant environment.
>>> >>
>>> >>     - Single FOP conf parse - Previously the renderer specific regions
>>> >>     of the FOP conf was being parsed on every run. This is costly to
>>> >>     performance for the obvious reason, but as well as this, it meant
>>> >>     that font auto-detection was having to be executed on every run.
>>> >>     The font-caching was created to mitigate some of those performance
>>> >>     costs, however, caching the FOP conf makes much more sense. It
>>> >>     means we can get rid of the font-caching and don't have to to
>>> >>     worry about performance but it also allowed to do a lot of clean
>>> >>     up in the configuration packages. The renderer specific config is
>>> >>     also lazy loaded such that it is only parsed when the respective
>>> >>     renderer is invoked, mitigating the one-off cost of parsing that
>>> >>     config.
>>> >>
>>> >>     - The environment profile - We've created an environment profile
>>> >>     that abstracts the system in which FOP is invoked. This allows us
>>> >>     to programmatically enforce restrictions to, for example,
>>> >>     font-caching and auto-detection since users may want to control
>>> >>     this behaviour for any number of reasons.
>>> >>
>>> >>     - Improved URI handling - because the URI resolution has been
>>> >>     unified to a couple of classes, the behaviour is much easier for
>>> >>     users to understand.
>>> >>
>>> >>     - Consistent base directories - We've tried to ensure that base
>>> >>     directories are consistent with FOP previously, the <base> and
>>> >>     <font-base> still work as previously.
>>> >>
>>> >>     There are however some outstanding TODOs that need to be
>>> >>     addressed, however, though they are important, they don't need to
>>> >>     be all merged in at the same time. I will be working on these and
>>> >>     keep the community updated:
>>> >>
>>> >>     TODOs//
>>> >>
>>> >>     - XGC and libraries - This is most likely the next project, we
>>> >>     need to do the same in the XGC project and look at some of FOPs
>>> >>     dependencies (Batik too!). The plan will be to move all the
>>> >>     resource resolver classes to XGC since that is the parent library
>>> >>     so that they can be used though out the XMLGraphics libraries.
>>> >>
>>> >>     - Improved MIME type resolution - currently FOP's file-type
>>> >>     (file-MIME-type) is performed in-situ using file-name endings.
>>> >>     This is, while working perfectly fine on a desktop environment,
>>> >>     would be less than desirable if file-names were just hashes or the
>>> >>     like from a virtual file-system. We need to give the user the
>>> >>     flexibility to define a file MIME type without forcing them to put
>>> >>     the file-ending in the URI.
>>> >>
>>> >>     - Default handling in some of the Configurators - We have improved
>>> >>     the mechanism that handles default values in the configuration as
>>> >>     well as config injected via RendererOptions (on the FOUserAgent)
>>> >>     and the FOP conf for PDF. However, time constraints haven't
>>> >>     allowed us to do the same for PS and AFP, which would be nice to
>>> >>     do. This isn't of utmost priority, but it would be nice to not
>>> >>     have the "if (x != null)" peppered around the source
>>> >>
>>> >>     Sorry for the long email, I just thought it'd be a good time to
>>> >>     expose some of the work we've been doing,
>>> >>
>>> >>     Mehdi
>>> >>
>>> >>
>>> >>     P.S. More information can be found wiki under the developers
>>> >>     section, it's currently down so I can't post a link.


-- 
pascal

Reply via email to