Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Stephan Herrmann]

Thanks, Ed, for raising these concerns.

The thread is already at a volume which makes it hard to digest, I can only hope 
I got the essence of what everybody is thinking.



One way I could interpret the situation is: It takes a very small number of 
qualified people to herd the train - full-time, and then the immediate issue is 
resolved. There are member companies for whom it should not be a problem to fund 
the one appointed train master - perhaps via the foundation. I'd love to see 
Ed's efforts to be compensated in a way which would allow him to give us a long 
term perspective. I don't represent a member company so I can't comment on 
whether and how this simple idea could be put to action.



I assume all of us subscribed to cross-projects have a shared interest in 
providing to our users plenty of options of which software they want to install, 
in various combinations, and all in the latest and greatest version. Without bad 
surprises on their way.
Please, those who want to do away with SimRel: tell me, what efforts are 
incurred by SimRel that or not essential for this original goal? If SimRel 
incurs non-essential efforts, produces accidental complexity, shouldn't we just 
name these, so we can fix things (process? automation?). (Disclaimer: I don't 
care about packages because a simrel repo + various oomph setups are all I need 
to get the Eclipses I want, or to push the same to colleagues in the company). 
(Disclaimer 2: I don't hate the cbi aggregator, I prefer to fix it when there's 
a problem).



For a thought experiment wrt the release cadence: is it possible our cadence is 
still too slow? Imagine a truly continuous SimRel. Perhaps, SimRel contributions 
should happen *always*, i.e., whenever a project has any code changes, or 
buffered to once per day. Some contributions will break downstream projects, 
which have the option to react, or drop out after 3 build failures. If your 
dependency drops out, you will notice immediately. Some version bumps, 
dependency changes will need coordination, here on cross-projects, but they will 
just happen at their own timing, not driven by release dates. In a world where 
so many tasks can be automated, isn't the continues flow of all seeing each 
others HEAD the simplest model of all?


In this model, SimRel (or should we call it SimFlow) would concentrate on 
ensuring that our components stay on track wrt compatibility with each other. 
The other concern about more regressions due to shorter cycles and no 
maintenance branch would still need to be discussed but that's probably a 
different discussion. That discussion could well suggest a much slower cadence, 
but perhaps that is even possibly *on top* of a continues SimFlow.



Just brain storming ...

Stephan


___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Wayne Beaton]

My apologies if I've missed something important... I haven't had a chance
to read through this entire thread.

I'd like to clarify that the Eclipse Planning Council has been removed from
the Eclipse Foundation Bylaws, but it has not been eliminated. It is in the
hands of the Planning Council to sort out how they operate now that they
are no longer governed by the bylaws. I agree that, given the breadth of
technology and work areas that folks are now engaged in at the Eclipse
Foundation, it no longer makes sense to have appointees from all top-level
projects and strategic members (this is actually one of the reasons why the
Planning Council was removed from the bylaws).

Wayne


On Wed, Jan 29, 2020 at 1:32 PM Aleksandar Kurtakov 
wrote:

>
>
> On Wed, Jan 29, 2020 at 8:06 PM Daniel Megert 
> wrote:
>
>> I'm -1 to change the release schedule. Yes, there are probably more bugs
>> but there are also more features *and* bug fixes that our users get more
>> frequently.
>>
>> One important thing that was not mentioned so far is the role of the
>> Planning Council where the stakeholders (strategic members and PMCs)
>> discuss and decide on the schedule. This can for sure not go to EPP unless
>> the current council is part of the EPP leadership.
>
>
> IMHO EPP (incl. SimRel)  shouldn't be mixed with Planning Council - it
> should be governed as every other project. Planning Council should be more
> of a cross project collaboration place. I would also question the need for
> Strategic members and PMCs having a vote on EPP (even less being in the
> leadership) unless the member in question actually does something in the
> EPP project.
> As much as this might sound like blasphemy we will fail to attract people
> taking over some duties if there are multiple abstract bodies dictating
> what/how to be done. I know that I (personally) for sure would not sign up
> in such a case. Having people that actually know what/how/why is done or at
> least are interested in helping some area would be more than welcome but
> having people from a PMC that failed to do proper release for couple of
> years or just being appointed by some company seems pointless. And my
> Planning Council experience shows that such people never actually attended
> even less discussed anything at the meetings and this makes me even more
> convinced that giving every strategic member and PMC EPP leadership would
> be totally wrong move.
>
>
>>
>> For me the thing we must preserve is the p2 repo and the installer.
>> Package are also nice/useful but not my top priority.
>>
>> Dani
>>
>>
>>
>> From:Gunnar Wagenknecht 
>> To:Cross project issues 
>> Date:29.01.2020 15:25
>> Subject:[EXTERNAL] Re: [cross-project-issues-dev] [WARNING]
>> SimRel Headed Off theTracks
>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>> --
>>
>>
>>
>> > On Jan 29, 2020, at 12:44, Sebastian Zarnekow <
>> sebastian.zarne...@gmail.com> wrote:
>> >
>> > But in general, the current release cadence puts too much of a burden
>> on the shoulders of all maintainers.
>>
>>
>> As a project lead contributed to the train in the past and as a package
>> maintainer, I truly disagree with the "too much of a burden" claim being
>> raised here. Once you got all the things in place and compliant I don't
>> ever recall it being a problem to put out new bits. 98% of it was automated
>> anyway. It was push on Jenkins. The other 2% was bureaucracy in the portal.
>>
>>
>> > Platform and JDT used to be rock solid with the annual releases. Now we
>> see more releases but also more bugs and complains from users as far as I
>> can tell. Most of the people that I'm talking too are no longer confident
>> in the quality of the release. For them it's nowadays a tradeoff between
>> the bugs the suffer from and know of vs the bugs they will suffer from but
>> don't know yet.
>>
>> There is some truth here but it really isn't that bad. I'd like to raise
>> two things on the positive side, though.
>>
>> 1. The quality is in my subjective impression on par with - if not better
>> - than the six-weeks milestone releases Eclipse had previously.
>> 2. I don't have to wait for a full year till I'm able to consume a fix.
>>
>> Yes, I do face a few bugs. Some of them are annoying. But I'd challenge
>> if they are really a result of the faster release cadence *or* a result of
>> funding downsizing in involved development teams.
>>
>>
>> > > Also annual releases will resurrect a number of "service releases"
>> with all the effort required,
>> >
>> > And with the quality gains. Exactly.
>>
>> You will only see quality gains *if* the projects are willing to invest
>> into maintaining a service branch. I have the impression that it's easier
>> for the active projects to simply fix things in main/master and don't worry
>> about back porting (which can double work).
>>
>>
>> In the past the SimRel had its clear purpose. It was a big win for the
>>

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Aleksandar Kurtakov]

On Wed, Jan 29, 2020 at 8:06 PM Daniel Megert 
wrote:

> I'm -1 to change the release schedule. Yes, there are probably more bugs
> but there are also more features *and* bug fixes that our users get more
> frequently.
>
> One important thing that was not mentioned so far is the role of the
> Planning Council where the stakeholders (strategic members and PMCs)
> discuss and decide on the schedule. This can for sure not go to EPP unless
> the current council is part of the EPP leadership.


IMHO EPP (incl. SimRel)  shouldn't be mixed with Planning Council - it
should be governed as every other project. Planning Council should be more
of a cross project collaboration place. I would also question the need for
Strategic members and PMCs having a vote on EPP (even less being in the
leadership) unless the member in question actually does something in the
EPP project.
As much as this might sound like blasphemy we will fail to attract people
taking over some duties if there are multiple abstract bodies dictating
what/how to be done. I know that I (personally) for sure would not sign up
in such a case. Having people that actually know what/how/why is done or at
least are interested in helping some area would be more than welcome but
having people from a PMC that failed to do proper release for couple of
years or just being appointed by some company seems pointless. And my
Planning Council experience shows that such people never actually attended
even less discussed anything at the meetings and this makes me even more
convinced that giving every strategic member and PMC EPP leadership would
be totally wrong move.


>
> For me the thing we must preserve is the p2 repo and the installer.
> Package are also nice/useful but not my top priority.
>
> Dani
>
>
>
> From:Gunnar Wagenknecht 
> To:Cross project issues 
> Date:29.01.2020 15:25
> Subject:[EXTERNAL] Re: [cross-project-issues-dev] [WARNING]
> SimRel Headed Off theTracks
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> > On Jan 29, 2020, at 12:44, Sebastian Zarnekow <
> sebastian.zarne...@gmail.com> wrote:
> >
> > But in general, the current release cadence puts too much of a burden on
> the shoulders of all maintainers.
>
>
> As a project lead contributed to the train in the past and as a package
> maintainer, I truly disagree with the "too much of a burden" claim being
> raised here. Once you got all the things in place and compliant I don't
> ever recall it being a problem to put out new bits. 98% of it was automated
> anyway. It was push on Jenkins. The other 2% was bureaucracy in the portal.
>
>
> > Platform and JDT used to be rock solid with the annual releases. Now we
> see more releases but also more bugs and complains from users as far as I
> can tell. Most of the people that I'm talking too are no longer confident
> in the quality of the release. For them it's nowadays a tradeoff between
> the bugs the suffer from and know of vs the bugs they will suffer from but
> don't know yet.
>
> There is some truth here but it really isn't that bad. I'd like to raise
> two things on the positive side, though.
>
> 1. The quality is in my subjective impression on par with - if not better
> - than the six-weeks milestone releases Eclipse had previously.
> 2. I don't have to wait for a full year till I'm able to consume a fix.
>
> Yes, I do face a few bugs. Some of them are annoying. But I'd challenge if
> they are really a result of the faster release cadence *or* a result of
> funding downsizing in involved development teams.
>
>
> > > Also annual releases will resurrect a number of "service releases"
> with all the effort required,
> >
> > And with the quality gains. Exactly.
>
> You will only see quality gains *if* the projects are willing to invest
> into maintaining a service branch. I have the impression that it's easier
> for the active projects to simply fix things in main/master and don't worry
> about back porting (which can double work).
>
>
> In the past the SimRel had its clear purpose. It was a big win for the
> Foundation to be able to coordinate releases across its projects. It really
> made us look big in terms of numbers and successful (year over year at the
> same time, no delays). It came with a ton of bureaucracy. IBM thankfully
> dedicated full-time employees to creating and maintaining the SimRel.
>
> I think it was already a risky decision to continue business as usual when
> the only FTE retired. There is a staffing issue at hand. I don't get the
> proposal of going back to one release per year. What is the solution if
> SimRel rans into a staffing issue again? One release every four years? I
> think a first step is to admit that we cannot maintain the existing
> process. There simply isn't enough funding.
>
> We have to allow and ask the question - is it time to end the SimRel?
>
> FWIW, as a package maintainer I don't care if I consume things from a

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Daniel Megert]

