Re: [cross-project-issues-dev] Question on Kepler SR1 release review
I certainly missed this decision (and no, as a small opensource project m2e does not have our planning counsel representative). Does the same release one month prior to RC1 rule apply to SR0 in June? If SR0 is treated differently, do you know/remember why? -- Regards, Igor On 2013-08-14 7:39 PM, David M Williams wrote: 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
If SR0 is treated differently, do you know/remember why? Maybe I'm missing your real question, but SR0 is a new release, by definition. Everyone expects new features there, and the release reviews are scheduled as a whole in advance, and there are deadlines for IP Reviews, etc., established well in advance of the actual release ... and we all hope everyone does have a rampdown plan even for SR0, though we don't police it. But, SR1 and SR2 are still defined to be Service Releases, and if someone has enough new things that it requires yet another release review, seems reasonable it be done well in advance since most are not expecting new features or minor upgrades, only service field upgrades. Its a balancing act to allow projects to add new features to a service release, yet still the kind of quality and stability users and adopters expect from a service release. I hope that gets at what you were asking. Let me know if I'm missing your question. From: Igor Fedorenko ifedore...@sonatype.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/15/2013 03:02 AM Subject:Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by:cross-project-issues-dev-boun...@eclipse.org I certainly missed this decision (and no, as a small opensource project m2e does not have our planning counsel representative). Does the same release one month prior to RC1 rule apply to SR0 in June? If SR0 is treated differently, do you know/remember why? -- Regards, Igor On 2013-08-14 7:39 PM, David M Williams wrote: 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
Re: [cross-project-issues-dev] Question on Kepler SR1 release review
as a small opensource project m2e does not have our planning counsel representative. Ah, I did miss this implied question. I believe m2e is a member of the Technology PMC, so your planning representative is Chris Aniszczyk. See following reference for complete list. http://www.eclipse.org/org/foundation/council.php#planning From: Igor Fedorenko ifedore...@sonatype.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 08/15/2013 03:02 AM Subject:Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by:cross-project-issues-dev-boun...@eclipse.org I certainly missed this decision (and no, as a small opensource project m2e does not have our planning counsel representative). Does the same release one month prior to RC1 rule apply to SR0 in June? If SR0 is treated differently, do you know/remember why? -- Regards, Igor On 2013-08-14 7:39 PM, David M Williams wrote: 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
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] 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] 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
