Re: [eclipse.org-planning-council] Respin of Mars 1 for Buildship

["David M Williams" <david_williams@xxxxxxxxxx>]

This has formally met the criteria for
an exception. (I'll wait a little longer to make it official, to give a
few hours for objections, if anyone dares :). 

But, two more questions for your Planning
Council member input: 

1. How long should we delay the formal
release? I was thinking of a full week (to give time for some adopter and
community confirmation for the new builds). Markus was thinking of three
days (Monday instead of Friday). 

I'd like to hear if others have an opinion?
Keep in mind, M2 is due next Friday too. But, also keep in mind, in the
past, doing a rebuild has sometimes "changed the repository"
in unexpected ways, since p2 is "pulling" from a reduced set
of artifacts, so sometimes comes up with a better solution than it would
when working with more artifacts ("better" in terms of reduced
numbers .. but ... in some rare cases, might not be what's desired). 

2. Do you think it worth picking up
another fix? From JGit, so that only one version of com.jcraft.jsch is
in the repository?  See bug
477148 and bugs it references
for the problem. The fix is for them to change what is "included"
in their feature. I do not want to "pile on" just because we
are doing a respin, but I do think that issue has the *potential* to be
nastier than the Buildship bug. I say "potential" just because
there may not be a work around for it, if someone does get "class
loader constraint" violations, but am not sure. And, also not sure
how many scenarios the problem might manifest itself in. There's only been
one concrete problem reported, that wasn't reproducible after a re-install
... so seems related to the order in which things are done. And, FWIW,
doing a re-spin would not magically leave out the "lower" version
of com.jcraft.jsch, since both 51 and 53 are (currently) explicitly included
by features. 

Advice welcome, 







From:      
 Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
To:      
 Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>, 
Date:      
 09/23/2015 11:01 AM
Subject:    
   Re: [eclipse.org-planning-council]
Respin of Mars 1 for Buildship
Sent by:    
   eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

+1

I tested the behaviour and the fix this afternoon, and
to me it seems to be worth a rebuild to avoid a bad user experience of
many users who will be testing the new Buildship Gradle tooling.

Thanks,
Markus


On 23 September 2015 at 16:56, Max Rydahl Andersen <manderse@xxxxxxxxxx>
wrote:
On 23 Sep 2015, at 15:55, Doug Schaefer wrote:

For your consideration.

I’ve commented on the cross-projects list with my thinking here. Since
we don’t seem to have a way to ensure we get maintenance releases of the
projects to users of the EPP packages, we have to do what’s right for
the users of those packages and fix these problems how we can. And unfortunately,
right now, that requires a respin.

+1000

/max


Doug.

From: <tools-pmc-bounces@xxxxxxxxxxx<mailto:tools-pmc-bounces@xxxxxxxxxxx>>
on behalf of Etienne Studer <etienne@xxxxxxxxxx<mailto:etienne@xxxxxxxxxx>>
Reply-To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx<mailto:tools-pmc@xxxxxxxxxxx>>
Date: Wednesday, September 23, 2015 at 7:28 AM
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx<mailto:tools-pmc@xxxxxxxxxxx>>

Subject: [tools-pmc] [Request] Respin of Mars 1

Hello

I’d like to ask the Tools PMC to do a re-spin of Mars 1 due to a critical
bug in Buildship 1.0.3, the Buildship version that is currently in Mars
1 RC4 and its EPP packages (Java / Committer / RCP). The bug has been fixed
in Buildship 1.0.5.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478151

Some details below:

What is the bug?
Buildship calls Bundle#start() to eagerly activate its UI plugin. This
is a problem since it causes the OSGi framework to persistently mark that
bundle for eager activation upon restart. Once Eclipse is restarted, the
bundle that was persistently activated will be activated very early in
the startup process which will likely cause it to touch preferences 'too
early' which results in no workspace prompt and the default workspace being
used.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054.

How does the bug become apparent?
Once a Gradle task has been launched from the Tasks View, the user will
not be prompted for the workspace anymore the next time he starts Eclipse,
but instead the very default Eclipse workspace is used.

Who is affected?
The bug affects those users (and only those users) that run a Gradle task
through Buildship from within Eclipse.

When was the bug identified and investigated?
We were able to confirm that this is a Buildship bug yesterday. We also
found the cause and a fix yesterday. All Buildship versions < 1.0.5
contain the bug.

When was this bug introduced?
The bug is there since June 6th, as we have found out in retrospect (yesterday).

Why was this bug not found earlier?
Most likely, because the relation between Buildship and how the bug manifests
itself in Eclipse is not obvious to the user observing the issue.

Is there a fix available?
Yes, the fix is available in Buildship 1.0.5, available as of last night.
It has been confirmed by three Gradle forum users that the issue has been
resolved in Buildship 1.0.5 .

I believe that it is critical for the introduction of Buildship into the
Eclipse SimRel and the Eclipse distributions that we get this fix in for
Mars 1. Otherwise, it will be a bad start for Buildship, especially considering
that the bug was known before the release and a fix would have been available.
Also, users might associate the bug with a general Eclipse problem, which
could cause unfair frustrations about the Eclipse IDE.

Thanks for considering it.

Regards, Etienne


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the solicitor-client
or other applicable privileges), or constitute non-public information.
Any use of this information by anyone other than the intended recipient
is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system.
Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxxto request removal.


/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxxto request removal.



-- 

###
EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

http://eclipsesource.com


Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany 
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.