Re: [cross-project-issues-dev] Question on Kepler SR1 release review
On Wed, Aug 14, 2013 at 10:08 AM, simone.seu...@sungard.com wrote: Hi everybody, ** ** because it is our first service release I just wanted to check if a service release is also processed like the yearly major release. Do we have to follow [1] and [2] or is there a different process? ** ** Sorry if I overlooked something in the documentation and thanks for the help in advance. ** ** Simone ** ** [1] http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Process [2] http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews*** * AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
I'll take this topic as a good segue to summarize Planning Council's view on more frequent releases and including new features in SRs. I'll try to keep in brief, but anyone is welcome to read my full notes of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 First, it was recognized our slow pace was not satisfying all projects and adopters, but ... Second, it was satisfying most, so the short answer is status quo continues ... though we committed to continue the discussion for the long term. Its just that no one knew of any easy answers that could be implemented easily, without requiring more work from everyone. The status quo is captured in our current policy statement, at http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F In fact, it turns out several strategic adopting members were surprised we allow new features at all ... and wanted the emphasis to stay on bug fixes and quality improvements in the SRs, and to not be surprised by new features. So, we humbling ask projects to announce and summarize here on cross-project list when they are adding new features and when minor versions increment. We definitely want to allow projects to add new features when they need to, based on the needs of their community and adopters ... but don't want to encourage experiments with new features that might not be fully baked yet. So, we'll stick with the restrictions that new releases must be released a month before RC1 and be in RC1, as our policy states. This does not prevent any project from having a new release anytime you want but might mean you can not contribute it to Simultaneous Release maintenance. Hope this helps adds clarity to the current rules for Simultaneous Release maintenance. Thanks, From: Gunnar Wagenknecht gun...@wagenknecht.org To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 08:55 AM Subject:Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by:cross-project-issues-dev-boun...@eclipse.org Am 14.08.2013 um 02:41 schrieb Matthias Sohn matthias.s...@gmail.com: AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. Yes, this is correct. Technically, a pure maintenance (aka. service) releases changes only the 'x' of 'a.b.x' version string. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org ___ 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
Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ... and SR1 reminders
Hi David, is there any chance we can get http://download.eclipse.org/releases/luna/ populated with the platform+jdt before m1? Thanks, Marcel On Aug 14, 2013, at 5:04 PM, David M Williams david_willi...@us.ibm.com wrote: Hi David, could you please update the corresponding google calendar? I've imported the linked iCal file, but can't find any Luna milestones entries. Best regards, Dennis. I have updated the Google Calendar for the reset of this year (through Luna M4) ... you can see there is overlap between Kepler SR1 and Luna M2 ... so please plan accordingly. https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.comctz=America/New_York I'll update the rest after Planning Council formally approves it. Our SR1 RC1 is coming up soon. While it is considered a warm-up please make sure your latest service contributions are in and working, since, shortly after that we have a pretty short runway to the final SR1. http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#SR1 Thanks, ___ 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
Is new releases must be released a month before SR RC1 a new requirement? -- Regards, Igor On 2013-08-14 6:53 PM, David M Williams wrote: I'll take this topic as a good segue to summarize Planning Council's view on more frequent releases and including new features in SRs. I'll try to keep in brief, but anyone is welcome to read my full notes of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 First, it was recognized our slow pace was not satisfying all projects and adopters, but ... Second, it was satisfying most, so the short answer is status quo continues ... though we committed to continue the discussion for the long term. Its just that no one knew of any easy answers that could be implemented easily, without requiring more work from everyone. The status quo is captured in our current policy statement, at http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F In fact, it turns out several strategic adopting members were surprised we allow new features at all ... and wanted the emphasis to stay on bug fixes and quality improvements in the SRs, and to not be surprised by new features. So, we humbling ask projects to announce and summarize here on cross-project list when they are adding new features and when minor versions increment. We definitely want to allow projects to add new features when they need to, based on the needs of their community and adopters ... but don't want to encourage experiments with new features that might not be fully baked yet. So, we'll stick with the restrictions that new releases must be released a month before RC1 and be in RC1, as our policy states. This does not prevent any project from having a new release anytime you want but might mean you can not contribute it to Simultaneous Release maintenance. Hope this helps adds clarity to the current rules for Simultaneous Release maintenance. Thanks, From: Gunnar Wagenknecht gun...@wagenknecht.org To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 08:55 AM Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by: cross-project-issues-dev-boun...@eclipse.org Am 14.08.2013 um 02:41 schrieb Matthias Sohn matthias.s...@gmail.com: AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. Yes, this is correct. Technically, a pure maintenance (aka. service) releases changes only the 'x' of 'a.b.x' version string. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org ___ 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
Yeah actually that doesn't make sense. Why have the release sit around for a month instead of fixing bugs in it right to the end of the SR? Sent from my BlackBerry 10 smartphone on the Rogers network. From: Igor Fedorenko Sent: Wednesday, August 14, 2013 11:24 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Is new releases must be released a month before SR RC1 a new requirement? -- Regards, Igor On 2013-08-14 6:53 PM, David M Williams wrote: I'll take this topic as a good segue to summarize Planning Council's view on more frequent releases and including new features in SRs. I'll try to keep in brief, but anyone is welcome to read my full notes of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 First, it was recognized our slow pace was not satisfying all projects and adopters, but ... Second, it was satisfying most, so the short answer is status quo continues ... though we committed to continue the discussion for the long term. Its just that no one knew of any easy answers that could be implemented easily, without requiring more work from everyone. The status quo is captured in our current policy statement, at http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F In fact, it turns out several strategic adopting members were surprised we allow new features at all ... and wanted the emphasis to stay on bug fixes and quality improvements in the SRs, and to not be surprised by new features. So, we humbling ask projects to announce and summarize here on cross-project list when they are adding new features and when minor versions increment. We definitely want to allow projects to add new features when they need to, based on the needs of their community and adopters ... but don't want to encourage experiments with new features that might not be fully baked yet. So, we'll stick with the restrictions that new releases must be released a month before RC1 and be in RC1, as our policy states. This does not prevent any project from having a new release anytime you want but might mean you can not contribute it to Simultaneous Release maintenance. Hope this helps adds clarity to the current rules for Simultaneous Release maintenance. Thanks, From: Gunnar Wagenknecht gun...@wagenknecht.org To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 08:55 AM Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by: cross-project-issues-dev-boun...@eclipse.org Am 14.08.2013 um 02:41 schrieb Matthias Sohn matthias.s...@gmail.com: AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. Yes, this is correct. Technically, a pure maintenance (aka. service) releases changes only the 'x' of 'a.b.x' version string. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org ___ 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
Its new as of last April. And, by all means ... fix bugs and then submit a maintenance release for final version (which would not need a new release). Released, in this context, means the formal Eclipse process of having been through the required release review which is always required of new releases. From: Doug Schaefer dschae...@qnx.com To: cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org, cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org, Date: 08/14/2013 11:33 AM Subject:Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by:cross-project-issues-dev-boun...@eclipse.org Yeah actually that doesn't make sense. Why have the release sit around for a month instead of fixing bugs in it right to the end of the SR? Sent from my BlackBerry 10 smartphone on the Rogers network. From: Igor Fedorenko Sent: Wednesday, August 14, 2013 11:24 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Is new releases must be released a month before SR RC1 a new requirement? -- Regards, Igor On 2013-08-14 6:53 PM, David M Williams wrote: I'll take this topic as a good segue to summarize Planning Council's view on more frequent releases and including new features in SRs. I'll try to keep in brief, but anyone is welcome to read my full notes of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 First, it was recognized our slow pace was not satisfying all projects and adopters, but ... Second, it was satisfying most, so the short answer is status quo continues ... though we committed to continue the discussion for the long term. Its just that no one knew of any easy answers that could be implemented easily, without requiring more work from everyone. The status quo is captured in our current policy statement, at http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F In fact, it turns out several strategic adopting members were surprised we allow new features at all ... and wanted the emphasis to stay on bug fixes and quality improvements in the SRs, and to not be surprised by new features. So, we humbling ask projects to announce and summarize here on cross-project list when they are adding new features and when minor versions increment. We definitely want to allow projects to add new features when they need to, based on the needs of their community and adopters ... but don't want to encourage experiments with new features that might not be fully baked yet. So, we'll stick with the restrictions that new releases must be released a month before RC1 and be in RC1, as our policy states. This does not prevent any project from having a new release anytime you want but might mean you can not contribute it to Simultaneous Release maintenance. Hope this helps adds clarity to the current rules for Simultaneous Release maintenance. Thanks, From: Gunnar Wagenknecht gun...@wagenknecht.org To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 08:55 AM Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by: cross-project-issues-dev-boun...@eclipse.org Am 14.08.2013 um 02:41 schrieb Matthias Sohn matthias.s...@gmail.com: AFAIK if you want to release a pure maintenance release (only bugfixes, no new features) you don't need a release review, if you want to ship new features you need the review. Yes, this is correct. Technically, a pure maintenance (aka. service) releases changes only the 'x' of 'a.b.x' version string. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org ___ 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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation
Does anyone know if CDT will be enabled for M1? We can't enable PTP without CDT. Thanks, Greg On Aug 9, 2013, at 10:06 AM, David M Williams david_willi...@us.ibm.com wrote: I hope everyone has enjoyed their summer vacations ... but now back to work! :) We do have a preliminary schedule for Luna milestones, see http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule (though, that one table is only part of that document to review, at the moment). The complete schedule is still open for review and tweaking, but the first several milestones are pretty much a given, and the first one is due in two weeks! The overall schedule (of having approximately 6 week milestones) is pretty much just like previous years. The one main difference is that we moved up M5 and M6 to make sure M6 finished before EclipseCon 2014 started (so ... we don't allow an extra week for end-of-year holidays) and this M5 and M6 change means M7 is a week longer than usual: 8 weeks instead of 7! As always, we hope everyone in 'kepler' stays in 'luna', but ... to make sure ... we require explicit buy in. In practice, this means I started the 'master' branch with what ever it was for Kepler, but then set enabled=false for everyone's contribution. If you plan to be in Luna, please removed the enabled=false from your contribution element. If you are not quite ready to actually make a contribution, you can put enabled=false in your repository element to signify the difference of planning to participate, but contribution not ready yet. If nothing else, you may simply have to wait until your pre-reqs make their contributions. I have enabled the contributions for Eclipse and Equinox (with out likely Luna M1 content), and produced a preliminary staging repo ... which has only those two projects in it, at the moment. Let the fun begin! As always, questions to this list are welcome. ___ 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
Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ... and SR1 reminders
Can you elaborate? Using m2e as an example, what repositories am I supposed to use to resolve jdt, xml editor and emf dependencies needed to build m2e Luna M1? -- Regards, Igor On 2013-08-14 7:33 PM, David M Williams wrote: Nope. If you need that ... sounds like you are doing something wrong :) From: Marcel Bruch marcel.br...@codetrails.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 11:30 AM Subject: Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ...and SR1 reminders Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David, is there any chance we can get _http://download.eclipse.org/releases/luna/_populated with the platform+jdt before m1? Thanks, Marcel On Aug 14, 2013, at 5:04 PM, David M Williams _david_willi...@us.ibm.com_ mailto:david_willi...@us.ibm.com wrote: Hi David, could you please update the corresponding google calendar? I've imported the linked iCal file, but can't find any Luna milestones entries. Best regards, Dennis. I have updated the Google Calendar for the reset of this year (through Luna M4) ... you can see there is overlap between Kepler SR1 and Luna M2 ... so please plan accordingly. _ __https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.comctz=America/New_York_ I'll update the rest after Planning Council formally approves it. Our SR1 RC1 is coming up soon. While it is considered a warm-up please make sure your latest service contributions are in and working, since, shortly after that we have a pretty short runway to the final SR1. _ __http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#SR1_ Thanks, ___ cross-project-issues-dev mailing list_ __cross-project-issues-dev@eclipse.org_ mailto: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
Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ... and SR1 reminders
What I typically do, is follow the 'dev list' of the projects we rely on. There, most projects announce where particular builds or repos are and when ready. And, if not, you can ask there. Such as for Eclipse, we always announce on several lists, one being 'eclipse-dev' http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09633.html Orbit is similar, http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg03447.html (though admittedly, there you actually have to look at the download page, to find the repository name ... but there is a very predictable pattern). Occasionally, we communicate with pre-req projects via bugzilla. For example, we in Platform do that with EMF, since there is a subset of EMF that we in platform need to be stable, before the rest of EMF is (you know, we have one of the special relationships where we depend on them, and they depend on us :) ... yet we are +0 and they are +1, as a whole. For examples, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=414969 https://bugs.eclipse.org/bugs/show_bug.cgi?id=414968 Ideally, it is best not to wait until the final build to build against ... but to occasionally move up to a weekly I-build, for those projects that provide them, since most projects know to make few changes as they near a milestone, so you can get a sneak peek if there will be any surprises in the final milestone build. Hope that helps, perhaps others have other tips? From: Igor Fedorenko ifedore...@sonatype.com To: cross-project-issues-dev@eclipse.org, Date: 08/14/2013 12:33 PM Subject:Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ... and SR1 reminders Sent by:cross-project-issues-dev-boun...@eclipse.org Can you elaborate? Using m2e as an example, what repositories am I supposed to use to resolve jdt, xml editor and emf dependencies needed to build m2e Luna M1? -- Regards, Igor On 2013-08-14 7:33 PM, David M Williams wrote: Nope. If you need that ... sounds like you are doing something wrong :) From: Marcel Bruch marcel.br...@codetrails.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/14/2013 11:30 AM Subject: Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ...and SR1 reminders Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David, is there any chance we can get _http://download.eclipse.org/releases/luna/_populated with the platform+jdt before m1? Thanks, Marcel On Aug 14, 2013, at 5:04 PM, David M Williams _david_willi...@us.ibm.com_ mailto:david_willi...@us.ibm.com wrote: Hi David, could you please update the corresponding google calendar? I've imported the linked iCal file, but can't find any Luna milestones entries. Best regards, Dennis. I have updated the Google Calendar for the reset of this year (through Luna M4) ... you can see there is overlap between Kepler SR1 and Luna M2 ... so please plan accordingly. _ __https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.comctz=America/New_York_ I'll update the rest after Planning Council formally approves it. Our SR1 RC1 is coming up soon. While it is considered a warm-up please make sure your latest service contributions are in and working, since, shortly after that we have a pretty short runway to the final SR1. _ __http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#SR1_ Thanks, ___ cross-project-issues-dev mailing list_ __cross-project-issues-dev@eclipse.org_ mailto: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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ... and SR1 reminders
Wouldn't say need :-) Recommenders 2.0 milestones is enabled. On Aug 14, 2013, at 5:33 PM, David M Williams david_willi...@us.ibm.com wrote: Nope. If you need that ... sounds like you are doing something wrong :) From:Marcel Bruch marcel.br...@codetrails.com To:Cross project issues cross-project-issues-dev@eclipse.org, Date:08/14/2013 11:30 AM Subject:Re: [cross-project-issues-dev] Ready for Luna (M1) aggregation ...and SR1 reminders Sent by:cross-project-issues-dev-boun...@eclipse.org Hi David, is there any chance we can get http://download.eclipse.org/releases/luna/ populated with the platform+jdt before m1? Thanks, Marcel On Aug 14, 2013, at 5:04 PM, David M Williams david_willi...@us.ibm.com wrote: Hi David, could you please update the corresponding google calendar? I've imported the linked iCal file, but can't find any Luna milestones entries. Best regards, Dennis. I have updated the Google Calendar for the reset of this year (through Luna M4) ... you can see there is overlap between Kepler SR1 and Luna M2 ... so please plan accordingly. https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.comctz=America/New_York I'll update the rest after Planning Council formally approves it. Our SR1 RC1 is coming up soon. While it is considered a warm-up please make sure your latest service contributions are in and working, since, shortly after that we have a pretty short runway to the final SR1. http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#SR1 Thanks, ___ 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
Re: [cross-project-issues-dev] Decommissioning of maven.eclipse.org
Woops apparently I misread my calendar, I meant to say *August* 30th 2013. Thanh On 14/08/13 03:04 PM, Thanh Ha wrote: Hi Everyone, Per bug 405750 [1] I'd like to take a look into decommissioning maven.eclipse.org soon. We now have repo.eclipse.org and several projects have already been publishing their artifacts there. At the moment I'm aiming to do this at the end of this month around September 30th 2013 but if this would be an issue for any projects please let us know. As far as I can tell the only artifacts that seem like they may affect any projects is 2 plugins from the dash project which have not been deployed to repo.eclipse.org: - eclipse-maven-signing-plugin - eclipse-signing-maven-plugin If your project uses either of these plugins this may affect you when we take the server offline. The CBI project also provides a signing plugin called the eclipse-jarsigner-plugin which is available on repo.eclipse.org and I would recommend you switch to using this plugin if this is the case. A README of how to use the plugin can be found here [2]. Thanh [1] https://bugs.eclipse.org/405750 https://bugs.eclipse.org/bugs/show_bug.cgi?id=405750 [2] http://git.eclipse.org/c/cbi/org.eclipse.cbi.maven.plugins.git/tree/README ___ 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
On 8/14/2013 3:15 PM, Doug Schaefer wrote: I don't remember that being the decision. Another thing that doesn't work with projects that want to ship more often and want to update the corresponding EPP package with that release. At the risk of overstating things, I don't think the Planning Council equally represents the interests of the many projects that participate in the simultaneous release. That is, I would say that the interests of the larger, more well-established projects and their consumers (e.g. platform, strategic developers, etc) are overrepresented on the Planning Council, and this has resulted in decisions that are counter to the increasing needs for innovation from newer/smaller projects...e.g. to ship more often, provide more innovation in tooling/IDE, have fewer 'must have' SR requirements because of resource limitations, etc. I don't want these comments to be construed as a criticism of chair David Williams, or even of the existing Planning Council. IMHO, the problem is more structural. Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
I tend to agree with this. A more representative simrel governance body would be leads of all participating projects. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Scott Lewis Sent: Wednesday, August 14, 2013 3:42 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review On 8/14/2013 3:15 PM, Doug Schaefer wrote: I don't remember that being the decision. Another thing that doesn't work with projects that want to ship more often and want to update the corresponding EPP package with that release. At the risk of overstating things, I don't think the Planning Council equally represents the interests of the many projects that participate in the simultaneous release. That is, I would say that the interests of the larger, more well-established projects and their consumers (e.g. platform, strategic developers, etc) are overrepresented on the Planning Council, and this has resulted in decisions that are counter to the increasing needs for innovation from newer/smaller projects...e.g. to ship more often, provide more innovation in tooling/IDE, have fewer 'must have' SR requirements because of resource limitations, etc. I don't want these comments to be construed as a criticism of chair David Williams, or even of the existing Planning Council. IMHO, the problem is more structural. Scott ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
