From my point of view, here are a couple of observations.
This is not a new requirement or procedure, we have done it this way for
several releases.
We used to "do it" (that is, disable contributions) at M4 if projects had
not yet declared intent or filed a release record, and there was an equal
amount complaining about "why now? My contribution has been working all
along and now it is broken because some dependency was disabled because
there is suddenly something new someone has to do". So, better to be M1,
rather than M4, IMHO.
Another part of the problem: there seems to by a "myth" that projects
merely have declare intent and have a release record, period. Not true.
You must also contribute to the build.
Another part of the problem: projects seem to think their dependencies are
all aware of the issue and will fix themselves eventually. I do not know
why, but that seems not to be the case. So, I suggest if you are waiting
on a dependency, to let them know, either though their dev list or open a
bug on them. It is always true that you are responsible for communicating
to the projects you depend on, letting them know what you need, etc. That
is still the case here.
Another part of the problem: projects seem to think that their +n day is
THE day they should contribute. Not true. It is the LAST day they can
contribute (with out announcing here on cross-project list). As a
practical workflow, once projects "declare", they should enable what ever
they have at that point, even if later on, on their LAST day to
contribute, they update their contribution. And this is true every
milestone. A "warm-up" contribution is always a good idea before making
your final contribution.
A possible part of the problem: Some projects may think their "release
record" needs to be accompanied by a "complete plan". This is not true. If
you have one, fine. But the projects release plan is something that can
and should be updated "as you go" since it is bound to change as
development progresses.
The only issue we do not account for well is when a "whole team" is on
vacation or working with a client for the entire months of July and August
(keeping in mind, some teams are one or two people) -- but, seems to me
that part of a well ran project is to know what deadlines are coming up
and to plan accordingly -- perhaps have a backup person submit the change,
open a bugzilla/Gerrit patch asking that someone else contribute it, since
their release engineer or project lead is absent.
Perhaps too part of the problem is that some projects do not understand
the reasoning for "disabling everyone" and so they stubbornly ignore M1
since it is not important to them. The reason it is important to "us" (the
Planning Council) to disable the projects and request projects declare and
enable themselves is that we have few ways to know if a project has become
inactive or disfunctional. So this is one modest attempt to make sure the
project is functional enough to at least "declare" and "contribute to a
build".
And, lastly, yes, M1 is often a rather poor milestone, from a Simultaneous
Release point of view.
I am sure improvements can be made, but the key -- from my point of view
-- is that projects smooth out their processes and dependencies, rather
than "the big guy in the sky" blindly makes everything work just fine for
everyone by making a lot of assumptions that may or may not be accurate.
To force something positive out of this difficult period of time, it does
give projects an opportunity to think through your dependencies and if you
really want or have to depend on them. For one, completely made up
example, what would you do if "UML Project" decided not to participate any
more? What if it was "terminated"? What is your contingency plan? Does
something need to be refactored? Made optional? Or, perhaps even move to
some other project?
I hope at least some of these comments are constructive. Spread the word.
(And open some bugs if you are waiting on someone).
From: Alexander Nyßen <nys...@itemis.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>,
Date: 08/09/2016 10:14 AM
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
Sent by: cross-project-issues-dev-boun...@eclipse.org
Hi Kaloyan,
Am 09.08.2016 um 15:55 schrieb Kaloyan Raev <kaloya...@zend.com>:
I really miss the root cause of the issue…
I don't understand how does it help breaking the SimRel build now and
hoping everything will be fine by the end of tomorrow.
I also do not think that breaking the build to enforce downstream
contributions is the way to go, as it blocks all contributions via Gerrit.
As far as I understand, there are a few projects that depend on each
other. Is there any cycle in the dependency graph?
Even if there is no cycle (which could well be on the level of projects),
there are several downstream dependencies (Ed and I have already pointed
out two).
We are not building the Oxygen SimRel from scratch. It is based on the
Neon state.
No, it isn’t. The Neon contributions are all disabled by default.
What have changed so significantly during Oxygen M1 so these project
cannot stage their contributions incrementally?
Nothing. Because of the downstream dependencies that exist, there is a lot
of bootstrapping required for M1. As the Neon contributions are disabled,
enabling a feature can only be performed after all prerequisites have been
contributed to M1. This is the root cause...
Kaloyan
Regards,
Alexander
From: cross-project-issues-dev-boun...@eclipse.org <
cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander Nyßen
<nys...@itemis.de>
Sent: Tuesday, August 9, 2016 4:38:00 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only
partially today
I also fear that without enabling the Neon contributions the bootstrapping
is not to be done. We are virtually postponing it all to Wednesday, when
we will have to perform a piece-by-piece integration (probably on the
level of individual features), hoping that all projects actually
contribute something. GEF for instance depends on e(fx)clipse and Xtext,
which - if I recollect correctly - have not even stated their intention to
participate in Oxygen. I am keeping my fingers crossed...
Regards
Alexander
Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk>:
Hi
Co-ordination would be good, but we have a new policy whose consequences
do not seem to have been appreciated.
Indeed it is +2, and I see no successful +1 contributions. Just GEF that
enabled a Neon contribution to reduce its small contribution to the
overall deadlock.
Regards
Ed Willink
On 09/08/2016 13:27, Kaloyan Raev wrote:
Hi Ed,
Can't all these projects coordinate and make the necessary contributions
within a short time frame without leaving master broken for a long time?
It's already M1 +2 date and the rest of the projects should be able to do
their contributions.
Kaloyan
From: cross-project-issues-dev-boun...@eclipse.org
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink
<e...@willink.me.uk>
Sent: Tuesday, August 9, 2016 3:20:07 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only
partially today
Hi
Feel free, but we have a policy problem.
The earlier discussion was on Xtext dependencies.
The build is currently failing because OCL depends on UML2 which is
missing.
Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is
missing.
We therefore have three choices.
Green all the way: No contribution is enabled till ALL prerequisites are
enabled. This will be very slow because of the recursive dependencies,
because relengs are not super-responsive, because it is August, because
some projects never contribute at M1, and because M1 used to be two rather
than one weeks long.
Red till green: contribute as normal, so that the validator identifies the
missing contributions.
The old way. Neon contributions are enabled by default.
I think the old way was better, but given that we are improving, I see
contribution enabling as appropriate so that the missing contributions are
highlighted.
AFAIAA all OCL's dependencies have declared intent so OCL can be enabled
and that is what I have done.
Regards
Ed Willink
On 09/08/2016 13:09, Kaloyan Raev wrote:
Hi folks,
I don't want to break the party, but your recent changes, pushed directly
to master, broke the validation build. Thus, everyone else who follow the
clean process of contributing via Gerrit is blocked at the moment.
I am going to revert the last changes one by one until I get a clean
validation build.
Please contribute your next changes via Gerrit.
Thanks,
Kaloyan
From: cross-project-issues-dev-boun...@eclipse.org
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink
<e...@willink.me.uk>
Sent: Monday, August 8, 2016 8:39:57 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only
partially today
Hi
XText has declared intent. XText releases asynchronously, so it is very
likely that Xtext 2.10 crosses the boundary.
It seems unhelpful that you have inhibited aggregation contributions just
because the XText releng has not realized how much trouble your
enabled=false is causing.
I'll enable OCL so that things improve as soon as XText and friends
appear.
Regards
Ed Willink
On 08/08/2016 18:27, David M Williams wrote:
> Can we have the Neon contributions available as in previous years?
Projects can do that, if they want -- as long as it is still "fits in".
But it is up to the project. They need to "declare intent" and provide a
release record, AND THEN re-enable what every contribution they want to
make.
Thanks,
From: Ed Willink <e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org,
Date: 08/08/2016 12:13 PM
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
Sent by: cross-project-issues-dev-boun...@eclipse.org
Hi
OCL too cannot be enabled until Xtext is enabled.
I feel that this attempt to bootstrap from nothing is going to make for
some very tight late coordination.
Can we have the Neon contributions available as in previous years?
If enabled="false" is required to enforce announced participation, surely
it would be better to apply it just after M2 to all projects that have
made no SimRel commit since Neon?
Regards
Ed Willink
On 08/08/2016 16:34, Alexander Nyßen wrote:
Hi all,
I have just re-enabled the GEF repository for Oxygen and made available
the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to
enable downstream projects that depend on it. The GEF (formerly known as
GEF4) contribution to M1 is already prepared as well, but I had to disable
it for now because it depends on downstream projects (namely e(fx)clipse
and Xtext) that have not updated their contributions yet. GEF will thus
not be available today but on Wednesday.
Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nys...@itemis.de
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nys...@itemis.de
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nys...@itemis.de
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino
[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
