Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Re: [cross-project-issues-dev] Re-spin process

<pascal> See answers embedded </pascal>



      - Are the EPP packages rebuilt and should they be?

I think that if we release new bits via the Europa discovery site, we
should release new EPP packages with those bits. But that's just my
opinion.
<pascal> I agree too. I hope for Markus that the package creation is as
automated as the Europa matic</pascal>

Second, my opinions:
      Personally I like the approach where Europa is a just a name and the
      content is a moving target representing the latest and greatest
      versions of
      the 21 projects that initially contributed until Ganymede ships. Of
      course
      it is harder for developers to know which versions of a plug-in
      someone was
      using, but the benefits for the community seems to be pretty high,
      and it
      also means that we regularly re-spin putting a higher burden on the
      coordinator.
I like this approach a lot - it matches well with the ease of distribution
that the internet provides us. I'm not clear on your "harder for developers
to know which versions of a plug-in" because each plug-in has a unique four
part version number. Each re-spin that contributes new bits would provide a
new four-part version number for those new bits. (I'm probably missing
something subtle.)

<pascal>You are right about parts of the version number changing (in fact
the content of europa should only change in its third and fourth segment)
and you did not miss anything subtle. The thing that worries me here is the
end user perspective. He/she has Europa, therefore when a bug is entered
the build id will likely be Europa. However for a bug triager this is not
enough thus requiring another round trip with the bug author to ask the
feature version of the suspected component (note that we need feature here
unless the cause of a failure is clearly identified to a plug-in, since it
is the only thing that changes for sure during a rebuild).
In the long term, a cool/perfect solution probably lies at the intersection
of our bugzilla infrastructure, mylyn and the new provisioning work, such
that when a bug is entered from mylyn the user setup is gathered
automatically (using provisioning infrastructure) and posted into a special
configuration entry in bugzilla. From that a bug triager/fixed could
reprovision on its machine the configuration used by the user. But I derive
:-)
</pascal>

As for the Europa coordinator: the overhead is fairly low, especially if
the re-spins are not emergencies, and the overhead for Ganymede will be
even lower. The "distribute to the leaves" philosophy of Europa and now
Ganymede is a big help here: for Ganymede, the Gan-omatic will do a build,
if the build fails, it will automatically remove the offending project and
then build again; it will continue doing this until it gets a green build.
It will notify all the project owners by email that they failed the build
and were removed from the Ganymede update site. Very low overhead for me
(the coordinator) because the computer is going to do all the work. Thomas
Hallgren (Cloudsmith, Buckminster) is going to help me set this up.
<pascal>I did not realize that everything was so automated, so it is really
great</pascal>

- Bjorn
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council




Back to the top