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.