Things are looking pretty good ... which means I was able to coax out a
green build, hacking in a few quick fixes and disable a few
contributions.
I've opened bugs where I made a quick fix and will remind everyone that
the following projects still have disabled features or repositories. Some
I saw some similar issues today, and opened this bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=363093
People using/effected by Graphiti may want to watch that bug ... I think
Michael will fix and explain soon,
but might effect others final build ... and I'm just saying might,
probably not,
Be sure to open bugs on issues and solutions, even if it turns out to be
not that bad (as Doug said) ... we are collecting them, such as
Bug 362076 - Better policy to guard against deleting all branches and tags
from our public repos
From: Greg Watson g.wat...@computer.org
To: Cross
Since I had to clear this up in TWO meetings I was at today ... I figured I
would remind everyone else, too.
The platform M4 (+0 day) is scheduled for Friday, 12/9.
The Simultaneous M4 is scheduled for 12/16. One week later!
See
http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Schedule
://wiki.eclipse.org/Juno/
Thanks,
From: Ashwani Sharma ashw.ku...@gmail.com
To: David M Williams/Raleigh/IBM@IBMUS,
Date: 12/06/2011 11:13 AM
Subject:Re: Need permission to submit files for juno contribution
Hi David,
I have submitted EMF Query2 contribution.
How can I check
So ... to be explicit ... there's nothing we need to do differently to
take advantage of better cleanup ... that this was just to overcome a bug
or limitation with Hudson?
We still can't (and are not expected to) shell over to one of the Hudson
slave's and do rm -fr to clean up anything ...
M5 ends February 3.
See
https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9t...@group.calendar.google.comctz=America/New_Yorkgsessionid=OK
and other info at
http://wiki.eclipse.org/Juno/
If you've not been in before, and nothing breaks if you are not in M4, I'd
suggest we handle
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231
[attachment Snapshot.PNG deleted by David M Williams/Raleigh/IBM]
___
cross-project-issues
version need increased for M5.
On the other hand, is not there any way to make the aggregator fail in case
the bundles which feed it are not signed ?
Cheers,
Adolfo.
El 15/12/2011 16:04, David M Williams escribió:
Yes, for M4, unsigned content wouldn't justify a respin. Its
some important issues between communities and nice to
know someone is working on them. I'm sure many in Eclipse will be
interested in your progress or outcome.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=364469
From: Eric Gwin eric.g...@oracle.com
To: David M Williams/Raleigh/IBM
, yes, that's
pretty much it. The first three segments are meant to match exactly the
original 3rd party jar/bundle, but the qualifier is not literally
date/time built but rather date/time of last CVS change, just to be
explicit.
HTH
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross
No, not too late ... too early :) ... but, my apologies, I've been meaning
to look into that breakage and will now give it a higher priority. You
can expect it to be fixed by Monday, 1/9, at the latest.
And, just in time!
As a reminder to all, Indigo warm-up RC1 runs from January 13 to January
of date
temporarily disable rap runtime
temporarily disable riena due to changing platform core
[2] http://download.eclipse.org/releases/maintenance/
[3] http://wiki.eclipse.org/Indigo/Simultaneous_Release_Plan#SR2
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross
This appears to be same issue described in bug 329923
https://bugs.eclipse.org/bugs/show_bug.cgi?id=329923
$ wget http://download.eclipse.org/releases/indigo/compositeContent.jar
--2012-01-18 13:20:50--
http://download.eclipse.org/releases/indigo/compositeContent.jar
Resolving
extremely hard to get a build to run on that hudson instance now with
all the builds tied to it (the virgo nightlies come to mind as they
often take all executors on the morning -CET-).
Best regards,
Laurent Goubet
Obeo
[attachment laurent_goubet.vcf deleted by David M Williams/Raleigh/IBM
tick tock
Here we are already at 3 PM on +3 day. Unless someone shouts wait, I'll
consider the updates for RC1 finished by 5 PM today (Eastern), and what
ever build is current will then become our maintenance staging repo for
RC1.
http://download.eclipse.org/releases/maintenance/
There are two
, with a x.y.2 version or can
we keep this x.y.1, since the code will be the same?
And thanks for your quick help over all these warm-up weeks! :)
On Wed, Jan 18, 2012 at 17:58, David M Williams david_willi...@us.ibm.com
wrote:
tick tock
Here we are already at 3 PM on +3 day. Unless someone
will be finished
thursday at 4AM Eastern. Could you wait us?
Cheers,
--
Vincent Lorenzo
De : cross-project-issues-dev-boun...@eclipse.org
[cross-project-issues-dev-boun...@eclipse.org] de la part de David M
Williams [david_willi...@us.ibm.com]
Date d'envoi
Looks like no other changes since 3:00 PM, so we'll consider this our RC1
repo. Suitable for early sanity checking and EPP Package build testing.
http://download.eclipse.org/releases/maintenance/
Don't forget to check repo reports ...
http://build.eclipse.org/indigo/simrel/
It looks like a
Remember that this coming week, Friday 1/27 to Friday 2/3 is the window
where we will be producing BOTH Juno M5 and Indigo SR2 RC2, with the most
work, for aggregation at least, taking place Monday to Wednesday. So, in
general, please respond to aggregation build failures quickly. And, more
Gold star to Mark for keeping us all informed!
Now that I look, I see that Riena is (still) disabled for Indigo SR2 RC2.
That's not good. Oversight? Or intentional? I will re-enable it, and see
how it does ... but doesn't work well for me locally ... if it is
intentionally still disabled due to
Still having windowbuilder problems (in Juno and Indigo) waiting to hear
from Mark. Hopefully fixable in next few hours?
Konstantin, it is automatic if you change your b3aggrcon file (which you
did) and in fact your contribution built successful in build 241.
As with Indigo, many problems ... unfortunately, we'll need to live with
these for 6 weeks until M6 ... expect more nag notes!
Test staging at
http://download.eclipse.org/releases/staging/
On Friday, this repo will be composed into /releases/juno (along with M4)
Worst problems:
Many disabled
, and I forgot to add them to the build.properties.
They are actually in the repo. Will be fixed for RC3.
Greg
On Feb 1, 2012, at 11:46 PM, David M Williams wrote:
I hate to call it done. We failed to achieve a true release candidate. I
blame myself. I obviously have not been sending out enough nag
M5 is not even out the door and problems already known about M6
aggregation! ... how's that for early warning? :)
See bug 370405 [1] for details (and feel free to comment there) but by a
series of bugs, coincidence, and my own missteps, our Juno aggregation
repository still points to an old
or should be do something
different to make sure we don't cause problems?
--
Regards,
Igor
On 12-02-02 3:49 PM, David M Williams wrote:
M5 is not even out the door and problems already known about M6
aggregation! ... how's that for early warning? :)
See bug 370405 [1] for details (and feel free
The official M5 location for Juno has been mirrored and turned on this
morning. There are only about 8 mirrors so far, so wouldn't hurt to wait,
unless you need it today.
http://download.eclipse.org/releases/juno/
(And remember, this one contains M5 and M4, and that mistaken Indigo
platform,
Nag note ...
Here we are, at beginning of RC3 +1 day, and a few questions and
reminders ...
Has Eclipse (the platform) contributed for RC3 yet?
I notice the contribution file says
M20120127-0800
but there is an M build from
M20120201-1336
which sounds like its closer to RC3, but, I do not know
there to RC4 ... well, except for
the little matter of everyone fixing their project's bugs and
regressions! :)
As always, test early, test often ... keep us posted ... and let us know if
questions.
Thanks,
From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev
I tried matching up the projects that are participating in Juno, per
http://www.eclipse.org/projects/releases/releases.php?release=juno
with the b3aggrcon files in the juno.build project.
Lacking any hope of automation, I hacked together a wiki page to use for
now:
/2012 02:49 PM, David M Williams wrote:
of Hudson seems several comments made or questions asked on this
list
with no response ... Hudson restarted, configuration changes all without
comment.
Just to close the loop on this one... Sometime ago, we decided (via
this list) that webmasters
Despite Hudson's attempts to thwart our progress, our RC3 repo is done and
testable at
http://download.eclipse.org/releases/maintenance/
and this one is a true release candidate! (though, I know a few more bug
fixes are planned for RC4, our final build).
Thanks to all those fixing legal file
-- We're currently running Hudson 2.1.2... We should perhaps upgrade to
2.2.0, or perhaps even use the 3.0.0 milestone that is available at
Eclipse... Any thoughts?
I've opened bug 371039 to discuss this. Anyone with knowledge or opinions
are very welcome to pipe in.
I've opened bug 371396 in orbit to discuss/decide.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371396
Thanks,
From: Ed Willink e...@willink.me.uk
To: cross-project-issues-dev@eclipse.org,
Date: 02/13/2012 11:59 AM
Subject:Re: [cross-project-issues-dev] Is it acceptable to have
,
From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org,
Date: 02/08/2012 02:07 PM
Subject:[cross-project-issues-dev] I need your help matching Juno
projectsto Juno aggregation files
Sent by:cross-project-issues-dev-boun
Here we are, end of RC4 +1 day. Final bits from many projects are being
provided, aggregated, and promoted to
http://download.eclipse.org/releases/maintenance/
So, keep up that continuous testing :/
Things are going smoothly as far as I can tell, with bug 371302 [1] being
only one I'm worried
http://download.eclipse.org/releases/maintenance/
(Final EPP packages, I'm sure, will be ready tomorrow, Thursday is EPP
day).
Now even though it sounds like we are done, it is not the time to slack off
on testing! Time for final testing and preparation for downloads and
updates.
Besides
/hudson/view/Repository%20Aggregation/job/indigo.runAggregator/lastBuild/consoleFull
[attachment laurent_goubet.vcf deleted by David M Williams/Raleigh/IBM]
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org
several slaves. Thought would be easy to use the production master
slaves and the production memory dump would give real scenario.
- Winston
On 2/17/12 6:28 AM, David M Williams wrote:
If you have any questions please feel free to ask.
Well ... since you asked us to ask ... :)
Why not use
I know there was a problem where a Gerrit Plugin was triggering jobs
(unrelated to Gerrit) but as far as I know, that was disabled/removed from
the production Hudson system. (Sorry, don't know bug number).
Plus, I had a case where URL Content Change trigger stopped working
right, and those jobs
I've added a new report to the common repository reports [1].
It is called Optional Runtime Requirements and Greediness [2]
I doubt it is too useful at the moment, except to reflect the magnitude of
the problem ... that many projects still have to move up to a more recent
publisher. Ideally,
No, no. Nothing new you have to do. No change to current procedures or
policies. But ... there is another document for your reading pleasure.
There has always been some notion of priorities that are sometimes
discussed and used in the context of the Yearly Simultaneous Release, And,
it was
Seems ok to me.
I can get to
http://download.eclipse.org/tools/orbit/downloads/drops/S20120308061416/repository/
from both inside and outside the eclipse (build) infrastructure and can
load the repository from that URL.
Maybe a momentary glitch?
To be explicit, there is no site.xml at that URL
I have been meeting with Kim, John, Paul, Bogdan and others nearly every
day to sort out changes coming to releng and the Eclipse Platform builds
after M6.
In brief, ... be patient :)
For the longer story of the plans to move to build.eclipse.org, see
I won't say who ... except to say it was not me! (this time :) ... had a
little script mishap, combined with incorrect permissions on the file
system, and the Eclipse project's 4.2 milestone repo was broken today
around noon. See bug 374707 [1] for details if you enjoy (or need) that
kind of
One more day. Wednesday 5 PM is cutoff unless someone requests an extra
hour or two.
The following aggregation files still contain some disabled features or
repositories.
Some are understood or already explained here, but others I have no idea
what's going on ...
not that I need to ... but,
Do you know where I can find org.eclipse.releng.tools for 4.2, a built
version?
Why do you ask? :) Having problems?
short answer 1:
There isn't one, specifically for 4.2 if you want to use if for updating
cvs mapfiles. As far as I know, you can still use the one from the 3.8
build page.
Well, normally I'd say no but, by virtue of meritocracy, when Ed
says we should, I believe it!
Note that no downstream clients are affected
What about EPP? I assume this effecting modeling package? But only modeling
package?
So, at the moment, I'll say yes and plan on starting a new
The .../releases/juno repository is well mirrored (60) and I have flipped
the switch to make it available for p2 updates.
The EPP Packages will be available later in the day; they will need a bit
more time for both the maintainers to sanity check, and a bit more time for
the mirrors to catch
repository [1] appears to contain older version of m2e. Is this
expected at this point or should I start investigating?
[1] http://download.eclipse.org/releases/staging/
--
Regards,
Igor
On 12-05-06 3:38 PM, David M Williams wrote:
Yes ... its here, M7 week! And, I'm already giving status
,
Igor
On 12-05-06 5:54 PM, David M Williams wrote:
... contain older version of m2e. Is this
expected at this point or should I start investigating?
I'd investigate. I assume you are expect something later than 1.1.0?
Looks like your m2e.b3aggrcon file has not been updated since November
] Status and outlook for M7
CDT is scrambling to fix some major issues. We may ask for more time.
Hopefully not.
Thanks,
Doug
From: David M Williams david_willi...@us.ibm.com
Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
Date: Wednesday, 9 May, 2012 12:11 PM
To: Cross project
Sorry Igor ... Juno's at the intersection of cutbacks and change. I guess
that wiki page should be fixed (feel free), but the explanation is on the
main Juno category: http://wiki.eclipse.org/Juno/
Tracking compliance and checklists: unlike previous years, there will be no
rolled-up, summarized
We in Orbit normally create our candidates a week a head of time to allow
plenty of time for updates or migration in build scripts.
But, the Platform has requested a respin for RC1 that makes sense to me, so
on Wednesday afternoon we will be producing a new S build from Orbit, for
use in builds
1. We'll be a bit late. Our RC1 +0 day is today (which I take as 5 PM), but
a serious regression was found and a respin requested, so by the time we
get that done, and confirm that final respin it will be either very late
tonight and probably Saturday before we do the final declare and rename
Is anyone still using this com.google.collect bundle, for Juno?
Normally, we in Orbit would never consider removing a bundle this late in
the cycle, but this bug has fallen through the cracks.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371396
The original creators of com.google.collect
Here it is, nearly 5 PM on +3 day, and we haven't had a green build all
day!?
I've been assuming people were tending to the issues and fixing things
up ... but ... without some quick communication here, I'm going to start
disabling projects in order to get a good build.
Please let us know if
Thanks to all the last minute fixes and getting a clean build. I've
disabled the aggregation build and assume we are ready for RC1, unless
someone comes up with a blocking problem that justifies a respin.
My main concern is that there are still two projects still disabled:
amp.b3aggrcon
If you absolutely want to eliminate the warning, just re-sign the jars
with the new cert. No need to rebuild them.
Care is needed here. Since the exact bits of a bundle are assumed to
be unique to the exact version and qualifier of a bundle. So, if a
signature
changes, the qualifier (at least)
I'm glad my note spurred so much attention to this important issue. I'll
try to respond briefly (but, you know how hard that is for me :)
I thought we had been through all that discussion on bugzilla already (I
can't find the ref right now since bugzilla is down).
. Georg Pietrek, Jens
Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
Am 24.05.2012 um 06:40 schrieb David M Williams:
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https
I have flipped the switch for Juno software repository so it now contains
RC1 content, along with the previous M7 content.
http://download.eclipse.org/releases/juno/
I haven't officially tested RC1 and M7 coexistence compatibility, but am
assuming its close enough not to cause problems, and
Means, using the new p2 publisher is obligatory and greedy=false is
not obligatory.
quoteIf the old behaviour is desired, i.e. an optional dependency
shall be satisfied during installation whenever possible, the
dependency can be annotated with an additional
3.
I'm not sure where documented either, but the general advice, I've heard,
and agree with, is for _products_ to include update sites but not features.
So, EPP Java EE I know likes to include some for webtools, mylyn, others?
And its makes sense for them as a product as it usually would for
of your magic reports to detect bad Update Site
URLs?
Regards
Ed Willink
On 25/05/2012 22:39, David M Williams wrote:
3.
I'm not sure where documented either, but the general advice, I've
heard, and agree with, is for _products_ to include update sites
this is the behaviour I see with Juno M7 P2 runtime
included with Tycho. Don't know if newer P2 behaves differently or if
the problem is limited to Tycho.
--
Regards,
Igor
On 12-05-24 10:27 AM, Denis Roy wrote:
On 05/24/2012 06:30 AM, Stephan Herrmann wrote:
On 05/24/2012 06:40 AM, David M Williams wrote:
Look
I did add some blame tracking and data to the greediness reports.
http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html
I'm not 100% sure the report is 100% correct, but if it is, the top 10
list of projects not using new publisher (or, deliberately circumventing
it) is
http://wiki.eclipse.org/Juno/Final_Daze
For those new here, we have this document every year. It is about the same
as previous years, but at least one person from each project should read it
carefully to now what's expected (probably release engineer, or project
lead, if not both). It tries to
sounds like 7 or 8 then? I'm find with that ... let us know if/when done.
If it starts to get past 9 (Eastern) I think we should should say no
more ... as with last week, we seem to be having trouble getting a green
build today, on +3 day.
Thanks,
From: Matthias Sohn
to the p2 repo for installing the current b3 model editor
to update
the contribution files ? Hope this helps to not kill the aggregator build.
--
Matthias
2012/5/30 David M Williams david_willi...@us.ibm.com
sounds like 7 or 8 then? I'm find with that ... let us know if/when done.
If it starts
-project-issues-dev-boun...@eclipse.org
I submitted our RC2 contribution for JGit and EGit, will you start another
aggregator build ?
I'll stay on standby until this build is green.
--
Matthias
2012/5/31 David M Williams david_willi...@us.ibm.com
Use the 0.2.x version of the b3 aggregator
I've promoted and made visible the RC2 content at
http://download.eclipse.org/releases/juno/
Unless someone reports incompatibilities, that repository is a composite
of RC2 and RC1.
The EPP packages will be available soon from
http://www.eclipse.org/downloads/index-developer.php
Thanks
Same place, if I understand the question ... same b3aggrcon file. Things
in Juno aggregation should be for only 4.2 (if, it does not work for
both). If you have 3.8 users that need your 3.8 specific site, you will
have to have some directions on your website that explains what they
should add
As we begin RC3, week, I wanted to report the good news that Virgo got
their problem figured out so everyone is currently in, and I've updated
staging (which would be sort of an RC2 Plus).
And the reports at
http://build.eclipse.org/juno/simrel/reporeports/
are looking much better than the
actually releasing an
contributing.
Thanks!
Benjamin.
De : David M Williams david_willi...@us.ibm.com
Répondre à : Cross project issues cross-project-issues-dev@eclipse.org
À : cross-project-issues-dev@eclipse.org
cross
Admittedly, there is one day left for Juno RC3, but I can't help but point
out several (27) missing about.html files.
http://build.eclipse.org/juno/simrel/reporeports/reports/layoutCheck.txt
Plus, according to another report,
This question has come up before if an Eclipse Project can release,
while it depends on something that is not released. And there are two
flavors: a) the dependency has never released at all, and b) the
dependency has been released before, but the project is not participating
in current
... and as a result org.eclipse.equinox.concurrent no longer part of
Eclipse Platform runtime as of RC4.
The greediness report is looking much better; thanks to all for paying
attention to details and making the common repo better.
My understanding was the the aggregator pulled the feature -- and only
the feature -- dependencies it needed from the aggregated site(s). Is that
not correct?
That is pretty much the case ... but ... it can get complicated. Do you
have any optional dependencies on it and do you publish
http://download.eclipse.org/releases/staging/
One more to go!
Test well!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
We got a few last minute respin requests, which should not effect
functionality, but are important packaging issues.
Our +0 deadline is today (5 PM Eastern) and the I-build re-spin will
actually be done by about that time ... but ... our Unit tests for that
build will not finish until
24 hours left!
I appreciate everyone keeping the build green and making progress on the
sim rel reports [1], though there are a few serious issues left there.
Just wanted to remind everyone that after RC4 (which ends tomorrow,
Wednesday, at 5 PM, unless someone asks for a few extra hours)
It is important to make sure the b3aggrcon files point to something that
allows a quick last minute rebuild to be performed, if needed ... but
beyond that, there's no specific rule or guideline about how or when to do
it ... I think it depends on each project's (or release engineer's?)
for a
green build].
- Forwarded by David M Williams/Raleigh/IBM on 06/13/2012 11:48 AM
-
From: David M Williams/Raleigh/IBM
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date: 06/13/2012 11:45 AM
Subject:Re: [cross-project-issues-dev] Failures in the Hudson Juno
was an ACTF problem. I saw that early ... so, will need to
investigate, but its a leaf component so I think we can temporarily
disable unless we hear something from the team soon ... say in the next 3
minutes?
Thanks,
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross
the issue soon, I'll go back to our older build methods.
Best regards,
Kentarou
---
Kentarou Fukuda, Ph.D.
IBM Research - Tokyo
Tel: +81-3-5144-2852
E-mail: kenta...@jp.ibm.com
From: David M Williams david_willi...@us.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date
Could this be a bogus hit?
Absolutely not! :)
Its just the last day is a rapidly changing one! Ironic?
Virgo noted to this list already they'd just fixed the features licenses
and indeed the latest report is clean for features:
the issue.
-Eric
On 13/06/2012 11:50 AM, David M Williams wrote:
Update ... Eric said to temporarily disable EclipseLink, and he'll try to
rebuild to avoid this dependency ... we'll see who shows up next.
[FYI, it is helpful, if you get a not about your project failing, to keep
us all informed
Ok, ... about 6:15 PM Eastern?
The previous build failed due to emf.query2 problem (bug 381786) so I'll
disable that and there will be just about enough time to try a respin
before 6:15 ... so, heck ... take till 6:30. :)
From: Holger Staudacher hstaudac...@eclipsesource.com
To:
I don't understand that. Can you please explain this?
Just that .../releases/juno software repository's main function is to hold
releases. We twist the rules a little before the release and put
milestones there before the first release ... but now that we are done
we will not put final
I find this interesting for a couple of reasons.
It sounds like we do not mirror .blobstore directories? Denis, can you
confirm rsync rules? It would kind of make sense not to by default, since
dot directory ... but, seems .blobstore should be an exception.
I'm not sure of all the ins and
Andrew Overholt provided answer a few days ago ...
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg07849.html
From: Eike Stepper step...@esc-net.de
To: cross-project-issues-dev@eclipse.org,
Date: 06/20/2012 10:59 PM
Subject:Re: [cross-project-issues-dev]
In case you could not guess, the common repo has been switched on and
ready for use.
http://download.eclipse.org/releases/juno/
For general information about Juno, see the main landing page:
http://www.eclipse.org/juno/
Thanks and congratulations to all the committers that make this
A reminder? Can you remind us what you are reminding us of? :)
That is, what is the new distribution of resources? Not that it is
necessarily any of my business ... but I feel like I missed a memo or
something and would appreciate a pointer. (In case there are other changes
coming that I
I have turned back on the aggregation builds.
Not surprisingly it failed right away, since, I suspect, many projects
still need to update their URLs to their final Juno release repository.
There are a couple of activities going on over the next week to 10 days,
such that it would be to your
details in bug 359240
https://bugs.eclipse.org/bugs/show_bug.cgi?id=359240
And give notice to this list when things are ready and set to go.
Thanks,
From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org,
Date: 07/31/2012 08:46 PM
Subject:[cross
(final contributions
from 8/20 to 8/22). That will be a busy week, so anything that can be done
early, even if done as warmup willl likely help that week complete on
time.
Thanks,
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross-project-issues-dev
until CDT enables theirs?
Greg
On Aug 7, 2012, at 10:23 AM, David M Williams wrote:
The re-enable part is in the b3aggrcon file. There is now an
enabled=fasle attribute for your contribution (in master branch) that
you have to remove, commit, and push.
Not sue what the status of the kepler flag
to the portal to manage modeling.emf.emf, but I don't
see Kepler in the choices:
Mail Attachment.png
Regards,
Ed
On 07/08/2012 1:56 AM, David M Williams wrote:
Ok, all done
The main changes were in
http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build
Which itself was renamed from
Our Kepler M1 +0 deadline is today, but,
in our unending drive to quality, we have decided to respin our Kepler M1
candidate
(http://download.eclipse.org/eclipse/downloads/drops4/I20120808-2000/)
Which means our actual M1 declare and promotion won't happen today, but
(likely) Saturday.
See
1 - 100 of 591 matches
Mail list logo
