Ok, it's enabled now. Thanks, Greg
On Aug 7, 2012, at 2:50 PM, David M Williams wrote: > I'm fine either way ... since I want it to be as most convenient for > everyone. So what ever works for you. > > It does slightly increase the odds I might want to disable someone just to > get a green build, in which case, you'd have to re-enable later, once prereqs > were in. But all that won't be a factor until next week. > > But, let's follow this convention: > > Currently the contribution element itself has the enabled="false" flag. > > If you remove that, and I later need to disable something to get a temporary > build, I will disable the repository element, not the whole contribution > itself. I think that will effectively have same result (not include your > stuff, so not be broken by missing prereqs) but will be clear that you did/do > contribute to Kepler, and are in a just a temporarily disabled state. > > Guess I should have been explicit, if anyone _knows_ they will not be in > Kepler, then feel free to say so explicitly, here to this list, to help > communication. But ... I have a feeling CDT will be :) [At least ... I hope!] > > Thanks, > > > > > > From: Greg Watson <g.wat...@computer.org> > To: Cross project issues <cross-project-issues-dev@eclipse.org>, > Date: 08/07/2012 02:16 PM > Subject: Re: [cross-project-issues-dev] Migrating SimRel files this > weekend to Git > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > David, > > We're dependent on CDT, so if I re-enable PTP it will generate a validation > error. Do you want me to go ahead and enable it anyway, or wait 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" is for simultaneous release in > the Portal. AFAIK, the EMO is planning to roll-out their new Portal soon and > I am assume that will all be handled then. > > The "re-enable" contribution is independent of that. (They could be made > related ... but ... not sure anyone is thinking that far ahead). > > Thanks! > > > > > > From: Ed Merks <ed.me...@gmail.com> > To: David M Williams/Raleigh/IBM@IBMUS, > Cc: dennis.hueb...@itemis.de > Date: 08/07/2012 03:30 AM > Subject: Re: [cross-project-issues-dev] Migrating SimRel files this > weekend to Git > > > > David, > > I'm not sure what I need to do to reenable EMF and XSD from the referenced > bugzilla. I went 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 previous "Juno specific" version (Seems things > are constant and steady enough to justify one document for both Juno and > Kepler). > > If I've missed anything (or, anything unclear) let me me know. > > Most important, in the master branch (for Kepler), I have disabled every > contribution and will require projects to re-enable themselves as a sign they > are intending to participate in Kepler (See bug 365738). > > The bad news is there is a large "order effect" here. For example, EMF and > GEF must re-enable themselves before WTP (or nearly anyone else) could > correctly aggregate. > > The good news is that I put an early "warm-up I build" in for Eclipse and > Equinox (and, yes, enabled them) and from some quick checks, it appears > everyone still builds with the Platform's Kepler M1 (at least, as of right > now, with warm-up) so ... the point is ... many low level projects such as > EMF or GEF could likely re-enable themselves quickly before any new > contributions were made/ready, thereby enabling your consuming projects to > re-enable themselves too. Put another way, there is no reason to wait until > your designated +n day to re-enable yourself, and if you do, it'd likely > complicate getting M1 done. > > This complete the 5 steps outlined in my original note. Transition complete > .... now on to business. > > Both Kepler M1 and Juno RC1 complete the same week (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@eclipse.org>, > Date: 08/06/2012 12:52 AM > Subject: Re: [cross-project-issues-dev] Migrating SimRel files this > weekend to Git > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Just to keep all informed. I have migrated sim rel file to Git > https://bugs.eclipse.org/bugs/show_bug.cgi?id=359240 > > And have the builds working at > https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/ > > But have not yet update any related documentation or "how to" information, > which I will be working on this week and post again when "all done". > https://bugs.eclipse.org/bugs/show_bug.cgi?id=386655 > So, no need to worry about much till then, but ... reserve some time later in > the week for worrying :) > > In the mean time, if you can't resist poking around :) remember that master > of org.eclipse.simrel.build will be for Kepler and the Juno_maintenance > branch will be for Juno SR1. > As before, the resulting p2 repositories for Kepler staging will be > http://download.eclipse.org/releases/staging > while Juno SR1 p2 staging will be at > http://download.eclipse.org/releases/maintenance > > Whew, > > > > > > From: David M Williams/Raleigh/IBM@IBMUS > To: Cross project issues <cross-project-issues-dev@eclipse.org>, > Date: 08/03/2012 01:56 PM > Subject: [cross-project-issues-dev] Migrating SimRel files this > weekend to Git > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Just an FYI that I will be moving the Sim Rel files over to Git this weekend. > It would not really hurt much if you continued to make changes today or > tomorrow ... but, you might have to do them again depending on exact timing. > > The build did get back to runnable state with just one feature disabled and > in communication with the team (SOA BPEL) the person to "really fix" the > issue is still out on holiday. > > So, we will be close to Juno SR0, but probably not exact. > > The hardest part for me this weekend will be updating all the "how to" wiki > pages, etc., so (after Monday) if people see areas I've missed, let me know. > > I'll try to remember to turn off "notifications" as I'm sure a couple of > aggregation builds will fail as I put new system in place, but if you see any > such messages this weekend, you can safely ignore them. > > And, thanks Henrik for the reminder to tag the initial version in Git with > JunoSR0 ... I would have forgotten. The final one in CVS was tagged with > JunoRC4b. > > I'll be off line this afternoon but will check mail and this list before > actually starting the work this evening, so if anyone has any concerns or > questions, feel free to say. > > I'll document 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-project-issues-dev] Kepler initial daze > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > 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 advantage to get those up to date in the next few > days. That is, updating so the "Juno Release" builds again. > > Here's an outline of what is quickly coming up (I propose). > > First, transition to Git. [1] I have been exploring and experimenting with > moving the aggregation files and build to Git and am feeling confident enough > to say we'll do it in about a week. So, at some point, let's say Friday, 8/3, > will be the official "cut off" time for CVS changes. After that, I suspect > there will be a little "down time" while I actually do the move, and get > things working again before it'd make sense to make official changes to your > Git files. So, anything not building by Friday will just be disabled. > > Second, change in aggregation build project name. [1] As we "rethink" this > stuff, as we move to Git, and a new release, it makes sense to change the > name of the projects to a persistent name, that won't change from release to > release, and instead we'll just make persistent branches of those projects. > The name currently proposed for new project will be > "org.eclipse.simrel.builds" which will initially be a "copy" of > "org.eclipse.juno.builds" (done after Friday 8/3). > > Third, right after we migrate to Git, and get the build running again with > those Git repos, we will branch master of "org.eclipse.simrel.builds" to > Juno_maintenance. From that point on, master will be for Kepler and > Juno_maintenance for Juno SR1. I expect this all to happen before Kepler M1 > +0 which is 8/10 [2] (And Juno SR1 aggregation starts shortly after that. > [3] ) > > Fourth, we need the maintenance branch to be able to build at any time ... > so, everyone needs to get and keep that up to date, if anything breaks from > what ever your final release was (which, should be unlikely). But ... > > Fifth, due to some discussions in some bug somewhere [4], it was decided that > as we start a new release, ALL projects will start off disabled in the > aggregation build. The project team will need to re-enable when they are > ready and committed to Kepler, which should be for M1 for those participating > in Juno. That would be by 8/22 at the latest. Anyone in Juno, but not in > Kepler M1 will be assumed to not be participating in Kepler or having some > troubles. Projects new to Kepler (still) have until M4 (at the latest) to > join the train (but, can join earlier, if they'd like!). > > So, a lot is proposed to be happening over the next week. I will keep you > informed along the way, but ... if anyone wants to update your CVS files one > last time, now is the time to do it. > > Comments, suggestions, questions, and your cooperation :) will be most > welcome. > > Thanks, > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=359240 > [2] http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule > [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR1 > [4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=365738 > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > <STG50990>_______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
