On 2/13/12 5:48 PM, Pedro Giffuni wrote:
On 02/13/12 11:24, Rob Weir wrote:
On Sun, Feb 12, 2012 at 8:34 PM, Pedro Giffuni<p...@apache.org> wrote:
Hmm...

On 02/12/12 17:06, Rob Weir wrote:
...

Anyone wants to play a bit with a patch? Alternatively we could just
leave
things as they are and drop StaX out of the distribution after
3.4-Release.
+1 for changing after 3.4.


Rob's message arrived *after* I committed the update.
It's a low risk update though; it helps a bit with the license
clearance issues and the instructions for using the prebuilt
distribution were just too outdated so let's wait to see what
the buildbot thinks about it.

Low risk, but not zero. At the very least, since we've already
started a formal QA pass for 3.4, it would be great if any changes
made from now on mentioned what, if anything, should be retested.
This probably also means that changes should come with a BZ issue
where such information is recorded.

In my build, and in the buildbots so far, the impact has been
zero and I am ready to revert if there is any need, but I see
your point.

I think we should still update some components: the security
stuff I mentioned earlier and apache-commons. I can open
bugzilla items for those. FWIW, I had a look at updating icc
and Lucene but those are very high risk IMHO.
I'm open to arguments that we're not at that point in the 3.4 release
cycle yet. But I think at some point we want to engage that level of
change discipline.
We should go further indeed: when we are ready for a release
we should call a code freeze: I suggest that should be called right
after the neon replacement is finished. We should probably be
thinking on branching after that too.

I agree that we should move into a code freeze mode as soon as we have the neon replacement. But in general I would strongly suggest that we move this kind of changes after the release and focus on bug fixing at the moment. Our primary goal should be really to get the 3.4 finished.

Juergen


Pedro.


-Rob

FWIW, I am more worried about some other updates that
should be done for security reasons; nss and libxmlsec,
but I have currently no plans to touch those.

Cheers,

Pedro.



Reply via email to