Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


On Wed, Jul 3, 2013 at 2:03 PM, Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx> 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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: July-03-13 4:38 PM
To: mike.milinkovich@xxxxxxxxxxx; 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.


On 13-07-03 1:55 PM, "Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>

>> 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 mailing list
cross-project-issues-dev mailing list

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |

Back to the top