Re: [cross-project-issues-dev] 6 month release cycle
While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue. Greg On Jul 2, 2013, at 3:30 PM, Doug Schaefer dschae...@qnx.com wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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] 6 month release cycle
+1 We're going to run into this with CDT. We will want to update the package every 6 months as well. From: Greg Watson g.wat...@computer.orgmailto:g.wat...@computer.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 16 July, 2013 4:13 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue. Greg On Jul 2, 2013, at 3:30 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto: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] 6 month release cycle
The download page is driven by the output of the EPP project which builds the packages from the release train repo. A lot of this is automated so I would suggest any change to the release cycle will also need to include how we update this workflow. Ian From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: July-16-13 11:07 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle +1 We're going to run into this with CDT. We will want to update the package every 6 months as well. From: Greg Watson g.wat...@computer.org mailto:g.wat...@computer.org Reply-To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 16 July, 2013 4:13 PM To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle While I support more frequent release cycles (PTP release more frequently so it would suit us well), I'd like to also suggest that projects also have more control over the packages available on the download site. In particular, we'd like to be able to update our package with a new build when we bring out a bug fix release so that new users don't need to update the package as soon as they download it. If you're interested in discussing this more, I've opened bug 412864 on this issue. Greg On Jul 2, 2013, at 3:30 PM, Doug Schaefer dschae...@qnx.com mailto:dschae...@qnx.com wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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
Re: [cross-project-issues-dev] 6 month release cycle
The fact that all the bundles composing packages are included in the release repo and that the ius for the epp are also there. On 2013-07-16, at 8:25 PM, Mickael Istria mist...@redhat.com wrote: On 07/16/2013 08:20 PM, Ian Skerrett wrote: The download page is driven by the output of the EPP project which builds the packages from the release train repo. A lot of this is automated so I would suggest any change to the release cycle will also need to include how we update this workflow. Is there any technical or workflow-related reason that would prevent EPP package from being released more often than release train is ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets ___ 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] 6 month release cycle
On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote: 1. New contributions are piled on, aggregation happens, problems are found and need to be sorted out manually. Meanwhile, aggregation is broken and more contributions pile on. The solution is to remove direct access to aggregation metadata and process one contribution at a time. When a contribution request is made, aggregation is performed. If it fails, the contribution is rejected and the contributing project gets to figure out what's wrong without affecting anyone else. Seems like using Gerrit to process contributions into aggregator would help. However, it means that someone has to review and merge this contributions manually; but if this Gerrit review also triggers a Jenkins build that validates the aggregation (without publishing it), it wouldn't be too difficult to maintain as it would spot some errors early and automatically. 2. Content of contributed repositories changes and some needed repositories are deleted. The result is inability to reproduce aggregation. The solution is policy (projects must not contribute mutating repositories to aggregation) and enforcement (mirroring of contributed repositories). The mirrors can be purged after a certain period when reproducing aggregation older than a certain amount of time is no longer necessary. This is closely related to this discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=331385 . I agree that projects should be forced provide a stable URL with stable content to aggregator. It should be a requirement of the release train. If we use Gerrit and reviews to contribute to aggregator, it's would be a criterion for vetoing a contribution. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
Am 09.07.2013 um 11:41 schrieb Mickael Istria: On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote: 1. New contributions are piled on, aggregation happens, problems are found and need to be sorted out manually. Meanwhile, aggregation is broken and more contributions pile on. The solution is to remove direct access to aggregation metadata and process one contribution at a time. When a contribution request is made, aggregation is performed. If it fails, the contribution is rejected and the contributing project gets to figure out what’s wrong without affecting anyone else. Seems like using Gerrit to process contributions into aggregator would help. However, it means that someone has to review and merge this contributions manually; but if this Gerrit review also triggers a Jenkins build that validates the aggregation (without publishing it), it wouldn't be too difficult to maintain as it would spot some errors early and automatically. A lot of failed builds were caused by missing (suddenly deleted/disappeared) artifacts not by incoming model changes. So autovalidation by Jenkins will probably prevent maintainers to submit a patch which fixes, but depends on the broken master state. So IMHO gerrit would not eliminate the problem in the whole, but can probably make the maintenance not that easy Best regards, Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ 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] 6 month release cycle
I don't see why manual Gerrit reviews would be desirable. Since the only goal here is to ensure that aggregation doesn't break, a successful aggregation pass is enough to prove that the contribution is good. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael Istria Sent: Tuesday, July 09, 2013 2:41 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote: 1. New contributions are piled on, aggregation happens, problems are found and need to be sorted out manually. Meanwhile, aggregation is broken and more contributions pile on. The solution is to remove direct access to aggregation metadata and process one contribution at a time. When a contribution request is made, aggregation is performed. If it fails, the contribution is rejected and the contributing project gets to figure out what's wrong without affecting anyone else. Seems like using Gerrit to process contributions into aggregator would help. However, it means that someone has to review and merge this contributions manually; but if this Gerrit review also triggers a Jenkins build that validates the aggregation (without publishing it), it wouldn't be too difficult to maintain as it would spot some errors early and automatically. 2. Content of contributed repositories changes and some needed repositories are deleted. The result is inability to reproduce aggregation. The solution is policy (projects must not contribute mutating repositories to aggregation) and enforcement (mirroring of contributed repositories). The mirrors can be purged after a certain period when reproducing aggregation older than a certain amount of time is no longer necessary. This is closely related to this discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=331385 . I agree that projects should be forced provide a stable URL with stable content to aggregator. It should be a requirement of the release train. If we use Gerrit and reviews to contribute to aggregator, it's would be a criterion for vetoing a contribution. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
On 07/09/2013 05:24 PM, Konstantin Komissarchik wrote: I don't see why manual Gerrit reviews would be desirable. Since the only goal here is to ensure that aggregation doesn't break, a successful aggregation pass is enough to prove that the contribution is good. A successful aggregation pass is enough to ensure build works once. The Jenkins Gerrit plugin would provide that. A human review would help to ensure that the contribution is good (sustainable URL, stable content, conformance to guidelines). Code review would decrease the amount of failed aggregation builds (because bad URLs would have more difficulties to get in) and would make contributors more aware of what is expected from them. Code review FTW! http://www.benlinders.com/2013/the-economics-of-software-quality/ and http://www.benlinders.com/wp-content/uploads/Business-Benefits-Reviews-Ben-Linders.pdf -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
You missed the second half of my writeup. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael Istria Sent: Tuesday, July 09, 2013 8:43 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle On 07/09/2013 05:24 PM, Konstantin Komissarchik wrote: I don't see why manual Gerrit reviews would be desirable. Since the only goal here is to ensure that aggregation doesn't break, a successful aggregation pass is enough to prove that the contribution is good. A successful aggregation pass is enough to ensure build works once. The Jenkins Gerrit plugin would provide that. A human review would help to ensure that the contribution is good (sustainable URL, stable content, conformance to guidelines). Code review would decrease the amount of failed aggregation builds (because bad URLs would have more difficulties to get in) and would make contributors more aware of what is expected from them. Code review FTW! http://www.benlinders.com/2013/the-economics-of-software-quality/ and http://www.benlinders.com/wp-content/uploads/Business-Benefits-Reviews-Ben-L inders.pdf -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
Konstantin's thought experiment about continuous aggregation is also really interesting. The key problem here is workload - our current aggregation is too error prone, unrepeatable, and time-consuming to add even more aggregations right now. It currently seems to take several full days of someone's time to nurse an aggregation through to successful completion. There is no question in my mind that with a bit of automation, continuous aggregation can be a hands-off operation, taking less effort than what's being expended today. There are two problems with what we are doing today: 1. New contributions are piled on, aggregation happens, problems are found and need to be sorted out manually. Meanwhile, aggregation is broken and more contributions pile on. The solution is to remove direct access to aggregation metadata and process one contribution at a time. When a contribution request is made, aggregation is performed. If it fails, the contribution is rejected and the contributing project gets to figure out what's wrong without affecting anyone else. 2. Content of contributed repositories changes and some needed repositories are deleted. The result is inability to reproduce aggregation. The solution is policy (projects must not contribute mutating repositories to aggregation) and enforcement (mirroring of contributed repositories). The mirrors can be purged after a certain period when reproducing aggregation older than a certain amount of time is no longer necessary. The other question for the continuous aggregation idea is to ask who is the target audience for it. If the goal is to get new features into the hands of users more quickly, then I think using the current nearly-monthly milestone aggregation is the better path. Continuous aggregation doesn't have an audience by itself. You can use continuous aggregation for everything from five year old maintenance stream to a nightly development stream. When continuous aggregation is applied to the latest releases, a key audience is a typical Eclipse user who wants the latest, but doesn't want to mess with problems associated with running development builds (milestones). Running with milestones is more common for developers working on Eclipse plugins than for the broader set of Eclipse users, since plugin developers already have to track those emerging milestone as their development target. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne Sent: Monday, July 08, 2013 11:37 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle There has been some great discussion here, and some similar ideas to what were discussed at the Planning Council F2F earlier this year [1]. Many Eclipse projects are already doing 3-6 or even more releases a year, so ideas about how to bring those together and get them out to end-users are worth talking about. My current view is that we are already slowly evolving from the one feature release a year to three release windows a year (June, September, February). Some projects use those release windows for maintenance, others use them for new feature releases. This makes sense as our projects are very diverse and the needs of different projects' consumer communities differ. We discussed this briefly in last week's Eclipse Project PMC and we currently think the 1+2 rhythm currently works well for the Platform project, but there is nothing stopping other projects from adopting a more frequent feature release cadence. Maybe we need to acknowledge this reality and change the names of the September/February releases to indicate they are not purely service releases (and yes, Spring/Summer/Fall are not the right names either). As for the specific idea of a December release, I admit I'm not wild on it. The last couple of weeks of December is really a poor time to be shipping software, both from perspective of people being on holidays, and from a marketing perspective it's hard to get anyone's attention at that time of year. Perhaps a bit more achievable is moving the September release to end of October, to make it a consistent pattern of release windows every four months. That also lines up nicely around EclipseCon Europe which is a big marketing and education opportunity if you're doing a release at that time of year. Again, not every project would need to use these windows for feature releases. A project could make every second window a feature release and use the in-between ones for maintenance. Or 2 feature releases + 1 maintenance release, etc. Again this is something projects are already moving towards and it is mainly a matter of socializing and outreach about what the Sept/Feb releases are doing. The next natural step from 3 release windows a year would be quarterly releases but this is a bigger step for projects and the community to make. Konstantin's thought
Re: [cross-project-issues-dev] 6 month release cycle
On Mon, 2013-07-08 at 14:37 -0400, John Arthorne wrote: [...] we currently think the 1+2 rhythm currently works well for the Platform project, [...] Being an occasional contributor, I can't disagree more. There is a yearly gap between providing a patch and getting it released. It means that some projects (like CDT) will ship without a fix for an annoying issue (and at least one Fedora will be shipped with a bug). For me it is a wasted time, because the patch could have been verified in the field (if commiters hadn't had time). And corrected if necessary. With CBI, it is easy to do an in-house build on demand. This is an opportunity (inhouse bugfixes may be contributed back) and a threat(it is easier respin builds than contribute a fix) at the same time. Not to mention that waiting a year to get a patch released is *extremely* demotivating. It is almost a show stopper. Eclipse needs contributors. I consider frequent releases to be a prerequisite to being open for contributors. -- Krzysztof Daniel kdan...@redhat.com Red Hat ___ 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] 6 month release cycle
Ideally, all the project tests should be executed - using dependencies from the simultaneous release repository. Also, some checks of the compiled classes should be made (e.g. load them all?), to verify that dependencies in the repository are compatible with those used at compile time. Regards, Alex On Thu, Jul 4, 2013 at 11:36 AM, Ed Willink e...@willink.me.uk wrote: Hi Good point. Perhaps a condition of participation in a Package would be contribution of a very small smoke test plugin that demonstrates that the participant has some plausible activity after installation. These could form the basis of an automated package test that would uncover many missing dependencies. For instance for OCL, I already have tests that do a minimal amount of editor liveness testing on an example project, which gives me some confidence that Xtext is still there in a useable fashion. Regards Ed Willink On 04/07/2013 10:25, Pascal Rapicault wrote: I would go even further, are the current packages really tested anyway? There are probably a couple ppl opening them up to see if things are at the right place but I can't imagine that a heavy testing is done. -Original Message- From: cross-project-issues-dev-**boun...@eclipse.orgcross-project-issues-dev-boun...@eclipse.org[mailto: cross-project-issues-**dev-boun...@eclipse.orgcross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas Hallgren Sent: July-04-13 5:20 AM To: cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle On 2013-07-03 23:42, Ian Bull wrote: While I do think most of this could be automated -- including the creation of the packages -- we need to question if this will inevitably reduce quality. I think quality comes from extensive automated testing and then hands-on usage. A fully automated release process would of course cover the first. So the question is really, do we want our users to do the hands-on testing for us? That in turn, begs the question, aren't we doing that already? Assuming that many projects do, then a more frequent release cycle will actually increase quality, not the opposite. And it shortens the bug-fixing cycle dramatically. - thomas __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3204/6462 - Release Date: 07/03/13 __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://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] 6 month release cycle
On 07/04/2013 11:52 AM, Alexey Panchenko wrote: Ideally, all the project tests should be executed - using dependencies from the simultaneous release repository. Projects are free to execute their tests on output of aggregated repo. The process is technically accessible to any plugin developer: * Take a target Eclipse (for example M7 with everything installed) * Install your tests in this target Eclipse * Use Eclipse test application to run automatically your tests on this platform (./eclipse -application org.eclipse.test.uitestapplication ) IMO, it's the responsability of the project to run those tests, not another step for the aggregation process. This could be a new requirement to signoff before the simultaneous release (By M7 with current yearly approach): Run project tests on a full execution environment. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
Hi On 04/07/2013 10:52, Alexey Panchenko wrote: Ideally, all the project tests should be executed - using dependencies from the simultaneous release repository. NO. Most project tests are to do with project functionality and so should be guaranteed passes on an aggregation. Dependencies on other projects should tested by the ptojects own build. The aggregation tests need only focus on overall integration whereby P2 compromises what is available leading to a completely missing bundle. If every project test ran, the aggregation builds would take forever. Also, some checks of the compiled classes should be made (e.g. load them all?), to verify that dependencies in the repository are compatible with those used at compile time. That's what the smoke test should do. Activate enough classes from enough places to demonstrate no CNFEs. Regards Ed Willink ___ 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] 6 month release cycle
The aggregation tests need only focus on overall integration whereby P2 compromises what is available leading to a completely missing bundle. p2 will never decide to *not* install a bundle just to get the rest to install... Do you have a scenario where this happen? The remediation is about updating or uninstalling the elements that have been explicitely installed and it is *not* about tweaking the ranges that are in the metadata. -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: July-04-13 6:27 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle Hi On 04/07/2013 10:52, Alexey Panchenko wrote: Ideally, all the project tests should be executed - using dependencies from the simultaneous release repository. NO. Most project tests are to do with project functionality and so should be guaranteed passes on an aggregation. Dependencies on other projects should tested by the ptojects own build. The aggregation tests need only focus on overall integration whereby P2 compromises what is available leading to a completely missing bundle. If every project test ran, the aggregation builds would take forever. Also, some checks of the compiled classes should be made (e.g. load them all?), to verify that dependencies in the repository are compatible with those used at compile time. That's what the smoke test should do. Activate enough classes from enough places to demonstrate no CNFEs. Regards Ed Willink ___ 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] 6 month release cycle
On 07/04/2013 12:34 PM, Pascal Rapicault wrote: What you seem to suggest is that a project higher up the stack test against the base. I think that by construct this is true bearing the change of version of the base. Not exactly, what I'm suggesting is that a project run test against *all the content* of the release train installed. Some will be dependencies and are anyway necessary for test to start, some other are independent, and may interact with the project in an unexpected way. Any project contributor takes an Eclipse, installs all Kepler bundles (EGit, Subversive, WTP, m2eclipse, GMF, XText...) with the magic Select All button of p2 installer, then it runs the tests against this huge platform. That's how project can notice, additionally to their acceptance tests validation product functionality, some integration bugs such as conflicting jobs/builders and can guarantee that it works together with the whole release train. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
I don't think this is a workable approach. First, such a test needs to run on all supported platform and jvm combinations, which makes already involved task pretty much impossible to perform, at least for small dev teams like we have in m2e. Second, this won't actually find interoperability problems because in most cases other projects will remain dormant, i.e. you actually have to have projects in git repository in order to see if your plugin works with egit or not. -- Regards, Igor On 2013-07-04 2:43 PM, Mickael Istria wrote: On 07/04/2013 12:34 PM, Pascal Rapicault wrote: What you seem to suggest is that a project higher up the stack test against the base. I think that by construct this is true bearing the change of version of the base. Not exactly, what I'm suggesting is that a project run test against *all the content* of the release train installed. Some will be dependencies and are anyway necessary for test to start, some other are independent, and may interact with the project in an unexpected way. Any project contributor takes an Eclipse, installs all Kepler bundles (EGit, Subversive, WTP, m2eclipse, GMF, XText...) with the magic Select All button of p2 installer, then it runs the tests against this huge platform. That's how project can notice, additionally to their acceptance tests validation product functionality, some integration bugs such as conflicting jobs/builders and can guarantee that it works together with the whole release train. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
Or, we could test packages the old-fashioned way -- by actively getting our community involved and excited about the developer builds. This means Tweeting, blogging, announcing and selling the cool new features that go into the new releases. It's a lot of work, but I'm willing to bet that a large community involvement will be more beneficial than any amount of smoke tests or unit tests. One way the EMO can help out here is to compile New and Noteworthy changelogs from Bugzilla bugs featuring the noteworthy keyword so that, from the main downloads page, we can easily point our users to what's new. In turn, that should compel them to download developer builds. Minimal effort on you, the committer. I've opened http://bugs.eclipse.org/412317 to investigate this further. Denis On 07/04/2013 07:15 AM, Igor Fedorenko wrote: I don't think this is a workable approach. First, such a test needs to run on all supported platform and jvm combinations, which makes already involved task pretty much impossible to perform, at least for small dev teams like we have in m2e. Second, this won't actually find interoperability problems because in most cases other projects will remain dormant, i.e. you actually have to have projects in git repository in order to see if your plugin works with egit or not. -- Regards, Igor On 2013-07-04 2:43 PM, Mickael Istria wrote: On 07/04/2013 12:34 PM, Pascal Rapicault wrote: What you seem to suggest is that a project higher up the stack test against the base. I think that by construct this is true bearing the change of version of the base. Not exactly, what I'm suggesting is that a project run test against *all the content* of the release train installed. Some will be dependencies and are anyway necessary for test to start, some other are independent, and may interact with the project in an unexpected way. Any project contributor takes an Eclipse, installs all Kepler bundles (EGit, Subversive, WTP, m2eclipse, GMF, XText...) with the magic Select All button of p2 installer, then it runs the tests against this huge platform. That's how project can notice, additionally to their acceptance tests validation product functionality, some integration bugs such as conflicting jobs/builders and can guarantee that it works together with the whole release train. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it’s out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. Best regards, Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ 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] 6 month release cycle
On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner dennis.hueb...@itemis.dewrote: All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it’s out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. I like this proposal. IMO releasing often is a good thing. Personally I most often use an M-build of the platform mixed with a recent nightly of those projects I am contributing to in order to experience what's coming in. At $DAYJOB we are releasing every 2 weeks. So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0 and minor releases with SR1, SR2 and an additional one in Dec which doesn't match a release train delivery. If we would get the chance to release more often I'd like to participate in that, though I am not sure if we would be able to create a new release every month so e.g. during vacation time it may happen that we would not ship a new version. -- 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] 6 month release cycle
some more considerations: If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...) Also, in my experience I need to start this process several weeks prior to the planned release. A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release. Thoughts? Am 03.07.2013 09:22, schrieb Matthias Sohn: On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner dennis.hueb...@itemis.de mailto:dennis.hueb...@itemis.de wrote: All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. I like this proposal. IMO releasing often is a good thing. Personally I most often use an M-build of the platform mixed with a recent nightly of those projects I am contributing to in order to experience what's coming in. At $DAYJOB we are releasing every 2 weeks. So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0 and minor releases with SR1, SR2 and an additional one in Dec which doesn't match a release train delivery. If we would get the chance to release more often I'd like to participate in that, though I am not sure if we would be able to create a new release every month so e.g. during vacation time it may happen that we would not ship a new version. -- Matthias ___ 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] 6 month release cycle
IMO, we now have tools (Hudson) to guarantee a good quality for integration build and putting us on the way to rolling release and continuous delivery. For SWTBot, I have to admit that making a release is just a marketing effort in order to make some blog posts and tweets, because of its good test suite, any snapshot which has tests working is better than the last release. It's actually a continuous delivery on the snapshots, and I've already recommended people to use snapshots many times because it's better than previous release and I don't have time to spend on the release right now. Basically, almost every snapshot could become a release when you can trust your test suite. Allowing project to have rolling-release/continuous-delivery was something Andrew already mentioned on the CBI mailing-list, and I think it's a good way to go for some projects. It's all the more true when projects don't have a schedule or a roadmap because they're community-driven, and change when community wants it to change. When it comes to release train, we should understand that as a quality label which is given once a year: being part of release train means that the version of your project you submit does conform to release train requirements/level of quality. It should not (and AFAI Understand, it does not) enforce a schedule for any project: a project that wants 3 releases in one year can do it, and project that did not have a release in previous year can resubmit an older version to release train. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ 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] 6 month release cycle
Hi On 03/07/2013 08:22, Matthias Sohn wrote: I like this proposal. IMO releasing often is a good thing. But... For projects with simple dependencies this should work. However for complex dependencies, occasional stakes in the ground are necessary. Consider Xtext applications. A) Eclipse (itemis) produces the Xtext (compile-time) and run-time B) Eclipse/third party uses Xtext at compile-time to produce an XYZZY editor and tooling depending on the Xtext run-time C) Users install the XYZZY tooling The flexibility of Xtext and DI means that there are backward and forward dependencies between A and B since B was auto-generated against an earlier A but runs on a new A. In practice this means that the Xtext run-time API is very hard to evolve and the users may be forced to use the Eclipse release on which the XYZZY editor was generated by B. As the release cycle gets faster, it will get harder for users to find a common platform for third party tools unless all important tools follow the faster release cycle very promptly. No chance. One could argue that such tight coupling between auto-generated code and run-time is undesirable, but I just use Xtext as an example. I suspect that there are many other projects where auto-generation presents similar challenges. So, Yes, let's have a half-yearly Intermediate Release, but please, still just one Major release per year. Let planned API breakage occur only prior to the last milestone of the Major release. Regards Ed Willink ___ 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] 6 month release cycle
Or it means that the workload on the IP team is spread more regularly throughout the year. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Henrik Rentz-Reichert Sent: July-03-13 3:34 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle some more considerations: If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...) Also, in my experience I need to start this process several weeks prior to the planned release. A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release. Thoughts? Am 03.07.2013 09:22, schrieb Matthias Sohn: On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner dennis.hueb...@itemis.demailto:dennis.hueb...@itemis.de wrote: All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. I like this proposal. IMO releasing often is a good thing. Personally I most often use an M-build of the platform mixed with a recent nightly of those projects I am contributing to in order to experience what's coming in. At $DAYJOB we are releasing every 2 weeks. So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0 and minor releases with SR1, SR2 and an additional one in Dec which doesn't match a release train delivery. If we would get the chance to release more often I'd like to participate in that, though I am not sure if we would be able to create a new release every month so e.g. during vacation time it may happen that we would not ship a new version. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto: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] 6 month release cycle
I like the approach of everybody contributing their latest release to a new kind of repo. However I'm wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don't allow for it. Does the repo contain two versions of GEF or is GMF not included? Now if we step back, the issue I'm describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I'm thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together. The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one. All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable. Finally another thing to consider is which repo would users build against? From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Dennis Hübner Sent: July-03-13 2:57 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. Best regards, Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ 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] 6 month release cycle
Hi P2's remediation is very impressive but unfortunately it is dreadfully slooow. If the repo is not validated, every user is going to have to have a tea break while P2 fixes things up. And if the repo is unvalidated, there will be a lot of fixing up. I would be amazed if P2 could sort out the anarchy. So the users will wait a long time, get given an irritating please confirm this magic solution that excludes your favourite product dialog. Eclipse will become a laughing stock. Regards Ed Willink On 03/07/2013 10:31, Pascal Rapicault wrote: I like the approach of everybody contributing their latest release to a new kind of repo. However Im wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges dont allow for it. Does the repo contain two versions of GEF or is GMF not included? Now if we step back, the issue Im describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However Im thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together. The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one. All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable. Finally another thing to consider is which repo would users build against? From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Dennis Hbner Sent: July-03-13 2:57 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and its out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makesaggregation repositories(look at maven central)valuable. Best regards, Dennis Hbner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Re: [cross-project-issues-dev] 6 month release cycle
For Eclipse as a product it is definitely good to have releases more often. It will lower the entry barrier (patches could find a way in the release in less then a year), and will attract new contributors. BUT at the same time there is Eclipse as a platform, with API compatibility, with service releases and specific change management policies, which is totally different from the Eclipse-As-A-Product. So, maybe the key point is that there is a need for two lines: - release train, kept as it is currently - rolling release - it is a product. rather for users then for developers. New API and features can be withdrawn. -- Krzysztof Daniel kdan...@redhat.com Red Hat ___ 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] 6 month release cycle
What you need to realize is that whether the repo is validated or not, the remediation will still happen when the user try to install something (or install a new version) that is incompatible with what is already installed. For example with this hypothetical scenario: - Imagine the user has the platform and GMF installed with a tight dependency on the platform. When the user decides to install the new version of the platform, then the installed version of GMF is no longer suitable, so the remediation will kick in. This will happen whether the p2 repo the user is installing from is validated or not. This is simply rooted in the fact that the user only wants to install one particular component without any desire to understand the dependencies. The only case where the user would not see any remediation is the check for updates. This is because in Kepler we've improved the logic to look for the highest applicable version of each IU rather than systematically proposing the highest version. I would assume that if we were to really provide frequent updates, then users would use the check for updates. Now on the details of remediation and p2 resolver. I agree that the remediation can be slow, and this is dependent on the number of repos you have enabled. Then there is the uncompressible time it takes to resolve dependencies and figure out the solutions and for this whether the repos are validated or not does not matter. The p2 resolver has been built to deal with inconsistent repository content , and it has been proven to scale by participating in dependency resolver competitions. So to answer your question, you can give a mess of dependency and p2 will still figure out something. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: July-03-13 5:40 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle Hi P2's remediation is very impressive but unfortunately it is dreadfully slooow. If the repo is not validated, every user is going to have to have a tea break while P2 fixes things up. And if the repo is unvalidated, there will be a lot of fixing up. I would be amazed if P2 could sort out the anarchy. So the users will wait a long time, get given an irritating please confirm this magic solution that excludes your favourite product dialog. Eclipse will become a laughing stock. Regards Ed Willink On 03/07/2013 10:31, Pascal Rapicault wrote: I like the approach of everybody contributing their latest release to a new kind of repo. However I'm wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don't allow for it. Does the repo contain two versions of GEF or is GMF not included? Now if we step back, the issue I'm describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I'm thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together. The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one. All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable. Finally another thing to consider is which repo would users build against? From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Dennis Hübner Sent: July-03-13 2:57 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. Best regards, Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431
Re: [cross-project-issues-dev] 6 month release cycle
Hi, Am 03.07.2013 um 00:33 schrieb Henrik Rentz-Reichert h...@protos.de: some more considerations: If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...) Also, in my experience I need to start this process several weeks prior to the planned release. A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release. Thoughts? I wouldn't call it burden but challenges. EMO (aka. Wayne) is already doing a great job of automating and streamlining as much of this as possible. We shouldn't plan our releases based on the process but optimize our process to allow for more frequent releases. +1 to the general idea. Big +1 to the idea of an always current aggregation repo that I can go to and fetch updates from. For me as a user it would be really nice to not track all projects individually. The annual release still makes sense, though. It could become a stable baseline for LTS. -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
Re: [cross-project-issues-dev] 6 month release cycle
I wonder, for those companies that want stability, should they focus on the LTS program where old releases are maintained for long periods of time. I'm of the opinion that the entire stack needs new feature development, at least on the IDE side. We are falling behind the competition and my thinking and hope is that releasing more often would help energize the community. On 13-07-03 6:10 AM, Ed Merks ed.me...@gmail.com wrote: Releasing more often sounds like a good thing in principle and of course projects are free to do so as they wish. One major concern I'd have about the release train itself releasing more often is the long ramp down cycle appearing twice as often per year. Of course the M/RC phase would need to be shorted, but then the question is, why is it currently so long? I expect the answer if to provide quality and stability, so would that inevitably suffer as a result? That would be a bad thing... Another question we must ask is what's best for the consumers/adopters? On the one hand, I imagine for projects with very active feature development, many of their consumers do want the latest and greatest as often as possible. On the other hand, I also imagine that a great many commercial adopters see quality and stability as their primary criteria for adoption and hence see more value in SR1 and SR2 releases of a stable base that's focused primarily on quality improvements compared to all the new feature development, which is almost inevitably associated with lower quality. On 03/07/2013 11:44 AM, Krzysztof Daniel wrote: For Eclipse as a product it is definitely good to have releases more often. It will lower the entry barrier (patches could find a way in the release in less then a year), and will attract new contributors. BUT at the same time there is Eclipse as a platform, with API compatibility, with service releases and specific change management policies, which is totally different from the Eclipse-As-A-Product. So, maybe the key point is that there is a need for two lines: - release train, kept as it is currently - rolling release - it is a product. rather for users then for developers. New API and features can be withdrawn. ___ 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] 6 month release cycle
I wonder, for those companies that want stability, should they focus on the LTS program where old releases are maintained for long periods of time. The LTS program is in no way intended to be a replacement for the simultaneous release. ___ 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] 6 month release cycle
Glad to see interest in my frequent aggregation proposal. To answer some of the questions that were raised... 1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room for milestones or IP team to do their work. Projects would release at whatever pace makes sense to them, set their own schedules and leave room for IP team to do their work. Some would continue to release yearly, some would be on a six month cycle, some would release even more frequently. The aggregation stream would only accept a finished release. In fact, given enough automation, the aggregation can become continuous. Suppose that instead of the current system where projects edit stuff in Git, there is a portal where projects contribute their release. Verification runs automatically, if it fails, the contribution is rejected. No more missing about.html files! The tool can also be available on verify only basis for projects wishing to check their release candidates. 2. What happens if there is a dependency conflict? For instance, if GEF pushes a new release, but the contributed GMF release still depends on the old version. We would very likely need to allow multiple versions in the repository for frequent aggregation to work. Perhaps only the latest version is categorized. 3. Should the aggregated repository be verified? Yes. The primary value of the aggregated repository is that there is a version of each component that can be installed together. If we don't verify at aggregation time, we will lose that feature. However, with multiple versions being present, the verification would need to be different. Instead of verifying if everything can be installed together, it should verify if a solution exists such that at least one version of each component can be installed with everything else. 4. What about LTS and others who want more stability. Do we still need the current release train for that? Not really. Let's call what I've described the latest stream. Periodically, the latest stream can be branched to create a stable stream of a given vintage. Projects can still contribute to the stable stream, but the rules are different (stricter). On the opposite end, we could also have a dev stream, where projects can contribute their latest milestone builds, integration builds, etc. 5. What would I build against? Projects should be tracking the release plans of their dependencies and build directly against the repositories published by their dependencies. Building against any aggregation stream is risky since you never know which version you are building against and you lose ability to reproduce your build. Thanks, - Konstantin ___ 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] 6 month release cycle
How often do the Eclipse packages get build and tested and what appears on the Eclipse download page? On 13-07-03 12:02 PM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: Glad to see interest in my frequent aggregation proposal. To answer some of the questions that were raised... 1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room for milestones or IP team to do their work. Projects would release at whatever pace makes sense to them, set their own schedules and leave room for IP team to do their work. Some would continue to release yearly, some would be on a six month cycle, some would release even more frequently. The aggregation stream would only accept a finished release. In fact, given enough automation, the aggregation can become continuous. Suppose that instead of the current system where projects edit stuff in Git, there is a portal where projects contribute their release. Verification runs automatically, if it fails, the contribution is rejected. No more missing about.html files! The tool can also be available on verify only basis for projects wishing to check their release candidates. 2. What happens if there is a dependency conflict? For instance, if GEF pushes a new release, but the contributed GMF release still depends on the old version. We would very likely need to allow multiple versions in the repository for frequent aggregation to work. Perhaps only the latest version is categorized. 3. Should the aggregated repository be verified? Yes. The primary value of the aggregated repository is that there is a version of each component that can be installed together. If we don't verify at aggregation time, we will lose that feature. However, with multiple versions being present, the verification would need to be different. Instead of verifying if everything can be installed together, it should verify if a solution exists such that at least one version of each component can be installed with everything else. 4. What about LTS and others who want more stability. Do we still need the current release train for that? Not really. Let's call what I've described the latest stream. Periodically, the latest stream can be branched to create a stable stream of a given vintage. Projects can still contribute to the stable stream, but the rules are different (stricter). On the opposite end, we could also have a dev stream, where projects can contribute their latest milestone builds, integration builds, etc. 5. What would I build against? Projects should be tracking the release plans of their dependencies and build directly against the repositories published by their dependencies. Building against any aggregation stream is risky since you never know which version you are building against and you lose ability to reproduce your build. Thanks, - Konstantin ___ 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] 6 month release cycle
On the flip side, we need to evaluate the benefits of more frequent releases to see if it's worth it. Completely agree. My assumption is that some projects will want to ship more often, and some will not. We have a large community, and one size rarely fits all. A strategy that can accommodate differing requirements will be necessary. ___ 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] 6 month release cycle
Just wondering here... but since LTS has the a goal of having a set of set points in time (the existing releases) that is maintained into the future, doesn't it make sense to have LTS be the primary stakeholder for the entire simultaneous release concept (maybe they are?) and then if, as Doug is calling for here, there was interest in a more fast moving, ideally generally bug free but sometimes glitchy IDE experience then folks can download and update their editor based on that stream? And have a durable update repository that isn't getting smoked, renamed, or what have you that people can just use for years on end. A bit like how ubuntu lets you have your stable and unstable streams that you can keep updated from As for version resolution...I thought one of the points of osgi was to allow multiple runtime versions of stuff to coexist so from a repository perspective, let them update whatever they want and downstream projects that trust their upstreams can have open version ranges and those that don't can take a more deliberate approach. I am aware I am probably trivializing much of the osgi experience there, but really...from a users perspective of Eclipse (which I am speaking from) I would like to just be able to flip a switch in the IDE and have it notify me of updates, download in the background and either update automagically or restart the IDE as needed and not care about adding p2 update repo this for that thing or download Milestone X or Y or whatever... cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jul 3, 2013 at 11:53 AM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: On the flip side, we need to evaluate the benefits of more frequent releases to see if it's worth it. Completely agree. My assumption is that some projects will want to ship more often, and some will not. We have a large community, and one size rarely fits all. A strategy that can accommodate differing requirements will be necessary. ___ 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] 6 month release cycle
but since LTS has the a goal of having a set of set points in time (the existing releases) that is maintained into the future, doesn't it make sense to have LTS be the primary stakeholder for the entire simultaneous release concept (maybe they are?) The Planning Council is currently responsible for defining and running the simultaneous release process. LTS currently relies upon the existence of a simultaneous release as its starting point. The LTS working group would be a very poor replacement for the Planning Council in running the simultaneous release. For example, one of the major features of the Planning Council is that it has representation on it from each of the PMCs. The LTS working group steering committee does not. ___ 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] 6 month release cycle
ok, fair enough...but if the LTS has been investing so much time and effort into building a process for being able to release updates to simultaneous releases, will they assume that burden from the Planning Council eventually? No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem. Will that effort be rolled back into the simultaneous release process that the Planning Council currently takes care of? At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes. My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon. maybe a slight off topic, if so my apologies No problem at all. For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help. ___ 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] 6 month release cycle
Successful aggregation would trigger packages build. Different packages should be able to build in parallel. The new repo and packages are pushed out on the download site at the end of the monthly cycle. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Wednesday, July 03, 2013 9:29 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle How often do the Eclipse packages get build and tested and what appears on the Eclipse download page? On 13-07-03 12:02 PM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: Glad to see interest in my frequent aggregation proposal. To answer some of the questions that were raised... 1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room for milestones or IP team to do their work. Projects would release at whatever pace makes sense to them, set their own schedules and leave room for IP team to do their work. Some would continue to release yearly, some would be on a six month cycle, some would release even more frequently. The aggregation stream would only accept a finished release. In fact, given enough automation, the aggregation can become continuous. Suppose that instead of the current system where projects edit stuff in Git, there is a portal where projects contribute their release. Verification runs automatically, if it fails, the contribution is rejected. No more missing about.html files! The tool can also be available on verify only basis for projects wishing to check their release candidates. 2. What happens if there is a dependency conflict? For instance, if GEF pushes a new release, but the contributed GMF release still depends on the old version. We would very likely need to allow multiple versions in the repository for frequent aggregation to work. Perhaps only the latest version is categorized. 3. Should the aggregated repository be verified? Yes. The primary value of the aggregated repository is that there is a version of each component that can be installed together. If we don't verify at aggregation time, we will lose that feature. However, with multiple versions being present, the verification would need to be different. Instead of verifying if everything can be installed together, it should verify if a solution exists such that at least one version of each component can be installed with everything else. 4. What about LTS and others who want more stability. Do we still need the current release train for that? Not really. Let's call what I've described the latest stream. Periodically, the latest stream can be branched to create a stable stream of a given vintage. Projects can still contribute to the stable stream, but the rules are different (stricter). On the opposite end, we could also have a dev stream, where projects can contribute their latest milestone builds, integration builds, etc. 5. What would I build against? Projects should be tracking the release plans of their dependencies and build directly against the repositories published by their dependencies. Building against any aggregation stream is risky since you never know which version you are building against and you lose ability to reproduce your build. Thanks, - Konstantin ___ 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] 6 month release cycle
But it is quite scary we're relying on individuals performing manual tasks to get the releases out. I hope that we can automate more of what they do. The beauty of Maven/Tycho/Hudson is that you can automate everything from source to download pages. We talk of the big red button, it would be great if that's all it was. Agreed, which was the lionshare of intent behind my questions regarding LTS assuming some of that role :) cheers, jesse D On 13-07-03 1:55 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: ok, fair enough...but if the LTS has been investing so much time and effort into building a process for being able to release updates to simultaneous releases, will they assume that burden from the Planning Council eventually? No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem. Will that effort be rolled back into the simultaneous release process that the Planning Council currently takes care of? At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes. My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon. maybe a slight off topic, if so my apologies No problem at all. For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help. ___ 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] 6 month release cycle
This was also the reason why I was suggesting that those new repos were not validated so we did not have to take on somebody else's time and it could be a simple mirror repo. I've been doing a similar work internally at Ericsson and automating most of it, but the handling of the b3 aggregation file is sometimes not that trivial (nothing against the tool but rather the dependencies of the IUs). As for the packages, I would say that these don't need to be released every time since they require alignment between all the components. The other thing that I'm wondering is whether we need a release date for this new repo. After all, why not just add project as they become available? -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: July-03-13 4:38 PM To: mike.milinkov...@eclipse.org; Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle Agree on David and Markus's time. These guys make the releases happen and are heavily under appreciated and over stressed. But it is quite scary we're relying on individuals performing manual tasks to get the releases out. I hope that we can automate more of what they do. The beauty of Maven/Tycho/Hudson is that you can automate everything from source to download pages. We talk of the big red button, it would be great if that's all it was. D On 13-07-03 1:55 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: ok, fair enough...but if the LTS has been investing so much time and effort into building a process for being able to release updates to simultaneous releases, will they assume that burden from the Planning Council eventually? No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem. Will that effort be rolled back into the simultaneous release process that the Planning Council currently takes care of? At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes. My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon. maybe a slight off topic, if so my apologies No problem at all. For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help. ___ 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] 6 month release cycle
This is exactly the type of conversation we need to be having. Thanks Konstantin for the out-of-box thinking and everyone else for great ideas / feedback. I think no matter what we do, we still need 'service releases' or multiple streams, but there is nothing here that precludes that. While I do think most of this could be automated -- including the creation of the packages -- we need to question if this will inevitably reduce quality. If packages are just a random collection of everyones latest stuff, automatically built on a monthly basis, we can't give much (if any) guarantee about the quality of those integrations. The original proposal included 'testing the release', but I don't think the package maintainers can be expected to test each package each month on each platform. This type of release also means we can't ramp-down as a group. As soon as some teams start to stabilize their integrations, someone else will undoubtedly release something new. Maybe we can address these issues by having a few of these monthly builds get promoted as 'Package Releases'. This is a great time to be having this conversation. Thank-you Doug for starting it! The planning council is not meeting this month, but I'll summarize the issues and bring them forward in August (although there are several PC members who have already commented). In the mean-time, please keep this conversation going. Cheers, Ian On Wed, Jul 3, 2013 at 2:03 PM, Pascal Rapicault pascal.rapica...@ericsson.com wrote: This was also the reason why I was suggesting that those new repos were not validated so we did not have to take on somebody else's time and it could be a simple mirror repo. I've been doing a similar work internally at Ericsson and automating most of it, but the handling of the b3 aggregation file is sometimes not that trivial (nothing against the tool but rather the dependencies of the IUs). As for the packages, I would say that these don't need to be released every time since they require alignment between all the components. The other thing that I'm wondering is whether we need a release date for this new repo. After all, why not just add project as they become available? -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto: cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: July-03-13 4:38 PM To: mike.milinkov...@eclipse.org; Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle Agree on David and Markus's time. These guys make the releases happen and are heavily under appreciated and over stressed. But it is quite scary we're relying on individuals performing manual tasks to get the releases out. I hope that we can automate more of what they do. The beauty of Maven/Tycho/Hudson is that you can automate everything from source to download pages. We talk of the big red button, it would be great if that's all it was. D On 13-07-03 1:55 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: ok, fair enough...but if the LTS has been investing so much time and effort into building a process for being able to release updates to simultaneous releases, will they assume that burden from the Planning Council eventually? No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem. Will that effort be rolled back into the simultaneous release process that the Planning Council currently takes care of? At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes. My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon. maybe a slight off topic, if so my apologies No problem at all. For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help. ___ 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
Re: [cross-project-issues-dev] 6 month release cycle
Just out of curiousity, is there a reason why people keep mentioning monthly, when there is a long-established 6-week cadence? Maybe we can address these issues by having a few of these monthly builds get promoted as 'Package Releases'. ___ 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] 6 month release cycle
I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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] 6 month release cycle
Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases. D From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [ifedore...@sonatype.com] Sent: Tuesday, July 02, 2013 3:49 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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] 6 month release cycle
One of the things we need to understand is *what do we want from a release train?* 1. Is it simply a release of the latest and greatest stuff Eclipse has? 2. Is it a set of plugins / components that are known to 'work together'? 3. Is it a co-ordinated marketing exercise? 4. Is it a snap-shot in time of what we have? 5. Is it something else? There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix match approaches. I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train. Doug, in the case of CDT, could you consider M4 M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)? Just a few more questions to hopefully help drive the discussion :-) Cheers, Ian On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko ifedore...@sonatype.comwrote: I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource ___ 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] 6 month release cycle
What's the point of releasing often if there are no new features? -- Regards, Igor On 2013-07-02 11:56 PM, Doug Schaefer wrote: Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases. D From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [ifedore...@sonatype.com] Sent: Tuesday, July 02, 2013 3:49 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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] 6 month release cycle
Spurring on the development of new features is part of what's driving this. Only the early adopters ever download milestone builds and we're trying to be more agile to a larger audience by going twice as often. D On 13-07-02 4:17 PM, Igor Fedorenko ifedore...@sonatype.com wrote: What's the point of releasing often if there are no new features? -- Regards, Igor On 2013-07-02 11:56 PM, Doug Schaefer wrote: Funny, that came up in our conversation too. Years ago, M releases were awesome. They always had new features and the quality was pretty good. But then the quality stopped being so good and there were less features, so people cared less about M releases. And that has left a long period of time where people really care about Eclipse releases. D From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [ifedore...@sonatype.com] Sent: Tuesday, July 02, 2013 3:49 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle I agree, one year is way too long. I am not even sure 6 months is often enough. We had three m2e releases between Juno and Kepler, and I consider m2e mature, (relatively) low-activity project. At the same time, I never use R builds myself, I always use M-builds as primary development environment for my $DAY_JOB. I don't suggest we do full-blown release every 6 weeks, but maybe there is a way to elevate perceived status of M builds such that users are more comfortable using them. -- Regards, Igor On 2013-07-02 11:30 PM, Doug Schaefer wrote: Hey gang, We have a discussion going in the CDT community and we are currently planning out how to achieve a 6 month release cycle. The feeling is that we need to get new features out faster to our users. The year long wait we currently have is making releases sluggish and I fear it's slowing down growth in our community. A 6 month cycle should infuse us with a little more energy, so goes the hope. I mentioned CDT's plans on twitter and a number of senior members of our larger Eclipse community thought it might be a good idea for other projects at Eclipse and maybe for the train itself. And I think so too. Instead of continuing that discussion on twitter, which is fun and everything, I thought we should bring that to a greater audience and see what other projects thought and whether it's something we should bring to the Planning Council and the rest of the EMO. I know there are a number of projects already releasing off stream during the year, but bringing things together more often might be a help to many others. But I'd like to hear your thoughts on that. Doug. ___ 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] 6 month release cycle
We're still debating what to do with the SR-2. The proposal was an early conservative one that was aimed to appease the community that doesn't want to live on the bleeding edge. Egit, you pretty much have to live on the bleeding edge since it's still pushing some basic features that everyone needs. But I could see us forgoing SR-2 altogether at some point and release the Dec CDT release at SR-2 time. I just think releasing random lineups every 4 months as somewhat happens now with those projects doesn't give you that focus on producing a known line-up that just works (and as we all know, we have had issues with Egit just landing randomly in a release cycle). SR testing is much lighter than release testing from my experience. From: Ian Bull irb...@eclipsesource.commailto:irb...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 2 July, 2013 5:03 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle The schedule you propose is interesting Doug. Two things stand out -- Your december release only has a one SR. (There is no 8.3.2). The second thing is that you plan on maintaining your June (Kepler) contribution in Feb (Kepler SR2). This is fine, but this is the opposite of what others have done. EGit (and Mylyn too, I think) have released new versions with the SRs. I'm not going judge what's better, but I don't like the fact that they are different. For example, the February 2014 will potentially have the latest and greatest EGit and a maintenance release of CDT after a new release was just announced. Combine that with the milestone stream that will undoubtedly be moving forward and our users will be hit with a confusing set of available sites from which to find their software. Also, what version of the CDT will be available in the MarketPlace next February? I'm not picking on anybody here. I think this demonstrates that we need to do something regarding multiple releases per year, and I'm doing my best do understand the different constraints we have. Cheers, Ian On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com wrote: Thanks Ian, to answer your questions: We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features. We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues. Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet. We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available. From: Ian Bull irb...@eclipsesource.commailto:irb...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Tuesday, 2 July, 2013 4:08 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle One of the things we need to understand is what do we want from a release train? 1. Is it simply a release of the latest and greatest stuff Eclipse has? 2. Is it a set of plugins / components that are known to 'work together'? 3. Is it a co-ordinated marketing exercise? 4. Is it a snap-shot in time of what we have? 5. Is it something else? There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix match approaches. I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train. Doug, in the case of CDT, could you consider M4 M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)? Just a few more questions
Re: [cross-project-issues-dev] 6 month release cycle
It goes back to the primary goal behind simrel. The original goal was to synchronize the releases and aggregation was secondary. With some projects wishing to release more frequently and some projects slowing down, perhaps the primary focus should be on aggregation rather than synchronizing everyone's schedule. Suppose for a minute that we ran the aggregation process monthly. All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull Sent: Tuesday, July 02, 2013 2:04 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle The schedule you propose is interesting Doug. Two things stand out -- Your december release only has a one SR. (There is no 8.3.2). The second thing is that you plan on maintaining your June (Kepler) contribution in Feb (Kepler SR2). This is fine, but this is the opposite of what others have done. EGit (and Mylyn too, I think) have released new versions with the SRs. I'm not going judge what's better, but I don't like the fact that they are different. For example, the February 2014 will potentially have the latest and greatest EGit and a maintenance release of CDT after a new release was just announced. Combine that with the milestone stream that will undoubtedly be moving forward and our users will be hit with a confusing set of available sites from which to find their software. Also, what version of the CDT will be available in the MarketPlace next February? I'm not picking on anybody here. I think this demonstrates that we need to do something regarding multiple releases per year, and I'm doing my best do understand the different constraints we have. Cheers, Ian On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer dschae...@qnx.com wrote: Thanks Ian, to answer your questions: We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features. We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues. Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet. We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available. From: Ian Bull irb...@eclipsesource.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org Date: Tuesday, 2 July, 2013 4:08 PM To: Cross project issues cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] 6 month release cycle One of the things we need to understand is what do we want from a release train? 1. Is it simply a release of the latest and greatest stuff Eclipse has? 2. Is it a set of plugins / components that are known to 'work together'? 3. Is it a co-ordinated marketing exercise? 4. Is it a snap-shot in time of what we have? 5. Is it something else? There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix match approaches. I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train. Doug, in the case of CDT, could you consider M4 M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)? Just a few more questions to hopefully help drive the discussion :-) Cheers, Ian
