Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
> In the past those were picked up automatically. I may have missed it, but is that no longer true? Correct. No longer true. There were some concerns by some that we'd "accidentally" include projects that were no longer participating. (And, there were a few cases, where we were doing that for 5 or 6 milestones). https://bugs.eclipse.org/bugs/show_bug.cgi?id=365738 Since we can't automate the whole thing now (the Portal flag, and the build enablement) the compromise was to disable everyone to start with. Your Juno data is still be there in your file though, so for most projects, its just a matter of someone from the project removing the enabled="false" attribute. We'll take that as as your affirmation. Anyone in Juno, but not in Kepler M1 will be assumed to not be participating in Kepler or having some troubles. Thanks, From: Doug Schaefer To: Cross project issues , Date: 08/07/2012 03:58 PM Subject: Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git Sent by:cross-project-issues-dev-boun...@eclipse.org Kepler should work with our Juno bits. In the past those were picked up automatically. I may have missed it, but is that no longer true? From: Greg Watson Reply-To: Cross project issues Date: Tuesday, 7 August, 2012 2:12 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git 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 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: 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 , Date:08/06/2012 12:52 AM Subject:Re: [cross-project-issues-dev] Migrating SimRel files this weekendtoGit 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/Repos
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
Kepler should work with our Juno bits. In the past those were picked up automatically. I may have missed it, but is that no longer true? From: Greg Watson mailto:g.wat...@computer.org>> Reply-To: Cross project issues mailto:cross-project-issues-dev@eclipse.org>> Date: Tuesday, 7 August, 2012 2:12 PM To: Cross project issues mailto:cross-project-issues-dev@eclipse.org>> Subject: Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git 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 mailto:ed.me...@gmail.com>> To:David M Williams/Raleigh/IBM@IBMUS, Cc:dennis.hueb...@itemis.de<mailto: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: 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 <mailto:cross-project-issues-dev@eclipse.org>, Date:08/06/2012 12:52 AM Subject:Re: [cross-project-issues-dev] Migrating SimRel files this weekendtoGit Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto: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: Dav
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 > To: Cross project issues , > Date: 08/07/2012 02:16 PM > Subject:Re: [cross-project-issues-dev] Migrating SimRel files this > weekendto 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 > 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: > > > 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, >
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 To: Cross project issues , 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 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: 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 , Date: 08/06/2012 12:52 AM Subject:Re: [cross-project-issues-dev] Migrating SimRel files this weekendtoGit 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 o
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 > 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: > > > 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 , > Date:08/06/2012 12:52 AM > Subject:Re: [cross-project-issues-dev] Migrating SimRel files this > weekendtoGit > 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 , > Date:08/03/2012 01:
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 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: 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 , Date: 08/06/2012 12:52 AM Subject: Re: [cross-project-issues-dev] Migrating SimRel files this weekendtoGit 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 , Date: 08/03/2012 01:56 PM Subject:[cross-project-issues-dev] Migrating SimRel files this weekend toGit 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
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 , 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 , Date: 08/03/2012 01:56 PM Subject: [cross-project-issues-dev] Migrating SimRel files this weekend toGit 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
Re: [cross-project-issues-dev] Migrating SimRel files this weekend to Git
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 , 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 break
[cross-project-issues-dev] Migrating SimRel files this weekend to Git
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-proj
