Re: [eclipse.org-planning-council] Shorter release cycles (cont...)

[David M Williams <david_williams@xxxxxxxxxx>]

Welcome Max. 

I'd say we don't have a proposal yet,
just an idea that we will develop a proposal. I'd suggest catching up with
the last meeting minutes at 
 https://wiki.eclipse.org/Planning_Council/

... May 6 has the most written down
ideas. 

Other Planning Council members, Red
Hat became a Strategic Member of Eclipse Foundation earlier this month,
and Max will be their representative to the Planning Council. 

Thanks, 




From:      
 "Max Rydahl Andersen"
<manderse@xxxxxxxxxx>
To:      
 "Eclipse Planning
Council private list" <eclipse.org-planning-council@xxxxxxxxxxx>,

Date:      
 05/13/2015 04:13 AM
Subject:    
   Re: [eclipse.org-planning-council]
Shorter release cycles (cont...)
Sent by:    
   eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

I'm joining the planning council and trying to catch
up on the 
discussion.

What is the actual proposal ?

Quarter releases with allowed API breakage sounds like something that 
would
completely destroy our ability to provide compatible versions of our 
plugins
and a killer of an actual working IDE in the community.

But I assume that is not the actual proposal :)

Can anyone point me to details of the current proposal ?

/max

> Well, the realities outside the Eclipse project are very different.
I 
> don’t report to the Tools PMC or the CDT project lead, I report to
a 
> manager at QNX and I get my marching orders from him. Good only comes
> when my manager allows me to work for the interests of the community
> as well as our company.
>
> There are a lot of committers that don’t have such kind bosses and
> lots come and go like the wind as their real bosses direct their work.
> But they contribute where they can and we appreciate what they do
(for 
> the most part) and we’re better off than if we had turned them away.
>
> Anyway, that’s all beside the point. We all agree that projects need
> good leaders that can influence their communities to work together.
> The projects I know about have that so I’m not too worried about
> projects doing the right thing as we open up to the idea of quarterly
> releases. Unless there are a lot that don’t…
>
> Doug
>
> From: Daniel Megert 
> <daniel_megert@xxxxxxxxxx<mailto:daniel_megert@xxxxxxxxxx>>
> Reply-To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Date: Tuesday, May 12, 2015 at 5:08 PM
> To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Subject: Re: [eclipse.org-planning-council] Shorter release cycles
> (cont...)
>
>> On a diverse project, there are many bosses and they don’t report
>> to each other.
> Every project has a lead and a PMC. They must work together. If not,
> something is broken and needs to be fixed or escalated.
>
>> We just need to make sure the projects have strong leadership
to pull 
>> it all together. I just wanted to add the data to the mix.
> Definitely. The prime directive for the projects (leadership) must
be 
> to deliver the best value they can provide to the community. The 
> products/companies can then decide which releases to adopt. This is
> nothing new. For example we at IBM don't consume every release/SR.
We 
> have clearly defined schedules and rely on the open source 
> deliverables. In order to make that work it is essential to have 
> public release plans where projects indicate whether they participate
> in a release with new features or just bug fixes.
>
> Dani
>
>
>
> From:        Doug Schaefer 
> <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>>
> To:        Eclipse Planning Council private list
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Date:        06.05.2015 20:29
> Subject:        Re: [eclipse.org-planning-council]
Shorter release 
> cycles (cont...)
> Sent by:        
> eclipse.org-planning-council-bounces@xxxxxxxxxxx<mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx>
> ________________________________
>
>
>
> Yes, but my scenario was more driven by a committer team that didn’t
> work as a unit. On a diverse project, there are many bosses and they
> don’t report to each other. The train helped me bring the different
> factions together and helped us work as a unit. And ironically enough,
> it was because the releases were yearly and people didn’t want to
> miss it. I kinda loose that hammer if we release too often. You may
> end up with committers taking a release off knowing they can jump
back 
> on for the next release in three months. It’s a strain on the rest
> of the team.
>
> It something we can over come, and sometimes face anyway. We just
need 
> to make sure the projects have strong leadership to pull it all 
> together. I just wanted to add the data to the mix.
>
> Doug.
>
> From: Ian Bull 
> <irbull@xxxxxxxxxxxxxxxxx<mailto:irbull@xxxxxxxxxxxxxxxxx>>
> Reply-To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Date: Wednesday, May 6, 2015 at 2:19 PM
> To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Subject: Re: [eclipse.org-planning-council] Shorter release cycles
> (cont...)
>
> We may want to require projects that wish to release on the train
to 
> publicize their release schedule, and give an appropriate heads-up
for 
> any changes to the schedule. This may help with the scenario Doug
just 
> described, but also help when a component has a lot of consumers on
> the train.
>
> Cheers,
> Ian
>
> On Wed, May 6, 2015 at 11:00 AM, Doug Schaefer 
> <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>>
wrote:
> Indeed a great discussion and again Thank You all for contributing
and 
> being open to the idea. I feel something great coming out of it. :)
>
> First for Ian’s question, yes, one repo at a fixed URL. It’s a 
> requirement I have of my customers to be able to update from release
> to release. Our schedule is somewhat random and driven by other forces
> so they don’t really know which Eclipse Platform release their 
> getting unless they look hard at it. They’d be pretty confused if
> they could upgrade to some but not others.
>
> I also wanted to add a bit of history that not many people know about
> other than long time CDT committers that were around at the time or
> heard my old grampa stories over CDT Summit beers…
>
> Before CDT joined the train, our release strategy was a mess. And
it 
> was really the diversity of our project that caused it. We had two
> major players, I worked for one and I now work for the other (hint,
> hint). One of them had a product based on CDT and that product 
> delivery schedule was driven by the platform it supported. The other
> was trying to release in sync with the Eclipse platform so it could
> feed into the product stack that that company was building on top.
>
> The problem crept up with the two schedules didn’t match. What ended
> up happening was that CDT released every time one of these two stacks
> needed a release. Unfortunately, the committers remained focused  on
> their product release and ended up not helping the other out when
it 
> was time for them to release. In fact, on one famous occasion, the
one 
> who had a few months before their release added a new feature two
> weeks before the other was going to have their release. Luckily we
had 
> great leaders back then and the commit was reverted.
>
> It was a complete mess and as we started to grow committers from 
> different ISVs, we started to ask, do we release every time one of
> them needed a release. That would have been complete chaos. So when
> the idea of the train came along I used the opportunity to standardize
> our releases and there was really little fuss because everyone knew
> that was the right thing to do and the answer was handed to us on
a 
> silver platter.
>
> So while the idea of 3 month cycles is a great advance forward, I
do 
> fear the unintended consequences. If projects aren’t releasing on
> every train release, then they have a decision to make on which 
> releases to release on. And what drives that decision? The old train
> gave us an automatic choice that we didn’t have to think or fuss
> about. Sometimes that’s a good thing.
>
> Doug.
>
> From: Ian Bull 
> <irbull@xxxxxxxxxxxxxxxxx<mailto:irbull@xxxxxxxxxxxxxxxxx>>
> Reply-To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Date: Wednesday, May 6, 2015 at 1:36 PM
> To: Eclipse Planning Council 
> <eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
> Subject: [eclipse.org-planning-council] Shorter release cycles 
> (cont...)
>
> Great discussion today!
>
> I really like the direction we are headed, and the idea of a release
> once per season would make us much more agile.
>
> One technical thing we need to consider is how we will structure the
> repository. Currently we create a new composite repository every each
> (for the June release) and add the SR1 and SR2 when they become 
> available. In the next year, we wipe the slate clean and start again
> with a fresh repository.
>
> If we are moving away from a Release + SR1 + SR2 and moving towards
a 
> rolling release, then I don't think we should clear the repository
> each year. This will make year-to-year updates impossible.
>
> One suggestion is to create a single composite repository, and store
> the latest N releases (N=4?). When N+1 is released we then drop the
> oldest release from list of children (of course we could maintain
the 
> update site forever at a permanent URL -- but that would be part of
> our retention strategy which we have not yet discussed).
>
> Thoughts? And thanks again everyone!
>
> Cheers,
> Ian
>
> --
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
> http://eclipsesource.com<http://eclipsesource.com/>
| 
> http://twitter.com/eclipsesource
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal
> to the Eclipse Foundation.  To be permanently removed from this
list, 
> you must contact emo@xxxxxxxxxxx<mailto:emo@xxxxxxxxxxx>
to request 
> removal.
>
>
>
> --
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
> http://eclipsesource.com<http://eclipsesource.com/>
| 
> http://twitter.com/eclipsesource_______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx<mailto:eclipse.org-planning-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal
> to the Eclipse Foundation.  To be permanently removed from this
list, 
> you must contact emo@xxxxxxxxxxx<mailto:emo@xxxxxxxxxxx>
to request 
> removal.
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal
> to the Eclipse Foundation.  To be permanently removed from this
list, 
> you must contact emo@xxxxxxxxxxx to request removal.


/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.