For me, the build would contain
fixes that product teams from different companies and different developers
felt were needed for a 3.4.3 build (if there was one, but there wasn't).
It would be totally untested. That's bad but we could say this
1) Consumers of the build would need
to be ok with this and I suspect that they would not. For example,
you care about one small bug in JDT but you risk a bunch of unrelated code
from SWT that could break your product completely.
2) What people were running in the field
would depend on when the build was made. How could bugs be reported
against it or when something breaks, how can we know what the person is
<eclipse@xxxxxxxxxxxxxx> Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
03/11/2009 06:42 PM
Please respond to
[eclipse-pmc] post 3.4.2 builds
In today's architecture call it was suggested that
we consider doing
post-3.4.2 builds of the 3.4 tree.
The sense of the meeting, I think, was that this would benefit our
customers (e.g., a central point for customers to get signed packages
when there are bug fixes needed for an Eclipse-based product); but that
there were obvious challenges in terms of messaging and releng
The suggestion wasn't mine, but I would benefit from something like
this. JDT-APT introduced a regression in the very last bug fix we
for 3.4.2 - one of these deals where, in fixing one bug, we introduced
different one, that wasn't discovered until a user upgraded. Olivier
and I both carefully reviewed the change before it was committed, and
while in retrospect I feel awful about it and we could have been even
more conservative than we were, frankly this stuff does happen.
The user in this case is a solution provider whose solution is now
busted by this frickin' little corner case that we'd never realized
existed, and he's politely wondering whether he needs to host a
post-3.4.2 patch update site on his web site or whether it should be on
Eclipse. I think the answer is probably "Eclipse" because
will inevitably hit this and I want to have an answer for them.
My default idea is to create an update site for the plug-in in question,
dangling off the Eclipse JDT-APT web page. But that seems slightly
silly if there are also going to be fixes over time in other components,
as there have been in 3.2 and 3.3. Imagine the poor user who needs
get a collection of these fixes. I'd much rather point them to a
place, even with the understanding that it is not for everyone and that
the fixes there are "caveat updator."
So, my straw-man proposal would be:
1. We do periodic post 3.4.2 builds - say, once every month or two.
2. These get an automated test run but no performance tests or manual
integration testing (no test day).
3. They are made available from a single update site hosted on
4. Information about that update site states that the code has not been
fully tested and that users should only update if they are encountering
a specific bug that is known to be fixed in the update.
There are plenty of holes in that proposal, but maybe it's at least a
starting point for discussion.
eclipse-pmc mailing list