Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

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 <nyssen@xxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx




Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev <kaloyan.r@xxxxxxxx>:

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-bounces@xxxxxxxxxxx<cross-project-issues-dev-bounces@xxxxxxxxxxx> on behalf of Alexander Nyßen <nyssen@xxxxxxxxx>
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 <ed@xxxxxxxxxxxxx>:

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-bounces@xxxxxxxxxxx<cross-project-issues-dev-bounces@xxxxxxxxxxx>on behalf of Ed Willink <ed@xxxxxxxxxxxxx>
Sent:
Tuesday, August 9, 2016 3:20:07 PM
To:
cross-project-issues-dev@xxxxxxxxxxx
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-bounces@xxxxxxxxxxx<cross-project-issues-dev-bounces@xxxxxxxxxxx>on behalf of Ed Willink <ed@xxxxxxxxxxxxx>
Sent:
Monday, August 8, 2016 8:39:57 PM
To:
cross-project-issues-dev@xxxxxxxxxxx
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 <ed@xxxxxxxxxxxxx>
To:        
cross-project-issues-dev@xxxxxxxxxxx,
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-bounces@xxxxxxxxxxx




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.nyssen@xxxxxxxxx

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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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.nyssen@xxxxxxxxx

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@xxxxxxxxxxx
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.nyssen@xxxxxxxxx

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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top