I'm -1 to change the release schedule. Yes, there are probably more bugs 
but there are also more features *and* bug fixes that our users get more 
frequently.

One important thing that was not mentioned so far is the role of the 
Planning Council where the stakeholders (strategic members and PMCs) 
discuss and decide on the schedule. This can for sure not go to EPP unless 
the current council is part of the EPP leadership.

For me the thing we must preserve is the p2 repo and the installer. 
Package are also nice/useful but not my top priority.

Dani



From:   Gunnar Wagenknecht 
To: Cross project issues 
Date:   29.01.2020 15:25
Subject:[EXTERNAL] Re: [cross-project-issues-dev] [WARNING] SimRel 
Headed Off the  Tracks
Sent by:cross-project-issues-dev-boun...@eclipse.org



> On Jan 29, 2020, at 12:44, Sebastian Zarnekow 
 wrote:
> 
> But in general, the current release cadence puts too much of a burden on 
the shoulders of all maintainers.


As a project lead contributed to the train in the past and as a package 
maintainer, I truly disagree with the "too much of a burden" claim being 
raised here. Once you got all the things in place and compliant I don't 
ever recall it being a problem to put out new bits. 98% of it was 
automated anyway. It was push on Jenkins. The other 2% was bureaucracy in 
the portal.


> Platform and JDT used to be rock solid with the annual releases. Now we 
see more releases but also more bugs and complains from users as far as I 
can tell. Most of the people that I'm talking too are no longer confident 
in the quality of the release. For them it's nowadays a tradeoff between 
the bugs the suffer from and know of vs the bugs they will suffer from but 
don't know yet.

There is some truth here but it really isn't that bad. I'd like to raise 
two things on the positive side, though.

1. The quality is in my subjective impression on par with - if not better 
- than the six-weeks milestone releases Eclipse had previously.
2. I don't have to wait for a full year till I'm able to consume a fix.

Yes, I do face a few bugs. Some of them are annoying. But I'd challenge if 
they are really a result of the faster release cadence *or* a result of 
funding downsizing in involved development teams.


> > Also annual releases will resurrect a number of "service releases" 
with all the effort required,
> 
> And with the quality gains. Exactly.

You will only see quality gains *if* the projects are willing to invest 
into maintaining a service branch. I have the impression that it's easier 
for the active projects to simply fix things in main/master and don't 
worry about back porting (which can double work).


In the past the SimRel had its clear purpose. It was a big win for the 
Foundation to be able to coordinate releases across its projects. It 
really made us look big in terms of numbers and successful (year over year 
at the same time, no delays). It came with a ton of bureaucracy. IBM 
thankfully dedicated full-time employees to creating and maintaining the 
SimRel.

I think it was already a risky decision to continue business as usual when 
the only FTE retired. There is a staffing issue at hand. I don't get the 
proposal of going back to one release per year. What is the solution if 
SimRel rans into a staffing issue again? One release every four years? I 
think a first step is to admit that we cannot maintain the existing 
process. There simply isn't enough funding.

We have to allow and ask the question - is it time to end the SimRel?

FWIW, as a package maintainer I don't care if I consume things from a 
central aggregated repository or from multiple sources. I maintain an EPP 
package as well as an internal distribution. Especially with the later I 
learned that the value of consuming things from the SimRel train repo is 
lower than I thought. Some SimRel participating projects publish updates 
more frequently to their own p2 repos. Some projects continue to think 
that only one certified version of Apache HttpClient, Guava, SLF4J, 
Commons Logging, whatever can be shipped with their release. SimRel never 
solved that. Things got much easier once I stop putting third party 
plug-ins into feature.xml files and started letting p2 figure it out. 
Works great and dramatically reduced the burden to adopt to any new 
Eclipse release.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, 
https://urldefense.proofpoint.com/v2/url?u=http-3A__guw.io_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=gvjVJO_4vPGdQd5qd7faqgcZ7fijaZLH5AOhgMIxHo4&s=_kiNEH3ULUUBSDzu__Ty4CmyUAgPSaI4zQBPvOcsAqA&e=
 



___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev





___
cross-pro

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Gunnar Wagenknecht]

> On Jan 29, 2020, at 12:44, Sebastian Zarnekow  
> wrote:
> 
> But in general, the current release cadence puts too much of a burden on the 
> shoulders of all maintainers.


As a project lead contributed to the train in the past and as a package 
maintainer, I truly disagree with the "too much of a burden" claim being raised 
here. Once you got all the things in place and compliant I don't ever recall it 
being a problem to put out new bits. 98% of it was automated anyway. It was 
push on Jenkins. The other 2% was bureaucracy in the portal.


> Platform and JDT used to be rock solid with the annual releases. Now we see 
> more releases but also more bugs and complains from users as far as I can 
> tell. Most of the people that I'm talking too are no longer confident in the 
> quality of the release. For them it's nowadays a tradeoff between the bugs 
> the suffer from and know of vs the bugs they will suffer from but don't know 
> yet.

There is some truth here but it really isn't that bad. I'd like to raise two 
things on the positive side, though.

1. The quality is in my subjective impression on par with - if not better - 
than the six-weeks milestone releases Eclipse had previously.
2. I don't have to wait for a full year till I'm able to consume a fix.

Yes, I do face a few bugs. Some of them are annoying. But I'd challenge if they 
are really a result of the faster release cadence *or* a result of funding 
downsizing in involved development teams.


> > Also annual releases will resurrect a number of "service releases" with all 
> > the effort required,
> 
> And with the quality gains. Exactly.

You will only see quality gains *if* the projects are willing to invest into 
maintaining a service branch. I have the impression that it's easier for the 
active projects to simply fix things in main/master and don't worry about back 
porting (which can double work).


In the past the SimRel had its clear purpose. It was a big win for the 
Foundation to be able to coordinate releases across its projects. It really 
made us look big in terms of numbers and successful (year over year at the same 
time, no delays). It came with a ton of bureaucracy. IBM thankfully dedicated 
full-time employees to creating and maintaining the SimRel.

I think it was already a risky decision to continue business as usual when the 
only FTE retired. There is a staffing issue at hand. I don't get the proposal 
of going back to one release per year. What is the solution if SimRel rans into 
a staffing issue again? One release every four years? I think a first step is 
to admit that we cannot maintain the existing process. There simply isn't 
enough funding.

We have to allow and ask the question - is it time to end the SimRel?

FWIW, as a package maintainer I don't care if I consume things from a central 
aggregated repository or from multiple sources. I maintain an EPP package as 
well as an internal distribution. Especially with the later I learned that the 
value of consuming things from the SimRel train repo is lower than I thought. 
Some SimRel participating projects publish updates more frequently to their own 
p2 repos. Some projects continue to think that only one certified version of 
Apache HttpClient, Guava, SLF4J, Commons Logging, whatever can be shipped with 
their release. SimRel never solved that. Things got much easier once I stop 
putting third party plug-ins into feature.xml files and started letting p2 
figure it out. Works great and dramatically reduced the burden to adopt to any 
new Eclipse release.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/


___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Willink]

Hi

On 29/01/2020 13:22, Ed Merks wrote:


Yet even this is non-trivial work that must be done by someone.

We seem to be so concerned with the details that we are completely 
ignoring the bigger picture.


The EF provides many services to us that we could not survive without. 
(No doubt we may have suggestions for doing them even better, but at 
least they mostly get done.) Thank you very much.


AFAIAA the EF employees are paid, presumably from Friends of Eclipse and 
other begging bowls.


It appears that many very important communal activities are not 
EF-funded and so unreasonably dependent on the enthusiasm and 
time-generosity of a few individuals. Again thank you, but this is where 
the sustainability problem lies.


All project-neutral activities such as SimRel, MarketPlace admin, AERI 
admin, ... must be EF-funded; perhaps not generously funded but at least 
reasonably so.


We need to ensure that the big users of Eclipse really contribute.

I gather that Huawei makes use of QVTo, perhaps to manage product lines, 
but certainly QVTo and I expect Eclipse gets nothing in return


Once we have sustainable funding for project-neutral, we can perhaps 
move on to funding widely useful activities such as OOMPH, EMF and some 
legacy projects.


    Regards

        Ed Willink


___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Of course how often to release and in which form is also a digression...

I am kind of ambivalent on this topic.  I do believe that quality has 
suffered as a result of this new approach.  As Sebastian mentioned, as a 
consumer I now often have the choice between the old version with known 
bugs versus the new version with unknown bugs.  Neither is a great 
choice.  I don't think anyone is on safe ground arguing that quality has 
actually been improved by eliminating service releases.


But I wonder the general feeling others are expressing that to them it 
feels like the cost personally and for their projects is higher without 
maintenance release.  My sense is somewhat different. In the past I had 
to maintain two streams and hence two development environments with two 
different target platforms.  I'd fix problems in master and then I had 
to cherry pick them into the maintenance branch (with different version 
increments).  I also had to do builds for both streams.  This duality 
was more work than is currently the case maintaining only a single stream.


So I try to understand why there is the perception that maintaining one 
stream is more work than maintaining two streams. I imagine part of the 
problem here the extent to which changes in upstream dependencies are 
disruptive to my project, which is more likely in a non-service stream.  
I.e., did the Platform or EMF change something that makes Xtext no 
longer work such that Xtext is forced to spin a new release rather than 
feeding their existing release (or a maintenance release if they so 
choose) into the train for the next cycle?  The extent to which we all 
avoid truly disruptive changes, surely it ought to be be less work in 
general to release from a single stream...


