Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Shorter release cycles (cont...)

On 13 May 2015, at 14:32, Doug Schaefer wrote:

Hey Max, glad you guys have joined.

As a quick summary, the suggestion was to release minor releases more
often. I originally proposed 6 months, David then came back with 3 which we are currently debating. Also thrown in by John is the concept of one of
those releases being an LTS release likely once a year.

Can you tell me how these are any different from just adding more SR releases and allow
more than 2 SR's if there are interest for it ?

(This is what I would actually like to see - SR's that tries to be as API compatible as possible, can get bug fixes but also don't exclude option of adding new features if it does not break API)

/max

We didn¹t discuss major releases but we can do that now but it would make sense that we only allow major releases on the LTS release. Though that
would be counter intuitive since an LTS release should be high quality
that a major release might not give you right away. But we do currently
have that rule where you can release minor releases on an SR and only
major releases in June.

Anyway, that¹s the plan. We need to think of all the unintended
consequences of all this before making an official proposal.

Doug.

On 2015-05-13, 8:21 AM, "Max Rydahl Andersen" <manderse@xxxxxxxxxx> wrote:

On 13 May 2015, at 13:52, David M Williams wrote:

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.

Thanks! I'll read up on it and come back after the bank holidays here -
so Monday ;)

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.

I was actually looking at sending a delegate, but then this topic about
changing release cycles came up so I stepped in for now.

Thanks,
/max

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.

_______________________________________________
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.

_______________________________________________
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


Back to the top