> 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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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 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. Part of this can probably be removed through better tooling and automation, but some of it may be the natural cost of getting so many millions of lines of fast moving open source code lined up, built, and tested. I think we need to improve infrastructure+process before we can increase how often we release aggregated content.
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. This gets new features out even faster, and also means that users get exposure to features early enough that projects can incorporate feedback before it is too late. The Chrome/Firefox Beta channel concept is very popular with developers - they are eager to get their hands on new stuff and are often willing to sacrifice a bit on quality to get it. The Eclipse community is much smaller but I still think there would be interest if we get the word out and set the right expectations. Personally I am never using anything older than the last milestone and overall stability is quite good.
On the other hand if the target audience for continuous aggregation is commercial adopters, I think it is much less valuable. What commercial adopters really value is the schedule alignment, and whether there is an aggregate repository and EPP packages or not is a relatively minor concern. Anyone building against Eclipse would likely not want to target a repository that is shifting every month in unpredictable ways - they generally want to control the timing of adoption by consuming from the individual repositories of single project releases.
Anyway, that was a bit more verbose and rambling than I intended, but that's my current input to the discussion...
John
[1] http://wiki.eclipse.org/Planning_Council/March_24_2013#Release_train_rhythm
From: Doug Schaefer <dschaefer@xxxxxxx>
To: "cross-project-issues-dev@xxxxxxxxxxx" <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 07/02/2013 03:31 PM
Subject: [cross-project-issues-dev] 6 month release cycle
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