Please correct any misperception I may have or illuminate any issues I 
do not fully understand in this regard.  I'd like to better understand 
the perception of others.  Please note that I agree that quality has 
suffered, but that's a separate issue from the perception that it's more 
work.


Regards,
Ed

On 29.01.2020 11:13, Alexander Fedorov wrote:

Hi all,

-1 for going back to annual releases.

For stable components there is an option to keep the same version 
contributed for a number of releases - this should be sufficient to 
support "annual release" experience.

For new and incubation components "annual" may mean mostly "next life".

For people that wants to contribute a patch it sounds like "ok, if you 
will be patient enough to go through all the environment setup, 
reviews and discussion - you have a chance to see you change next 
year" - for a majority of newcomers this doesn't look attractive.
For eclipse-based vendors - annual release is the invitation to do a 
fork and think about switching to another platform. Why? Because 
"another platform" with growing popularity has monthly releases.


Also annual releases will resurrect a number of "service releases" 
with all the effort required, at least to support the new Java 
versions. So, as Mickael stated below, the effort is comparable.


I agree with Mickael that only enforced automated reject via pipeline 
rules can improve the situation with release quality. Passing pipeline 
should mean "the change is good enough to spent time on final review 
before the merge".


Regards,
AF

29.01.2020 12:58, Mickael Istria пишет:



On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand 
mailto:matthias.wien...@itemis.de>> wrote:


Hi all,

+1 for going back to annual releases.


Projects are not forced to do quarterly releases. You can have your 
project do a yearly release, but it just means that since Platform 
releases every 3 months, you need to check your project against 2 
milestones and 2 RCs of the Platform every 3 months (12 times a 
year). Which doesn't change much compared to previous state where 
projects were supposed to be tested against all Platform milestones 
and RC, ie 11 times a year.\


The work done by Ed M is very appreciated. Ideally, the different
checks (e.g. licenses) could be automated to prevent degradation
of SimRel quality.


Some checks have already been possible to automate for a while: 
https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven

The licence check may be missing, and could be added.
Or one can probably just build a similar Maven configuration to run 
the other analyzers.
But the real thing is that what matters is not building the report, 
but enforcing rules without human intervention. This typically 
happens only with mechanism that fail the build in case the analyzers 
see issue. As long as human reading is required, it cost too much 
effort and time to someone, and feedback loop becomes too long. The 
only good way to report a bad state is to fail the build so it 
doesn't pass review.


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retri

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Aleksandar,

Comments below.

On 29.01.2020 13:23, Aleksandar Kurtakov wrote:



On Wed, Jan 29, 2020 at 1:47 PM Ed Merks > wrote:


Comments below.

On 29.01.2020 12:08, Aleksandar Kurtakov wrote:
>
> Let's add that I fully stand by Mickael here and his proposal is
the
> only one we got so far with a potential to improve the situation.
As I mentioned in my reply to Mickael, the proposal is mostly
juggling
the locations of the problems, not eliminating the underlying
problems,
though likely reducing the problems by virtue of reducing the
number of
involved projects.


I have never even thought that this will fix the underlying problems. 
But reducing them gives some fresh air and time(!) so we can actually 
look at how to actually fix them. Keeping the status quo means all of 
our time goes into preserving it .


Yet even this is non-trivial work that must be done by someone.

Let me give another example - we have spent months on getting api 
tools, version checks, even new compile warnings fail gerrit 
verification jobs for platform. This came at a cost - a number of 
third party dependencies (Lucene, Felix , Batik ...) haven't been 
updated regularly. But now that these checks are in line and every 
single patch is verified to not break these things (that used to cost 
weeks per release) we are full steam ahead on improving the situation 
as we are no longer paying the time price to do it manually.
Yes, I'd like to see the same thing happen for SimRel, whatever form 
that its in or it becomes.  But this comes at a cost and the question is 
how best to minimize that cost and who will bear it?
If that means we get EPP+simrel shrinked to some bare minimum so we 
can automate things and whoever wants to add something adheres to more 
and automated(!) checks - it's totally worth it.
I don't think size affects the cost of automating the checks. Though 
size will likely reduce the number of things that fail the checks.


> We have to just admit that Simrel and EPP can't continue in the way
> they are and look out for changes that will improve the situation.
I don't agree.  I would argue that train aggregate's value is not
merely
to install EPP packages, but rather to provide one-stop shopping
for a
consistent set of features that will function cohesively. But it's
fair
to argue, "I don't care about that so I won't invest my resource in
that".  Nevertheless, I do see value in that, and have been investing
resource in that.
> From Ed's proposal:
> * Choice 1 - let's be realistic and admit that this would not
happen.
> No one will step up and do things the way they used to be just
because
> someone is used to it being that way E.g. If I (or anyone from my
> team) step up - we will effectively implement the proposal. Of
course
> anyone is free to jump in and keep things the way they are -
I'll be
> more than happy to be proven wrong here :)
I would be happy to step in if I were able to continue to pay my
bills
in some way that was directly or indirectly related to the
investment of
my effort.


And many others but I don't see anyone offering it. That's why I call 
it unrealistic until we actually see someone offering it.


Indeed.   Yet I persevere, though for how long?

Of course I don't see anyone else stepping forward either.  Just the 
proposal to throw away as much as possible to make doing this horrible, 
frustrating, thankless grunt work a bit less unattractive than it is 
currently, along with some +1s to back that point of view.


+1s and proposals aren't actions.  So to date, I am the only one who has 
taken action.



> * Choice 2 - speak to representatives. From all the
> Planning/Architecture council meetings there used to be a lot of
> wishful thinking over the years and pretty much no one there
spent the
> time/resources to make it happen. Read this as - we don't need
talks,
> we need actions.
I've prompted the board the take action but without further
prompting it
is indeed just so many words and so little action.
> * Choice 3 - do nothing . I understand this is meant to be
provocative
> and I fully support some stress over the community. We should start
> questioning every single piece of our process and if it has
resource
> issues consider it ineffective or not needed before trying to solve
> it. For many of the existing plugins that are part of the Simrel
that
> would be the best to do - nothing.
Yes, I intend to make people realize that this is basically what
everyone is doing and has been doing.
> Well actually do single step - remove them.
> To use DLTK project  - we did exactly that - dropped the python
(Pydev
> is better offering!), ruby (Solargraph is better offering!), shell
> script (ShellWas is better

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Aleksandar Kurtakov]

On Wed, Jan 29, 2020 at 2:57 PM Ed Merks  wrote:

> Clearly we digress here.  In any case, this bugzilla is open for
> removing invalid marketplace listings:
>
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=550713
>
> Many failures are pretty clear.  The host no longer exists so clearly
> the listing is completely bogus...
>

I know the bug and I have commented on it and chased people to drop broken
listings and etc. But this is clearly not working thus we need someone from
Foundation to either step in or open the management of the marketplace to
the community so we can deliver better user experience.


>
> More comments below.
>
> On 29.01.2020 13:34, Aleksandar Kurtakov wrote:
> > So who is in charge of marketplace content?
>
> That's unclear.  It's kind of distributed as are most things. The user
> create/edits their listing, but until I implemented something to test
> it, no one tested it. There is no established process for removal.  I
> think only foundation staff can remove listings. And of course, like
> everyone else, the foundation staff is overloaded for lack of resource...
>
> > I can't believe we don't have a way to remove non-installable features
> > based on these reports. After all each release there is compatibility
> > with the latest  simrel added. Who does that? How? Can community
> > influence help with that?
> > IMHO claimed but not actually supported compatibility should be auto
> > removed from the market place entry. Entries with nothing installable
> > should be removed.
> I agree, but I'd hate for errors in my testing to cause a listing to be
> removed for bogus reasons.
> > As I would expect something like "Eclipse Foundation doesn't have
> > resources to develop that" popping up in the discussion - how can the
> > community help?  Any pointers are welcome.
> I think the report pretty much does the job, assuming no errors in the
> testing process itself.
>

We have to be 100% sure in the report - yes! But even more importantly it
has to be hooked with some automated run, notify (maintainer should be able
to point issue in reporting to stop removal or fix the listing), remove if
no action cycle and this is not existing AFAIK.


> > Wayne, I point to you with these questions as you should at least be
> > able to ask the correct person to jump in.
> ___
> 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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Clearly we digress here.  In any case, this bugzilla is open for 
removing invalid marketplace listings:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=550713

Many failures are pretty clear.  The host no longer exists so clearly 
the listing is completely bogus...


More comments below.

On 29.01.2020 13:34, Aleksandar Kurtakov wrote:

So who is in charge of marketplace content?


That's unclear.  It's kind of distributed as are most things. The user 
create/edits their listing, but until I implemented something to test 
it, no one tested it. There is no established process for removal.  I 
think only foundation staff can remove listings. And of course, like 
everyone else, the foundation staff is overloaded for lack of resource...


I can't believe we don't have a way to remove non-installable features 
based on these reports. After all each release there is compatibility 
with the latest  simrel added. Who does that? How? Can community 
influence help with that?
IMHO claimed but not actually supported compatibility should be auto 
removed from the market place entry. Entries with nothing installable 
should be removed.
I agree, but I'd hate for errors in my testing to cause a listing to be 
removed for bogus reasons.
As I would expect something like "Eclipse Foundation doesn't have 
resources to develop that" popping up in the discussion - how can the 
community help?  Any pointers are welcome.
I think the report pretty much does the job, assuming no errors in the 
testing process itself.
Wayne, I point to you with these questions as you should at least be 
able to ask the correct person to jump in.

___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Aleksandar Kurtakov]

On Wed, Jan 29, 2020 at 1:28 PM Ed Merks  wrote:

> Comments below.
> On 29.01.2020 10:48, Mickael Istria wrote:
>
>
> It seems mostly based on the the principle/assumption that moving the
>> problem will simplify the problem or make existing problems disappear by
>> magic.
>>
> Indeed, I believe that moving the problem to a better functioning project
> according to EDP practices, and by the way getting rid of a lot of
> questionable effort, will make many projects disappear.
>
> Making project disappears will definitely help make their contributed
> problems disappears.  Also, centralization of responsibilities seems
> helpful.
>
> Currently the train repo is a prerequisite for producing the packages and
>> it composes a large set of repositories into a single aggregate at which
>> point a high level of consistency is checked and ensured. In the end,
>> ensuring that all the artifacts that comprise each package are coherent
>> (and stable) does not go away even if somehow the packages were produced by
>> directly pulling content from something other than the train repository.
>>
> With EPP, we ensure that the packages are consistent and of good enough
> quality to be released. I don't think that would change much, and EPP could
> also add some tests verifying all features can install in the same IDE.
>
> The user's often install additional things the consistency of which is
> also important it seems to me.   The train has helped a great deal with
> that. E.g., you can be sure that when you install Xtext you also install
> the corresponding EMF version...
>
>
>
>> Nothing changes with regard to ensuring consistent licenses, signed
>> content, proper inter-operation, stable repositories, and mutual
>> instability.
>>
> Right, but at least, if it's in EPP, then we're sure the projects that are
> integrated have at least 1 person (the EPP maintainer for this package)
> caring about those issues and dealing with them. While with current push
> model in SimRel, some project push outdated stuff and aren't reachable.
>
> Yes, though it's not clear that this point what subset remains based on
> the transitive closure of all EPP package dependencies.   Often there are
> surprises.  E.g., I tried to remove BIRT, but there remain charting
> dependencies so I could only reduce the subset aggregated from BIRT...
>
> In the end, I'm not even sure if you're suggesting that there needs to be
>> no aggregation at all, but simply a very large set of direct references to
>> various project repositories.  But I can assure you that loading 50
>> repositories instead of 2 when doing an install will not improve the
>> experience, and that getting n projects to maintain long-term stable sites
>> is a new problem that will also turn into yet another cat herding exercise
>> and when it fails (as all things do on occasion), the users will notice
>> immediately.
>>
> I suggest EPP builds the aggregated and categorized p2 repository,
> containing only stuff that are included in packages.
>
> We'd need to understand the transitive closure of all packages and presume
> that consistency for anything in a package is just not important to anyone,
> not even users.
>
> As such, I did quick test, resolve all EPP IUs for 2020-03 into a target
> platform, which suggests that only 10% of the IUs are in packages. It's not
> clear which cross section of projects this covers.  But it's clear looking
> at which EMF things are in the TP that only a very small subset of what EMF
> contributes to the aggregate is transitively required by the EPP
> packages.   I'd not be happy with a train aggregate that did not include
> all the things I currently contribute to the train.  One stop shopping from
> the aggregate, an aggregate that's bigger than what's transitively
> pre-installed in the union of all EPP packages, seems to me to have
> significant value...
>
> To build. EPP references different source p2 repositories, just like
> SimRel reference other repositories.
>
> So how will the exact repositories to use be managed?  I see later you
> suggest a *.target file, but it's not clear if that's a per-package
> *.target, in which case keeping it consistent across packages is important,
> or if it's shared single *.target, in which case multiple packages need to
> main the union of IUs to pull from the URLs.
>
> It feel as if you've joined the discussion years after all the reasons for
>> having a train the first place were had, and that you assume there really
>> are no good reasons because you were not part of those discussions.  So all
>> the reasons need to be reiterated, at which point you are highly inclined
>> to try to shoot each one down because they don't fit you current conclusion.
>>
> I know the reasons, and participated in integration of a project in SimRel
> 11 years ago and was very excited about SimRel and invested in it. I think
> it was interesting back then, but times have changed: many project are
> almost inactive in SimRel, SimRel b

Re: [cross-project-issues-dev] Eclipse 2020-03 and new ASM/JUnit5 Versions

[Evgeny Mandrikov]

Hi,

On Tue, Jan 28, 2020 at 4:39 PM Roland Grunberg  wrote:

> I'm not sure about ASM 7.3.1. I would ask in Bug 559150 so there's some
> awareness by the maintainer(s) adding the bundles that others are
> waiting for this.


Thank you for the reminder.
I can not find any existing CQ for ASM 7.3.1, so created
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21547
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21548


Regards,
Evgeny
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Aleksandar Kurtakov]

On Wed, Jan 29, 2020 at 1:47 PM Ed Merks  wrote:

> Comments below.
>
> On 29.01.2020 12:08, Aleksandar Kurtakov wrote:
> >
> > Let's add that I fully stand by Mickael here and his proposal is the
> > only one we got so far with a potential to improve the situation.
> As I mentioned in my reply to Mickael, the proposal is mostly juggling
> the locations of the problems, not eliminating the underlying problems,
> though likely reducing the problems by virtue of reducing the number of
> involved projects.
>

I have never even thought that this will fix the underlying problems. But
reducing them gives some fresh air and time(!) so we can actually look at
how to actually fix them. Keeping the status quo means all of our time goes
into preserving it .
Let me give another example - we have spent months on getting api tools,
version checks, even new compile warnings fail gerrit verification jobs for
platform. This came at a cost - a number of third party dependencies
(Lucene, Felix , Batik ...) haven't been updated regularly. But now that
these checks are in line and every single patch is verified to not break
these things (that used to cost weeks per release) we are full steam ahead
on improving the situation as we are no longer paying the time price to do
it manually.
If that means we get EPP+simrel shrinked to some bare minimum so we can
automate things and whoever wants to add something adheres to more and
automated(!) checks - it's totally worth it.


> > We have to just admit that Simrel and EPP can't continue in the way
> > they are and look out for changes that will improve the situation.
> I don't agree.  I would argue that train aggregate's value is not merely
> to install EPP packages, but rather to provide one-stop shopping for a
> consistent set of features that will function cohesively.  But it's fair
> to argue, "I don't care about that so I won't invest my resource in
> that".  Nevertheless, I do see value in that, and have been investing
> resource in that.
> > From Ed's proposal:
> > * Choice 1 - let's be realistic and admit that this would not happen.
> > No one will step up and do things the way they used to be just because
> > someone is used to it being that way E.g. If I (or anyone from my
> > team) step up - we will effectively implement the proposal. Of course
> > anyone is free to jump in and keep things the way they are - I'll be
> > more than happy to be proven wrong here :)
> I would be happy to step in if I were able to continue to pay my bills
> in some way that was directly or indirectly related to the investment of
> my effort.
>

And many others but I don't see anyone offering it. That's why I call it
unrealistic until we actually see someone offering it.


> > * Choice 2 - speak to representatives. From all the
> > Planning/Architecture council meetings there used to be a lot of
> > wishful thinking over the years and pretty much no one there spent the
> > time/resources to make it happen. Read this as - we don't need talks,
> > we need actions.
> I've prompted the board the take action but without further prompting it
> is indeed just so many words and so little action.
> > * Choice 3 - do nothing . I understand this is meant to be provocative
> > and I fully support some stress over the community. We should start
> > questioning every single piece of our process and if it has resource
> > issues consider it ineffective or not needed before trying to solve
> > it. For many of the existing plugins that are part of the Simrel that
> > would be the best to do - nothing.
> Yes, I intend to make people realize that this is basically what
> everyone is doing and has been doing.
> > Well actually do single step - remove them.
> > To use DLTK project  - we did exactly that - dropped the python (Pydev
> > is better offering!), ruby (Solargraph is better offering!), shell
> > script (ShellWas is better offering), js (WildWebDeveloper is better
> > offering)  from the December release.
> > To use CDT project  - launchbar and templates repo are merged into
> > main one to reduce cycles. Terminal is getting moved to CDT so RSE can
> > finally be left to rot there. Ancient parsers are getting dropped and
> > so on.
> > I'm not even going to mention the amount of work and automation that
> > went on Platform and Tycho side .
> Yes, I'm well aware of how much work it is just contributing quality
> content to SimRel for my own projects.  I'm sure this is a huge effort
> for a great many, hence the cries for doing fewer releases. But the
> platform drives and that drives the rest of us and we have far less
> resource than does the platform!
>

Interestingly enough Platform used to be the one of the most understaffed
project and exactly the change to more releases and faster delivery of user
fixes made it better covered with resources. See e.g. Alexander Fedorov -
he is one of the contributors that jumped after the more to frequent
releases. With less frequent releases there will be less resource

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Comments below.

On 29.01.2020 12:08, Aleksandar Kurtakov wrote:


Let's add that I fully stand by Mickael here and his proposal is the 
only one we got so far with a potential to improve the situation.
As I mentioned in my reply to Mickael, the proposal is mostly juggling 
the locations of the problems, not eliminating the underlying problems, 
though likely reducing the problems by virtue of reducing the number of 
involved projects.
We have to just admit that Simrel and EPP can't continue in the way 
they are and look out for changes that will improve the situation.
I don't agree.  I would argue that train aggregate's value is not merely 
to install EPP packages, but rather to provide one-stop shopping for a 
consistent set of features that will function cohesively.  But it's fair 
to argue, "I don't care about that so I won't invest my resource in 
that".  Nevertheless, I do see value in that, and have been investing 
resource in that.

From Ed's proposal:
* Choice 1 - let's be realistic and admit that this would not happen. 
No one will step up and do things the way they used to be just because 
someone is used to it being that way E.g. If I (or anyone from my 
team) step up - we will effectively implement the proposal. Of course 
anyone is free to jump in and keep things the way they are - I'll be 
more than happy to be proven wrong here :)
I would be happy to step in if I were able to continue to pay my bills 
in some way that was directly or indirectly related to the investment of 
my effort.
* Choice 2 - speak to representatives. From all the 
Planning/Architecture council meetings there used to be a lot of 
wishful thinking over the years and pretty much no one there spent the 
time/resources to make it happen. Read this as - we don't need talks, 
we need actions.
I've prompted the board the take action but without further prompting it 
is indeed just so many words and so little action.
* Choice 3 - do nothing . I understand this is meant to be provocative 
and I fully support some stress over the community. We should start 
questioning every single piece of our process and if it has resource 
issues consider it ineffective or not needed before trying to solve 
it. For many of the existing plugins that are part of the Simrel that 
would be the best to do - nothing.
Yes, I intend to make people realize that this is basically what 
everyone is doing and has been doing.

Well actually do single step - remove them.
To use DLTK project  - we did exactly that - dropped the python (Pydev 
is better offering!), ruby (Solargraph is better offering!), shell 
script (ShellWas is better offering), js (WildWebDeveloper is better 
offering)  from the December release.
To use CDT project  - launchbar and templates repo are merged into 
main one to reduce cycles. Terminal is getting moved to CDT so RSE can 
finally be left to rot there. Ancient parsers are getting dropped and 
so on.
I'm not even going to mention the amount of work and automation that 
went on Platform and Tycho side .
Yes, I'm well aware of how much work it is just contributing quality 
content to SimRel for my own projects.  I'm sure this is a huge effort 
for a great many, hence the cries for doing fewer releases. But the 
platform drives and that drives the rest of us and we have far less 
resource than does the platform!
Aka active projects are already actively engaged into streamlining the 
developer experience so burden is manageable. In my eyes there is no 
other way but to do that for Simrel+EPP
To me it's a fundamental issue of resource and leadership.  Someone must 
lead.  Someone must take responsibility. Someone must have broad, 
long-term oversight.  Someone must manage and deal with the removal of 
projects and that somone must have the authority to do so.

___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Sebastian Zarnekow]

Everyone,

> his proposal is the only one we got so far with a potential to improve
the situation

I don't think that's true. Ed W also brought the option to the table, that
we could reassess the benefit of 4 release trains per year. Does this even
carry its own weight?
I'm fully aware of the fact that there are projects that want to deliver
more often than once or twice a year. But in general, the current release
cadence puts too much of a burden on the shoulders of all maintainers.

Platform and JDT used to be rock solid with the annual releases. Now we see
more releases but also more bugs and complains from users as far as I can
tell. Most of the people that I'm talking too are no longer confident in
the quality of the release. For them it's nowadays a tradeoff between the
bugs the suffer from and know of vs the bugs they will suffer from but
don't know yet.

The proposal to drop the idea of release trains in their current shape
appears to be striking at a first glance (less work is better, who does not
like that idea!!). But to me its seems to based on false assumptions and
also based on oblivion.
We used to be at a place called plugin-hell living next jar-hell and being
the little sister of dll-hell. Introducing the train back then was such a
huge step forwards when it comes to quality and robustness and customer
satisfaction, I always want to shed tears of joy when thinking about this.
Of course we suffered from the curse of good intentions since the train
became too crowded, but at least we had a certain level of quality. When
going for four release per anno, we suffered again, but even more so. Four
times the work for participant, no maintenance releases - which used to be
a great value back in the days, and people moving on (no offence, such is
life).

The valid question after this rambling remains. What are our options? And
how do we find a feasible path forward - not daring to say the best path
here.
There seems to be consensus that we want to reduce the workload. But
certainly dropping the train entirely has to be carefully weighted against
a reliable schedule with fewer outages.
My gut feeling is that 2 releases per year would already greatly help to
allow a little room the breath for those project maintainers, that are
responsive and try to remain compatible to the other projects.

> For stable components there is an option to keep the same version
contributed for a number of releases - this should be sufficient to support
"annual release" experience.
> For new and incubation components "annual" may mean mostly "next life".

Nothing prevents these to ship more often against the released bundles of
other projects. Why does one need to ship the same bits 4 times a year if
there is no observable progress?

> For eclipse-based vendors - annual release is the invitation to do a fork
and think about switching to another platform. Why? Because "another
platform" with growing popularity has monthly releases.

I don't know a single vendor that will immediately jump the most recent
train. See rantings about quality above.

> Also annual releases will resurrect a number of "service releases" with
all the effort required,

And with the quality gains. Exactly.

> Right, but at least, if it's in EPP, then we're sure the projects that
are integrated have at least 1 person (the EPP maintainer for this package)
caring about those issues and dealing with them. While with current push
model in SimRel, some project push outdated stuff and aren't reachable.

Assuming you depend on these bits. How would it improve the situation. The
poor maintainer of the package cannot reach the unreachable people either.
No obvious gain to me.
And to put myself into the shoes of the responsive maintainer of a project.
If you want to / have to contribute your project to multiple EPPs, do you
coordinate with everyone individually when you do changes? How do you make
sure, that you do not break these packages? How can be ensured, that your
project remains a good citizen. Also in that regard, no obvious gain to me.

It's a little unfortunate that I don't have a great idea either and can
only express my concerns about the current direction of Eclipse, the
quality and the proposed solutions.
But it may be worthwhile to revisit the train schedule and have fewer big
releases per anno and reconsider service releases with a more curated list
of changes.

Best
Sebastian

On Wed, Jan 29, 2020 at 12:09 PM Aleksandar Kurtakov 
wrote:

>
>
> On Wed, Jan 29, 2020 at 11:49 AM Mickael Istria 
> wrote:
>
>>
>> It seems mostly based on the the principle/assumption that moving the
>>> problem will simplify the problem or make existing problems disappear by
>>> magic.
>>>
>> Indeed, I believe that moving the problem to a better functioning project
>> according to EDP practices, and by the way getting rid of a lot of
>> questionable effort, will make many projects disappear.
>>
>>> Currently the train repo is a prerequisite for producing the packages

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Matthias Wienand]

Hi,

> The only good way to report a bad state is to fail the build so it doesn't 
> pass review.

That is exactly what I had in mind.

Given Alexander’s arguments, I stand corrected: "release early, release often". 
For GEF, automation of the process will be advanced further. I want to 
contribute a newer version only when it adds value.

The only issue I have with the current release process is deciding beforehand 
what version will be contributed. Maybe I am misunderstanding something about 
the process, though.

Best regards,
Matthias
--

Matthias Wienand
B.Sc. Softwaretechnik
Software Engineer

Telefon: +49 231 9860 202
Telefax: +49 231 9860 211
Mobil:   +49 176 248 950 82


matthias.wien...@itemis.de
http://www.xing.com/profile/Matthias_Wienand2
http://www.itemis.de


itemis AG

Niederlassung Lünen
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Abdelghani El-Kacimi
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino

> Am 29.01.2020 um 10:58 schrieb Mickael Istria :
> 
> 
> 
> On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand  > wrote:
> Hi all,
> 
> +1 for going back to annual releases.
> 
> Projects are not forced to do quarterly releases. You can have your project 
> do a yearly release, but it just means that since Platform releases every 3 
> months, you need to check your project against 2 milestones and 2 RCs of the 
> Platform every 3 months (12 times a year). Which doesn't change much compared 
> to previous state where projects were supposed to be tested against all 
> Platform milestones and RC, ie 11 times a year.\
> 
> The work done by Ed M is very appreciated. Ideally, the different checks 
> (e.g. licenses) could be automated to prevent degradation of SimRel quality.
> 
> Some checks have already been possible to automate for a while: 
> https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven 
> 
> The licence check may be missing, and could be added.
> Or one can probably just build a similar Maven configuration to run the other 
> analyzers.
> But the real thing is that what matters is not building the report, but 
> enforcing rules without human intervention. This typically happens only with 
> mechanism that fail the build in case the analyzers see issue. As long as 
> human reading is required, it cost too much effort and time to someone, and 
> feedback loop becomes too long. The only good way to report a bad state is to 
> fail the build so it doesn't pass review.
> ___
> 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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Comments below.

On 29.01.2020 10:48, Mickael Istria wrote:


It seems mostly based on the the principle/assumption that moving
the problem will simplify the problem or make existing problems
disappear by magic.

Indeed, I believe that moving the problem to a better functioning 
project according to EDP practices, and by the way getting rid of a 
lot of questionable effort, will make many projects disappear.
Making project disappears will definitely help make their contributed 
problems disappears.  Also, centralization of responsibilities seems 
helpful.


Currently the train repo is a prerequisite for producing the
packages and it composes a large set of repositories into a single
aggregate at which point a high level of consistency is checked
and ensured. In the end, ensuring that all the artifacts that
comprise each package are coherent (and stable) does not go away
even if somehow the packages were produced by directly pulling
content from something other than the train repository.

With EPP, we ensure that the packages are consistent and of good 
enough quality to be released. I don't think that would change much, 
and EPP could also add some tests verifying all features can install 
in the same IDE.
The user's often install additional things the consistency of which is 
also important it seems to me.   The train has helped a great deal with 
that. E.g., you can be sure that when you install Xtext you also install 
the corresponding EMF version...


Nothing changes with regard to ensuring consistent licenses,
signed content, proper inter-operation, stable repositories, and
mutual instability.

Right, but at least, if it's in EPP, then we're sure the projects that 
are integrated have at least 1 person (the EPP maintainer for this 
package) caring about those issues and dealing with them. While with 
current push model in SimRel, some project push outdated stuff and 
aren't reachable.
Yes, though it's not clear that this point what subset remains based on 
the transitive closure of all EPP package dependencies.   Often there 
are surprises.  E.g., I tried to remove BIRT, but there remain charting 
dependencies so I could only reduce the subset aggregated from BIRT...


In the end, I'm not even sure if you're suggesting that there
needs to be no aggregation at all, but simply a very large set of
direct references to various project repositories.  But I can
assure you that loading 50 repositories instead of 2 when doing an
install will not improve the experience, and that getting n
projects to maintain long-term stable sites is a new problem that
will also turn into yet another cat herding exercise and when it
fails (as all things do on occasion), the users will notice
immediately.

I suggest EPP builds the aggregated and categorized p2 repository, 
containing only stuff that are included in packages.


We'd need to understand the transitive closure of all packages and 
presume that consistency for anything in a package is just not important 
to anyone, not even users.


As such, I did quick test, resolve all EPP IUs for 2020-03 into a target 
platform, which suggests that only 10% of the IUs are in packages. It's 
not clear which cross section of projects this covers.  But it's clear 
looking at which EMF things are in the TP that only a very small subset 
of what EMF contributes to the aggregate is transitively required by the 
EPP packages.   I'd not be happy with a train aggregate that did not 
include all the things I currently contribute to the train.  One stop 
shopping from the aggregate, an aggregate that's bigger than what's 
transitively pre-installed in the union of all EPP packages, seems to me 
to have significant value...


To build. EPP references different source p2 repositories, just like 
SimRel reference other repositories.
So how will the exact repositories to use be managed?  I see later you 
suggest a *.target file, but it's not clear if that's a per-package 
*.target, in which case keeping it consistent across packages is 
important, or if it's shared single *.target, in which case multiple 
packages need to main the union of IUs to pull from the URLs.


It feel as if you've joined the discussion years after all the
reasons for having a train the first place were had, and that you
assume there really are no good reasons because you were not part
of those discussions. So all the reasons need to be reiterated, at
which point you are highly inclined to try to shoot each one down
because they don't fit you current conclusion.

I know the reasons, and participated in integration of a project in 
SimRel 11 years ago and was very excited about SimRel and invested in 
it. I think it was interesting back then, but times have changed: many 
project are almost inactive in SimRel, SimRel build has lost 
maintenance workforce and there doesn't seem to be much hope for more, 
here i

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Lars Vogel]

> We should start questioning every single piece of our process and if it has 
> resource issues consider it ineffective or not needed before trying to solve 
> it.

+1

> -1 for going back to annual releases.

-1 also for going back to annual releases, with the 3 month release
process we are able to deliver platform enhancements to the user base
and JDT is capable of delivering support for every new Java release.



On Wed, Jan 29, 2020 at 12:09 PM Aleksandar Kurtakov
 wrote:
>
>
>
> On Wed, Jan 29, 2020 at 11:49 AM Mickael Istria  wrote:
>>
>>
>>> It seems mostly based on the the principle/assumption that moving the 
>>> problem will simplify the problem or make existing problems disappear by 
>>> magic.
>>
>> Indeed, I believe that moving the problem to a better functioning project 
>> according to EDP practices, and by the way getting rid of a lot of 
>> questionable effort, will make many projects disappear.
>>>
>>> Currently the train repo is a prerequisite for producing the packages and 
>>> it composes a large set of repositories into a single aggregate at which 
>>> point a high level of consistency is checked and ensured. In the end, 
>>> ensuring that all the artifacts that comprise each package are coherent 
>>> (and stable) does not go away even if somehow the packages were produced by 
>>> directly pulling content from something other than the train repository.
>>
>> With EPP, we ensure that the packages are consistent and of good enough 
>> quality to be released. I don't think that would change much, and EPP could 
>> also add some tests verifying all features can install in the same IDE.
>>
>>>
>>> Nothing changes with regard to ensuring consistent licenses, signed 
>>> content, proper inter-operation, stable repositories, and mutual 
>>> instability.
>>
>> Right, but at least, if it's in EPP, then we're sure the projects that are 
>> integrated have at least 1 person (the EPP maintainer for this package) 
>> caring about those issues and dealing with them. While with current push 
>> model in SimRel, some project push outdated stuff and aren't reachable.
>>>
>>> In the end, I'm not even sure if you're suggesting that there needs to be 
>>> no aggregation at all, but simply a very large set of direct references to 
>>> various project repositories.  But I can assure you that loading 50 
>>> repositories instead of 2 when doing an install will not improve the 
>>> experience, and that getting n projects to maintain long-term stable sites 
>>> is a new problem that will also turn into yet another cat herding exercise 
>>> and when it fails (as all things do on occasion), the users will notice 
>>> immediately.
>>
>> I suggest EPP builds the aggregated and categorized p2 repository, 
>> containing only stuff that are included in packages.
>> To build. EPP references different source p2 repositories, just like SimRel 
>> reference other repositories.
>>>
>>> It feel as if you've joined the discussion years after all the reasons for 
>>> having a train the first place were had, and that you assume there really 
>>> are no good reasons because you were not part of those discussions.  So all 
>>> the reasons need to be reiterated, at which point you are highly inclined 
>>> to try to shoot each one down because they don't fit you current conclusion.
>>
>> I know the reasons, and participated in integration of a project in SimRel 
>> 11 years ago and was very excited about SimRel and invested in it. I think 
>> it was interesting back then, but times have changed: many project are 
>> almost inactive in SimRel, SimRel build has lost maintenance workforce and 
>> there doesn't seem to be much hope for more, here is Marketplace, there are 
>> EPP packages, there is an installer... So I think it's just time to question 
>> again whether we can collectively afford SimRel as it is now, and even 
>> whether this is still the appropriate solution for past problems.
>> Those who need more need to invest more; but if no-one wishes to invest more 
>> despite the urge, then it's that there is actually no strong enough need to 
>> keep things as they are now.
>>>
>>> In any case, no matter exactly all the concrete details of what you are 
>>> suggesting, the question of who does that work remains the same one.
>>
>> If we keep separated SimRel and EPP and keep projects that are irrelevant to 
>> EPP in a push mode, it's a lot of work and no-one will want to do this work.
>> If we make things simpler and better address current issues instead of 
>> sticking to older ones, then it's less work and it's more interesting, some 
>> people will continue it.
>>>
>>> My reasons to support that is that:
>>> * Marketplace would still be available -> no loss for users
>>>
>>> I also pointed out that you could fix your marketplace entry:  
>>> https://www.eclipse.org/setups/marketplace/?id=3394048
>>
>> This is far from being top-priority, I have more valuable work in the 
>> backlog (like lobbying for the end of SimRel a

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Aleksandar Kurtakov]

On Wed, Jan 29, 2020 at 11:49 AM Mickael Istria  wrote:

>
> It seems mostly based on the the principle/assumption that moving the
>> problem will simplify the problem or make existing problems disappear by
>> magic.
>>
> Indeed, I believe that moving the problem to a better functioning project
> according to EDP practices, and by the way getting rid of a lot of
> questionable effort, will make many projects disappear.
>
>> Currently the train repo is a prerequisite for producing the packages and
>> it composes a large set of repositories into a single aggregate at which
>> point a high level of consistency is checked and ensured. In the end,
>> ensuring that all the artifacts that comprise each package are coherent
>> (and stable) does not go away even if somehow the packages were produced by
>> directly pulling content from something other than the train repository.
>>
> With EPP, we ensure that the packages are consistent and of good enough
> quality to be released. I don't think that would change much, and EPP could
> also add some tests verifying all features can install in the same IDE.
>
>
>> Nothing changes with regard to ensuring consistent licenses, signed
>> content, proper inter-operation, stable repositories, and mutual
>> instability.
>>
> Right, but at least, if it's in EPP, then we're sure the projects that are
> integrated have at least 1 person (the EPP maintainer for this package)
> caring about those issues and dealing with them. While with current push
> model in SimRel, some project push outdated stuff and aren't reachable.
>
>> In the end, I'm not even sure if you're suggesting that there needs to be
>> no aggregation at all, but simply a very large set of direct references to
>> various project repositories.  But I can assure you that loading 50
>> repositories instead of 2 when doing an install will not improve the
>> experience, and that getting n projects to maintain long-term stable sites
>> is a new problem that will also turn into yet another cat herding exercise
>> and when it fails (as all things do on occasion), the users will notice
>> immediately.
>>
> I suggest EPP builds the aggregated and categorized p2 repository,
> containing only stuff that are included in packages.
> To build. EPP references different source p2 repositories, just like
> SimRel reference other repositories.
>
>> It feel as if you've joined the discussion years after all the reasons
>> for having a train the first place were had, and that you assume there
>> really are no good reasons because you were not part of those discussions.
>> So all the reasons need to be reiterated, at which point you are highly
>> inclined to try to shoot each one down because they don't fit you current
>> conclusion.
>>
> I know the reasons, and participated in integration of a project in SimRel
> 11 years ago and was very excited about SimRel and invested in it. I think
> it was interesting back then, but times have changed: many project are
> almost inactive in SimRel, SimRel build has lost maintenance workforce and
> there doesn't seem to be much hope for more, here is Marketplace, there are
> EPP packages, there is an installer... So I think it's just time to
> question again whether we can collectively afford SimRel as it is now, and
> even whether this is still the appropriate solution for past problems.
> Those who need more need to invest more; but if no-one wishes to invest
> more despite the urge, then it's that there is actually no strong enough
> need to keep things as they are now.
>
>> In any case, no matter exactly all the concrete details of what you are
>> suggesting, the question of who does that work remains the same one.
>>
> If we keep separated SimRel and EPP and keep projects that are irrelevant
> to EPP in a push mode, it's a lot of work and no-one will want to do this
> work.
> If we make things simpler and better address current issues instead of
> sticking to older ones, then it's less work and it's more interesting, some
> people will continue it.
>
>> My reasons to support that is that:
>> * Marketplace would still be available -> no loss for users
>>
>> I also pointed out that you could fix your marketplace entry:
>> https://www.eclipse.org/setups/marketplace/?id=3394048
>>
> This is far from being top-priority, I have more valuable work in the
> backlog (like lobbying for the end of SimRel as we know it ;)
>
>> That hasn't happened and the fully 1/3 of the marketplace entries are
>> completely broken or somewhat broken.  Consistent/correct marketplace
>> listings is yet another exercise of cat herding.
>>
> There are stats about installation issues in Marketplace already, and IIRC
> there is even a system to notify owner in case of too many install
> failures. That seems far enough to me, and my current usage of Marketplace
> is pretty pleasant and leads to good experience. (while I never use the
> SimRel site...)
>
>
>> * packages would still be available -> no loss for users
>>
>> So at le

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Alexander Fedorov]

Hi all,

-1 for going back to annual releases.

For stable components there is an option to keep the same version 
contributed for a number of releases - this should be sufficient to 
support "annual release" experience.

For new and incubation components "annual" may mean mostly "next life".

For people that wants to contribute a patch it sounds like "ok, if you 
will be patient enough to go through all the environment setup, reviews 
and discussion - you have a chance to see you change next year" - for a 
majority of newcomers this doesn't look attractive.
For eclipse-based vendors - annual release is the invitation to do a 
fork and think about switching to another platform. Why? Because 
"another platform" with growing popularity has monthly releases.


Also annual releases will resurrect a number of "service releases" with 
all the effort required, at least to support the new Java versions. So, 
as Mickael stated below, the effort is comparable.


I agree with Mickael that only enforced automated reject via pipeline 
rules can improve the situation with release quality. Passing pipeline 
should mean "the change is good enough to spent time on final review 
before the merge".


Regards,
AF

29.01.2020 12:58, Mickael Istria пишет:



On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand 
mailto:matthias.wien...@itemis.de>> wrote:


Hi all,

+1 for going back to annual releases.


Projects are not forced to do quarterly releases. You can have your 
project do a yearly release, but it just means that since Platform 
releases every 3 months, you need to check your project against 2 
milestones and 2 RCs of the Platform every 3 months (12 times a year). 
Which doesn't change much compared to previous state where projects 
were supposed to be tested against all Platform milestones and RC, ie 
11 times a year.\


The work done by Ed M is very appreciated. Ideally, the different
checks (e.g. licenses) could be automated to prevent degradation
of SimRel quality.


Some checks have already been possible to automate for a while: 
https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven

The licence check may be missing, and could be added.
Or one can probably just build a similar Maven configuration to run 
the other analyzers.
But the real thing is that what matters is not building the report, 
but enforcing rules without human intervention. This typically happens 
only with mechanism that fail the build in case the analyzers see 
issue. As long as human reading is required, it cost too much effort 
and time to someone, and feedback loop becomes too long. The only good 
way to report a bad state is to fail the build so it doesn't pass review.


___
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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Mickael Istria]

On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand <
matthias.wien...@itemis.de> wrote:

> Hi all,
>
> +1 for going back to annual releases.
>

Projects are not forced to do quarterly releases. You can have your project
do a yearly release, but it just means that since Platform releases every 3
months, you need to check your project against 2 milestones and 2 RCs of
the Platform every 3 months (12 times a year). Which doesn't change much
compared to previous state where projects were supposed to be tested
against all Platform milestones and RC, ie 11 times a year.\

The work done by Ed M is very appreciated. Ideally, the different checks
> (e.g. licenses) could be automated to prevent degradation of SimRel quality.
>

Some checks have already been possible to automate for a while:
https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven
The licence check may be missing, and could be added.
Or one can probably just build a similar Maven configuration to run the
other analyzers.
But the real thing is that what matters is not building the report, but
enforcing rules without human intervention. This typically happens only
with mechanism that fail the build in case the analyzers see issue. As long
as human reading is required, it cost too much effort and time to someone,
and feedback loop becomes too long. The only good way to report a bad state
is to fail the build so it doesn't pass review.
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Mickael Istria]

> It seems mostly based on the the principle/assumption that moving the
> problem will simplify the problem or make existing problems disappear by
> magic.
>
Indeed, I believe that moving the problem to a better functioning project
according to EDP practices, and by the way getting rid of a lot of
questionable effort, will make many projects disappear.

> Currently the train repo is a prerequisite for producing the packages and
> it composes a large set of repositories into a single aggregate at which
> point a high level of consistency is checked and ensured. In the end,
> ensuring that all the artifacts that comprise each package are coherent
> (and stable) does not go away even if somehow the packages were produced by
> directly pulling content from something other than the train repository.
>
With EPP, we ensure that the packages are consistent and of good enough
quality to be released. I don't think that would change much, and EPP could
also add some tests verifying all features can install in the same IDE.


> Nothing changes with regard to ensuring consistent licenses, signed
> content, proper inter-operation, stable repositories, and mutual
> instability.
>
Right, but at least, if it's in EPP, then we're sure the projects that are
integrated have at least 1 person (the EPP maintainer for this package)
caring about those issues and dealing with them. While with current push
model in SimRel, some project push outdated stuff and aren't reachable.

> In the end, I'm not even sure if you're suggesting that there needs to be
> no aggregation at all, but simply a very large set of direct references to
> various project repositories.  But I can assure you that loading 50
> repositories instead of 2 when doing an install will not improve the
> experience, and that getting n projects to maintain long-term stable sites
> is a new problem that will also turn into yet another cat herding exercise
> and when it fails (as all things do on occasion), the users will notice
> immediately.
>
I suggest EPP builds the aggregated and categorized p2 repository,
containing only stuff that are included in packages.
To build. EPP references different source p2 repositories, just like SimRel
reference other repositories.

> It feel as if you've joined the discussion years after all the reasons for
> having a train the first place were had, and that you assume there really
> are no good reasons because you were not part of those discussions.  So all
> the reasons need to be reiterated, at which point you are highly inclined
> to try to shoot each one down because they don't fit you current conclusion.
>
I know the reasons, and participated in integration of a project in SimRel
11 years ago and was very excited about SimRel and invested in it. I think
it was interesting back then, but times have changed: many project are
almost inactive in SimRel, SimRel build has lost maintenance workforce and
there doesn't seem to be much hope for more, here is Marketplace, there are
EPP packages, there is an installer... So I think it's just time to
question again whether we can collectively afford SimRel as it is now, and
even whether this is still the appropriate solution for past problems.
Those who need more need to invest more; but if no-one wishes to invest
more despite the urge, then it's that there is actually no strong enough
need to keep things as they are now.

> In any case, no matter exactly all the concrete details of what you are
> suggesting, the question of who does that work remains the same one.
>
If we keep separated SimRel and EPP and keep projects that are irrelevant
to EPP in a push mode, it's a lot of work and no-one will want to do this
work.
If we make things simpler and better address current issues instead of
sticking to older ones, then it's less work and it's more interesting, some
people will continue it.

> My reasons to support that is that:
> * Marketplace would still be available -> no loss for users
>
> I also pointed out that you could fix your marketplace entry:
> https://www.eclipse.org/setups/marketplace/?id=3394048
>
This is far from being top-priority, I have more valuable work in the
backlog (like lobbying for the end of SimRel as we know it ;)

> That hasn't happened and the fully 1/3 of the marketplace entries are
> completely broken or somewhat broken.  Consistent/correct marketplace
> listings is yet another exercise of cat herding.
>
There are stats about installation issues in Marketplace already, and IIRC
there is even a system to notify owner in case of too many install
failures. That seems far enough to me, and my current usage of Marketplace
is pretty pleasant and leads to good experience. (while I never use the
SimRel site...)


> * packages would still be available -> no loss for users
>
> So at least we agree that packages are needed.  Unfortunately there's no
> one to produce them.
>

On the epp-dev mailing-lists, some questions are pending for others to
evaluate how much the can inve

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Matthias Wienand]

Hi all,

+1 for going back to annual releases.

I am very glad about the Jiro change, though.

The work done by Ed M is very appreciated. Ideally, the different checks (e.g. 
licenses) could be automated to prevent degradation of SimRel quality. This 
would also raise awareness immensely as following all discussions is a little 
too much for me, personally — I select what to read according to title.

Best regards,
Matthias
--

Matthias Wienand
B.Sc. Softwaretechnik
Software Engineer

Telefon: +49 231 9860 202
Telefax: +49 231 9860 211
Mobil:   +49 176 248 950 82


matthias.wien...@itemis.de
http://www.xing.com/profile/Matthias_Wienand2
http://www.itemis.de


itemis AG

Niederlassung Lünen
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Abdelghani El-Kacimi
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino

> Am 29.01.2020 um 10:10 schrieb Ed Willink :
> 
> Hi
> 
> I share Ed and Christian's concerns, and as I wrote earlier the original 
> purpose of SimRel was to provide a coherent synchronized release across all 
> active projects. The quarterly SimRel has totally undermined that because 
> many projects cannot support the faster cadence. Personally, it means that I 
> just chuck out my auto-tested builds without manual verification. Diligent 
> checks that I used to perform annually have gone out the window. I used to 
> use perhaps every other 6 weekly milestone for my personal development 
> resulting in many regression bugs getting fixed pre-release. Now the 
> regressions get detected after release; it is all much much too fast. The 
> final platform RC is done almost before some projects have started on their 
> first RC. The only things that can get fixed are panics and just look at the 
> number of RC3 respin discussions we now have to have because of the 
> unreasonable speed; in the past RC3 and RC4 were available.
> 
> Let's go back to annual SimRels that provide a coherent best endeavours 
> release that users can be confident of enhancing by taking on board service 
> releases. No longer a brand new different selection of novel bugs every 
> quarter.
> 
> If projects want to do quarterly intermediate releases, fine, they are 
> intermediate releases. Until such time as the high speed community steps up 
> and commits the resources to support it, why does the rest of Eclipse have to 
> suffer?
> 
> The timing of the annual release should be aligned to offer a useable rather 
> than experimental latest-Java experience.
> 
> (When I advocate annual SimRels, that does not mean I endorse EPPs. 
> Personally I only use the base Eclipse SDK ZIP, project ZIPs where available 
> and the SimRel P2 as a last resort. I can easily live without EPPs, but a 
> synchronized SimRel P2 is critical.)
> 
> (As a modelling developer I might be expected to use the Modeling EPP, but 
> sadly I find that although ridiculously bloated, it lacks important projects 
> and includes one project that I find detrimental to my UX.)
> 
> Regards
> 
> Ed Willink
> 
> On 29/01/2020 08:21, Dietrich, Christian wrote:
>> Hi all,
>> 
>> I personally share Ed's concerns about the direction the Eclipse
>> SimRel is thrifting. Maintaining 4 Releases a Year in a quite involved
>> project like Xtext with many dependencies was a lot of work. Also the
>> move to the new Cloud based Jenkins infrastructure ate a lot of
>> resources at the Xtext team last year. Resources that we won't have
>> this year. Thus is see this a burden for many smaller and less
>> resourced projects. I am not sure if a pull approach would solve this
>> problem as there still needs to be common ground for projects that
>> need to depend on each other. No EMF would mean no Platform, Xtext,
>> OCL etc.
>> 
>> ~Christian
>> ___
>> 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://www.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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Willink]

Hi

I share Ed and Christian's concerns, and as I wrote earlier the original 
purpose of SimRel was to provide a coherent synchronized release across 
all active projects. The quarterly SimRel has totally undermined that 
because many projects cannot support the faster cadence. Personally, it 
means that I just chuck out my auto-tested builds without manual 
verification. Diligent checks that I used to perform annually have gone 
out the window. I used to use perhaps every other 6 weekly milestone for 
my personal development resulting in many regression bugs getting fixed 
pre-release. Now the regressions get detected after release; it is all 
much much too fast. The final platform RC is done almost before some 
projects have started on their first RC. The only things that can get 
fixed are panics and just look at the number of RC3 respin discussions 
we now have to have because of the unreasonable speed; in the past RC3 
and RC4 were available.


Let's go back to annual SimRels that provide a coherent best endeavours 
release that users can be confident of enhancing by taking on board 
service releases. No longer a brand new different selection of novel 
bugs every quarter.


If projects want to do quarterly intermediate releases, fine, they are 
intermediate releases. Until such time as the high speed community steps 
up and commits the resources to support it, why does the rest of Eclipse 
have to suffer?


The timing of the annual release should be aligned to offer a useable 
rather than experimental latest-Java experience.


(When I advocate annual SimRels, that does not mean I endorse EPPs. 
Personally I only use the base Eclipse SDK ZIP, project ZIPs where 
available and the SimRel P2 as a last resort. I can easily live without 
EPPs, but a synchronized SimRel P2 is critical.)


(As a modelling developer I might be expected to use the Modeling EPP, 
but sadly I find that although ridiculously bloated, it lacks important 
projects and includes one project that I find detrimental to my UX.)


    Regards

        Ed Willink

On 29/01/2020 08:21, Dietrich, Christian wrote:

Hi all,

I personally share Ed's concerns about the direction the Eclipse
SimRel is thrifting. Maintaining 4 Releases a Year in a quite involved
project like Xtext with many dependencies was a lot of work. Also the
move to the new Cloud based Jenkins infrastructure ate a lot of
resources at the Xtext team last year. Resources that we won't have
this year. Thus is see this a burden for many smaller and less
resourced projects. I am not sure if a pull approach would solve this
problem as there still needs to be common ground for projects that
need to depend on each other. No EMF would mean no Platform, Xtext,
OCL etc.

~Christian
___
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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Merks]

Mickael,

Comments below.

On 29.01.2020 09:09, Mickael Istria wrote:

Hi Ed,

as I already mentioned in some previous emails, I'd be personally in 
favor or simply getting rid of SimRel and just evolve EPP to provide 
both the packages and the necessary artifacts for these packages to work.


Yes, I expected such a note from you...

But it seems to me misguided and not grounded in the factual reality.  
It seems mostly based on the the principle/assumption that moving the 
problem will simplify the problem or make existing problems disappear by 
magic.  Currently the train repo is a prerequisite for producing the 
packages and it composes a large set of repositories into a single 
aggregate at which point a high level of consistency is checked and 
ensured.  In the end, ensuring that all the artifacts that comprise each 
package are coherent (and stable) does not go away even if somehow the 
packages were produced by directly pulling content from something other 
than the train repository.  Nothing changes with regard to ensuring 
consistent licenses, signed content, proper inter-operation, stable 
repositories, and mutual instability.  In the end, I'm not even sure if 
you're suggesting that there needs to be no aggregation at all, but 
simply a very large set of direct references to various project 
repositories.  But I can assure you that loading 50 repositories instead 
of 2 when doing an install will not improve the experience, and that 
getting n projects to maintain long-term stable sites is a new problem 
that will also turn into yet another cat herding exercise and when it 
fails (as all things do on occasion), the users will notice immediately.


It feel as if you've joined the discussion years after all the reasons 
for having a train the first place were had, and that you assume there 
really are no good reasons because you were not part of those 
discussions.  So all the reasons need to be reiterated, at which point 
you are highly inclined to try to shoot each one down because they don't 
fit you current conclusion.


In any case, no matter exactly all the concrete details of what you are 
suggesting, the question of who does that work remains the same one.



My reasons to support that is that:
* Marketplace would still be available -> no loss for users


I also pointed out that you could fix your marketplace entry:

  https://www.eclipse.org/setups/marketplace/?id=3394048

That hasn't happened and the fully 1/3 of the marketplace entries are 
completely broken or somewhat broken.  Consistent/correct marketplace 
listings is yet another exercise of cat herding.



* packages would still be available -> no loss for users
So at least we agree that packages are needed.  Unfortunately there's no 
one to produce them.

* installer would still be available -? no loss for users
Here the question is:  Which repositories will contain all the 
artifacts?  How much work will I personally (Oomph) have because of a 
complete change in design in EPP structure?
* SimRel and its strange governance and all the discussions that have 
emerged with it disappear -> time saved
It will only disappear from view, but the identical technical problems 
will simply migrate somewhere else.   Somewhere decentralized?  
Somewhere with no central oversight?  This doesn't not sound like the 
problems will go away, but rather will become invisible to most of us, 
but not for the users.
* EPP starts handing everything, and EPP governance is working well -> 
EDP used efficiently.
The person who does not exist will restructure everything and will 
manage everything personally and none of us will have to do anything at 
all anymore to help that person.  That sounds great in principle, except 
for that person.  And I'm often that person, and I can assure you it's 
not great at all; I often cannot solve problems that come from elsewhere.
* Active contributors like you stop spending effort on projects that 
are not worth it (to you): many projects are in SimRel just by the 
force of habit, but the value for the user community is arguable and 
the cost for maintainers is present (more things to check, more bugs 
to open, more files to watch, longer build time).
Removing projects from the train will be somewhat helpful in reducing 
the overhead.  We could start with EMF and finish with Oomph; that would 
save me personally one hell of a lot of work.  Or did you have specific 
projects in mind that are not worth the effort?
With this proposal, the maintenance cost would be drastically reduced 
and the process be made more streamlined with typical EDP. Hopefully 
this will become simple enough for the few active contributors on 
SimRel (build & infra, not contributions) and EPP to be able to cope 
with this for some years.
Are you volunteering to step up to prototype and demonstrate all the new 
infrastructure that would be involved in your proposal so that we may 
concretely assess how that alternative would work in detail rathe

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Dietrich, Christian]

> Can you please explicit what you mean by "this" in "see this a burden" ?

i mean moving to the new Jenkins>
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Mickael Istria]

On Wed, Jan 29, 2020 at 9:23 AM Dietrich, Christian <
christian.dietr...@itemis.de> wrote:

> Resources that we won't have this year.Thus is see this a burden for many
> smaller and less
> resourced projects.


Can you please explicit what you mean by "this" in "see this a burden" ?
The fact that project doesn't have resource to keep activity isn't a
problem SimRel can or should deal with IMO. If there is no-one interested
in shipping XText in EPP packages  and testing it as part of the package,
then what's the point in aggregating it?


> I am not sure if a pull approach would solve this
> problem as there still needs to be common ground for projects that
> need to depend on each other. No EMF would mean no Platform, Xtext,
> OCL etc.


There is still a common ground, it's just defined in EPP as a
target-platform or whatever similar and it's controlled by EPP
contributors, not by projects who aren't investing in SimRel/EPP.
Platform successfully uses EMF without SimRel and everything works, so this
big common ground isn't something that's strongly required for projects to
be functional.
The deal becomes that if a project wants to be in EPP/SimRel, they have to
invest in testing and maintenance of EPP/SimRel. Currently, it's not the
case, and many SimRel contributions behave as "freeloaders" of others work.
If you want EMF to be and healthy project, then join me in reducing the
amount of effort Ed M spends on cross-project stuff, so he'll be more
available for EMF if he wants to ;) Any energy taken by SimRel/EPP is
energy that's not placed someplace else; in many cases, the energy would be
better getting directly in the projects rather than in the aggregation.
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Dietrich, Christian]

Hi all,

I personally share Ed's concerns about the direction the Eclipse
SimRel is thrifting. Maintaining 4 Releases a Year in a quite involved
project like Xtext with many dependencies was a lot of work. Also the
move to the new Cloud based Jenkins infrastructure ate a lot of
resources at the Xtext team last year. Resources that we won't have
this year. Thus is see this a burden for many smaller and less
resourced projects. I am not sure if a pull approach would solve this
problem as there still needs to be common ground for projects that
need to depend on each other. No EMF would mean no Platform, Xtext,
OCL etc.

~Christian
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Mickael Istria]

Hi Ed,

as I already mentioned in some previous emails, I'd be personally in favor
or simply getting rid of SimRel and just evolve EPP to provide both the
packages and the necessary artifacts for these packages to work.
My reasons to support that is that:
* Marketplace would still be available -> no loss for users
* packages would still be available -> no loss for users
* installer would still be available -? no loss for users
* SimRel and its strange governance and all the discussions that have
emerged with it disappear -> time saved
* EPP starts handing everything, and EPP governance is working well -> EDP
used efficiently.
* Active contributors like you stop spending effort on projects that are
not worth it (to you): many projects are in SimRel just by the force of
habit, but the value for the user community is arguable and the cost for
maintainers is present (more things to check, more bugs to open, more files
to watch, longer build time).
With this proposal, the maintenance cost would be drastically reduced and
the process be made more streamlined with typical EDP. Hopefully this will
become simple enough for the few active contributors on SimRel (build &
infra, not contributions) and EPP to be able to cope with this for some
years.

About enforcing or checking SimRel rules, then they are not really SimRel
rules and checking that or declaring compatibility should be handled by
projects, as part of their releases; not by a downstream consumption.

To summarize, making SimRel become a "pull" project like EPP and not a
"push" project like it is now is IMO the best path to keep the community
able to ship good quality end-users oriented IDE artifacts

Cheers,
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev