Greetings,
I'm sorry if this has been brought up and discussed elsewhere already.
But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno
SR2 a high risk for users.
See here for details:
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html
Am 19.02.2013 18:04, schrieb
Am 22.02.2013 11:33, schrieb Markus Knauer:
- If I were a member of the EGit team, I would try to educate my users
how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing
list, other channels...
They are trying really hard. But honestly, would you download a software
that has a
This would also help us to properly deal with:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477
Cheers
Alexander
Am 22.02.2013 um 11:55 schrieb Gunnar Wagenknecht gun...@wagenknecht.org:
When it's really too late for SR2, the plan should be made for a SR2a.
--
Dr. Alexander Nyßen
I think we need to look at respinning SR2. For the last 18 months we have
been pushing the entire community towards git, so now introducing a
significant regression into eGit would just be bad news for our users.
From: cross-project-issues-dev-boun...@eclipse.org
+1 for respinning, and declaring Juno SR2 early next week.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cross-project-issues-dev-boun...@eclipse.org
*If* respinning SR2 is in order, is it possible to include m2e 1.3.1 as
well (instead of 1.3.0)?
This is far less critical than eGit, (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=400520 /
http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=95b254ecec2b1cb723a6d2ae4fb7a47a394c2dcb)
but it's a
I'm obviously a little late with my Wait message, but given the data
damaging bug reported by EGit, We need to think this through and come up
with an alternative plan.
All those plans would involve not releasing today.
I'll call for an Emergency meeting of the Planning Council today at 1:00
2013/2/22 Gunnar Wagenknecht gun...@wagenknecht.org
Am 22.02.2013 11:33, schrieb Markus Knauer:
- If I were a member of the EGit team, I would try to educate my users
how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing
list, other channels...
They are trying really
it's up again I just started a jgit build
--
Matthias
2013/2/22 Denis Roy denis@eclipse.org
Restore is complete, and Matt is kicking Hudson as I type this.
Thanks,
Denis
On 02/22/2013 08:54 AM, Eric Gwin wrote:
Any news? A cursory look at build.eclipse.org shows what appears to
2013/2/22 David M Williams david_willi...@us.ibm.com
I'm obviously a little late with my Wait message, but given the data
damaging bug reported by EGit, We need to think this through and come up
with an alternative plan.
All those plans would involve not releasing today.
I'll call for an
Hi David,
On 22/02/2013 14:14, David M Williams wrote:
All those plans would involve not releasing today.
Just wondering, if this Wait ... don't release yet! also implies
individual projects.
We (I) have already published our bits as planned (Only announce to the
forum is pending). Giving
Hi David,
Thanks. Unreleasing is quite straightforward:
- Removing a composed children p2 repository (the target release)
- A minor change commit and push to hidden the downloadable zips.
Going for that, then.
Cheers,
Adolfo.
On 22/02/2013 14:29, David M Williams wrote:
Individual projects
2013/2/22 Matthias Sohn matthias.s...@gmail.com
2013/2/22 David M Williams david_willi...@us.ibm.com
I'm obviously a little late with my Wait message, but given the data
damaging bug reported by EGit, We need to think this through and come up
with an alternative plan.
All those plans would
As already documented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477,
I did the same for gef yesterday, so when re-running the aggregator, gef 3.8.2
should now be properly included as well.
Cheers
Alexander
Am 22.02.2013 um 15:57 schrieb Matthias Sohn matthias.s...@gmail.com:
Thanks very much. I started a build, and it failed:
/opt/users/hudsonbuild/workspace/eclipselink-nightly-master/autobuild.xml:430:
java.io.FileNotFoundException:
/shared/rt/eclipselink/handoff-file-build-master-v20130222-547208e.dat
(Permission denied)
Looks like Hudson may need some
Not the release day email I was expecting to wake up to, but I agree that a
respin seems in order. In this case quality trumps deadlines.
Cheers,
Ian
On 22 Feb 2013 06:19, Matthias Sohn matthias.s...@gmail.com wrote:
2013/2/22 Gunnar Wagenknecht gun...@wagenknecht.org
Am 22.02.2013 11:33,
I'm re-applying the ACLs for hudsonBuild. It is taking forever.
Denis
On 02/22/2013 10:07 AM, Eric Gwin wrote:
Thanks very much. I started a build, and it failed:
/opt/users/hudsonbuild/workspace/eclipselink-nightly-master/autobuild.xml:430:
java.io.FileNotFoundException:
Simrel is a composite repo, isn't it ?
So what about simply adding 1 branch to the composite which contains egit-2.3.1
and then respinnnig the packages ?
That shouldn't take more than the week-end , even including all mirroring ?
I sympathize with Alexander (GEF) and Fred (m2e), but IMO any
2013/2/22 Denis Roy denis@eclipse.org
Off hand, a complete respin cycle would take at least a week, maybe two,
but there might be ways to simply remove EGit, putting it back at its SR1
level, producing that better known quantity, and letting EGit follow their
own release schedule, as
After some painful conversation with the Planning Council members, the
conclusion was to delay the release 1 week, but not do a full respin, to
only revert the EGit contribution.
The plan is to redo the common repository and EPP packages, with the EGit
contribution reverted to what it was in
I hate to throw a stick in the spokes, but what happens if another project in
the aggregate repository already has a min dependency on EGit 2.2 or even 2.3?
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf
Since the new version of EGit was only introduced in RC3, that could only
happen if someone changed their minimum dependency on EGit in their RC4
contribution. That seems unlikely but projects should speak up if they
have that constraint. Markus mentioned the only project downstream from
EGit
The only way to be safe is to re-run the aggregation build after the
roll-back, regardless of whether the rollback is to 2.1 or 2.2. That will
flush out any issues with dependency. Then, of course, we need a contingency
for what happens if aggregation fails (there is a dependency).
In some
The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug
that could be addressed by the project's own update repo and hot fix
process. The GEF issue is more complicated, can not be fixed by their own
update site, exactly, since part of the damage already exists in SR1.
Kosta has a very good point here:
moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900
unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10
2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.com
Kosta has a very good point here:
** **
moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900
unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B
10
Thanks Matthias –
So then in my understanding there is no contribution in Simrel outside egit
itself, that would require egit-2.3 and thus the rollback should be fine.
Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck
Bridgham has mentioned.
Thanks,
Martin
--
Martin
If GEF is (or has) released a feature with the version 3.9 and there is a
new GEF release that contains additional API, then it should (must?)
increment it's minor version to 3.10. If there is no new API between what's
been released and Kepler, then I supposed that keeping 3.9 is ok, but
really a
Frankly its rather scary that SR2 will run on a milestone build of GEF. How
much testing was there on this milestone to assure fitness for SR2?
I know that I, along with others how build upon GEF, would rest easier if
the GEF issue was also resolved in the respin. This is the last Juno
2013/2/22 Oberhuber, Martin martin.oberhu...@windriver.com
Thanks Matthias –
** **
So then in my understanding there is no contribution in Simrel outside
egit itself, that would require egit-2.3 and thus the rollback should be
fine.
Using 2.2 seems preferable to me, to get the
David can correct if I'm wrong here. But the decision was to actually remove
Egit from the SR2 repo resulting in the Egit from SR1 getting picked up
instead. Egit 2.2 wasn't considered.
It's a pretty troubling situation. The community shouldn't be taking this
lightly.
Sent from my BlackBerry
If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that
seams, that ship already sailed.
Sent from my BlackBerry 10 smartphone.
From: Konstantin Komissarchik
Sent: Friday, February 22, 2013 5:55 PM
To: 'Cross project issues'
Reply To: Cross project issues
Subject: Re:
Alexander Nyßen wrote:
GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I
remember - still
contained the 3.8.1 bundles, only the feature versions were incremented at
that time)
[snip]
3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains
2013/2/23 Doug Schaefer dschae...@qnx.com
David can correct if I'm wrong here. But the decision was to actually
remove Egit from the SR2 repo resulting in the Egit from SR1 getting picked
up instead. Egit 2.2 wasn't considered.
I didn't know that it was decided to remove egit from SR2 and
Hi
Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2
that must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then
3.10.0 for Kepler.
[When this is all over, can we have a clearer policy on maintenance
releases being maintenance
The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect
to bundles (I assume the branches had not diverged at this point), and only the
feature versions increased to 3.9.0 (I will cross-check that again, but the
bundles should just have different qualifiers w.r.t. the
36 matches
Mail list logo
