Re: [eclipse-pmc] post 3.4.2 builds

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

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
up front.

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
actually running?

"Walter Harley" <eclipse@xxxxxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

03/11/2009 06:42 PM

Please respond to
eclipse-pmc@xxxxxxxxxxx

To	<eclipse-pmc@xxxxxxxxxxx>
cc
Subject	[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
resources. 

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
made
for 3.4.2 - one of these deals where, in fixing one bug, we introduced
a
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
someone else
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
to
get a collection of these fixes.  I'd much rather point them to a
single
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
eclipse.org.
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.

Thanks,
  -walter

_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc