[cross-project-issues-dev] SimRel 2018-09 Release Candidate 2 (RC2) staging repo is complete

[Frederic Gurr]

Hi,

Since the SimRel aggregator build is quiet, I declare the staging repo
for 2018-09 RC2 to be complete.

As usual, it can be found here:

=> http://download.eclipse.org/staging/2018-09/

Please note, we will enter quiet days for 2018-09. If no blocking
issues are found, RC2 will become the official 2018-09 release on
Wednesday, September 19th.

Thanks for all your contributions and happy quiet days!

Regards,

Fred

[Mickael Istria]

Corrosion suffers from a blocking issue:
https://github.com/eclipse/corrosion/issues/131 which was included in the
build that's in SimRel.
It seems like we'd be able to fix it promptly.

So if it's easy and not controversial, we'd appreciate if a respin can
happen.

But if it's too hard,
Corrosion is a low popularity plugin, I expect that most installation come
from marketplace (Where we can publish a newer version including the patch
whenever we want) or by downloading the zip (which represents 0.5% of all
downloads). Also, I believe Corrosion is not business-critical to us as
maintainers.
The impact of this bug will be bad, for sure, but maybe not bad enough...

Having said that, I think it's now Planning Council call to take a decision
about whether Corrosion bug triggers a SimRel respin.

[Daniel Megert]

If I recall the process correctly, the project needs to talk to its PMC
which then decides whether to ask the Planning Council for a respin.

Dani



From: Mickael Istria <***@redhat.com>
To: Cross project issues <cross-project-issues-***@eclipse.org>
Date: 14.09.2018 12:18
Subject: Re: [cross-project-issues-dev] SimRel 2018-09 Release
Candidate 2 (RC2) staging repo is complete
Sent by: cross-project-issues-dev-***@eclipse.org



Corrosion suffers from a blocking issue:
https://github.com/eclipse/corrosion/issues/131 which was included in the
build that's in SimRel.
It seems like we'd be able to fix it promptly.

So if it's easy and not controversial, we'd appreciate if a respin can
happen.

But if it's too hard,
Corrosion is a low popularity plugin, I expect that most installation come
from marketplace (Where we can publish a newer version including the patch
whenever we want) or by downloading the zip (which represents 0.5% of all
downloads). Also, I believe Corrosion is not business-critical to us as
maintainers.
The impact of this bug will be bad, for sure, but maybe not bad enough...

Having said that, I think it's now Planning Council call to take a
decision about whether Corrosion bug triggers a SimRel respin.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[Mickael Istria]

New build of Corrosion that's available for SimRel contains a fix for the
blocker issue. A respin of SimRel should automatically grab it.

Hi PMC,
Corrosion suffers from a blocking issue: https://github.com/eclipse/cor
rosion/issues/131 which was included in the build that's in SimRel.
It seems like we'd be able to fix it promptly.
So if it's easy and not controversial, we'd appreciate if a respin can
happen.
But if it's too hard,
Corrosion is a low popularity plugin, I expect that most installation come
from marketplace (Where we can publish a newer version including the patch
whenever we want) or by downloading the zip (which represents 0.5% of all
downloads). Also, I believe Corrosion is not business-critical to us as
maintainers.The impact of this bug will be bad, for sure, but maybe not bad
enough...
Affected people will be mostly those who have already an EPP package
installed and run an upgrade against newer SimRel. However, IIRC, this
process is disabled by default.
Should we trigger a respin request process, or just live with a broken
Corrosion in SimRel or ... ?
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

[Ed Merks]

Mickael,

I can see in the SimRel commits that Ed and Karsten have done SimRel
commits for their changes:

Thanks Karsten and Ed for the efforts over the weekend!

From the absence of commits for your changes, I assumed that Corrosion
would be using some generic URL to contribute to SimRel, i.e., a URL for
which the contents of the repository can change over time such that you
didn't need to update SimRel itself. Looking at the details, it looks
like you're using http://download.eclipse.org/corrosion/snapshots/ as
the URL. Several other contributions you made 7 days ago use this same
approach of pointing at "snapshots".  I was under the impression that
the general policy for SimRel contributions is that the URLs should
point at stable locations (or that the version of the contributions
should be specified).  To avoid problems in the future, I would suggest
that your SimRel updates to use non-released versions (the development
stream builds) of your contributions ought to be done much earlier in
the SimRel process; then the problems would have been found much earlier
(or at least could have been found much earlier).

I'm also wondering now about the general policy of the URLs in SimRel
*.aggrcon.  I ask because I could certainly spare effort by pointing my
EMF contributions at the following URL:

http://download.eclipse.org/modeling/emf/emf/builds/milestone/latest

Then whenever I do a new milestone build it would automatically be in
SimRel.  That would be convenient for me, but I see several potential
problems with this:

1. I would have to be careful when I do my milestone builds.
2. I would never commit changes to SimRel, so I would never verify that
my latest contribution doesn't cause problems; only others would
notice problems caused by my fluctuating contributions, i.e., when
they commit their changes.
3. At the end of the SimRel release cycle, there would be no stable set
of URLs from which the results could be re-aggregated.

This all makes me wonder what is the general policy on the SimRel
contribution URLs and their stability.  I.e., is it possible (should it
be possible) to respin SimRel 2018-09 say two weeks from today and end
up with the same results as we do when we respin today?

While I'm questioning about how all this should work, I would like to
point out that it would be awfully nice that when I commit changes to
EMF's contribution, I didn't end up with all this in my staging view:

This seems to be the result of textual editing of the files.

I'd like to remind contributors that it's trivially easy to create a
specialized installation for working with the SimRel repo using the
installer:

Regards,
Ed

Post by Mickael Istria
New build of Corrosion that's available for SimRel contains a fix for
the blocker issue. A respin of SimRel should automatically grab it.
Hi PMC,
https://github.com/eclipse/corrosion/issues/131
<https://github.com/eclipse/corrosion/issues/131> which was
included in the build that's in SimRel.
It seems like we'd be able to fix it promptly.
So if it's easy and not controversial, we'd appreciate if a respin
can happen.
But if it's too hard,
Corrosion is a low popularity plugin, I expect that most
installation come from marketplace (Where we can publish a newer
version including the patch whenever we want) or by downloading
the zip (which represents 0.5% of all downloads). Also, I believe
Corrosion is not business-critical to us as maintainers.The impact
of this bug will be bad, for sure, but maybe not bad enough...
Affected people will be mostly those who have already an EPP
package installed and run an upgrade against newer SimRel.
However, IIRC, this process is disabled by default.
Should we trigger a respin request process, or just live with a
broken Corrosion in SimRel or ... ?
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc

[Ed Willink]

Hi Ed

I posted earlier making the same observation about stable URLs.

When updating a SimRel aggrcon contribution, it is much easier to do a
text edit on just one file to change the URL, (then cut and paste to
Install New Software... to check for typos / broken repo).

The aggrcon tooling is only necessary for 'global' changes
(addition/removal/reordering/renaming) such as features and committer names.

I think the 'everything has changed' is because new lines evolve,
possibly because the aggrcon tooling has not picked up recent EMF fixes,
possibly because it still needs to impose the project Unix+UTF-8 settings.

(Some users favour some GIT config magic that I don't understand and for
which I have seen conflicting advice. Perhaps the confusion / lack of
compliance is a problem and might even be changing files.)

IMHO Once the project specifies Unix+UTF-8 and tooling respects the
project settings, CM tool settings cease to be an issue.)

Regards

Ed Willink

Post by Ed Merks
Mickael,
I can see in the SimRel commits that Ed and Karsten have done SimRel
Thanks Karsten and Ed for the efforts over the weekend!
From the absence of commits for your changes, I assumed that Corrosion
would be using some generic URL to contribute to SimRel, i.e., a URL
for which the contents of the repository can change over time such
that you didn't need to update SimRel itself.  Looking at the details,
it looks like you're using
http://download.eclipse.org/corrosion/snapshots/ as the URL.  Several
other contributions you made 7 days ago use this same approach of
pointing at "snapshots".  I was under the impression that the general
policy for SimRel contributions is that the URLs should point at
stable locations (or that the version of the contributions should be
specified).  To avoid problems in the future, I would suggest that
your SimRel updates to use non-released versions (the development
stream builds) of your contributions ought to be done much earlier in
the SimRel process; then the problems would have been found much
earlier (or at least could have been found much earlier).
I'm also wondering now about the general policy of the URLs in SimRel
*.aggrcon.  I ask because I could certainly spare effort by pointing
http://download.eclipse.org/modeling/emf/emf/builds/milestone/latest
Then whenever I do a new milestone build it would automatically be in
SimRel.  That would be convenient for me, but I see several potential
1. I would have to be careful when I do my milestone builds.
2. I would never commit changes to SimRel, so I would never verify
that my latest contribution doesn't cause problems; only others
would notice problems caused by my fluctuating contributions,
i.e., when they commit their changes.
3. At the end of the SimRel release cycle, there would be no stable
set of URLs from which the results could be re-aggregated.
This all makes me wonder what is the general policy on the SimRel
contribution URLs and their stability.  I.e., is it possible (should
it be possible) to respin SimRel 2018-09 say two weeks from today and
end up with the same results as we do when we respin today?
While I'm questioning about how all this should work, I would like to
point out that it would be awfully nice that when I commit changes to
This seems to be the result of textual editing of the files.
I'd like to remind contributors that it's trivially easy to create a
specialized installation for working with the SimRel repo using the
Regards,
Ed

Post by Mickael Istria
New build of Corrosion that's available for SimRel contains a fix for
the blocker issue. A respin of SimRel should automatically grab it.
Hi PMC,
https://github.com/eclipse/corrosion/issues/131
<https://github.com/eclipse/corrosion/issues/131> which was
included in the build that's in SimRel.
It seems like we'd be able to fix it promptly.
So if it's easy and not controversial, we'd appreciate if a
respin can happen.
But if it's too hard,
Corrosion is a low popularity plugin, I expect that most
installation come from marketplace (Where we can publish a newer
version including the patch whenever we want) or by downloading
the zip (which represents 0.5% of all downloads). Also, I believe
Corrosion is not business-critical to us as maintainers.The
impact of this bug will be bad, for sure, but maybe not bad enough...
Affected people will be mostly those who have already an EPP
package installed and run an upgrade against newer SimRel.
However, IIRC, this process is disabled by default.
Should we trigger a respin request process, or just live with a
broken Corrosion in SimRel or ... ?
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc

_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Ed Merks]

Ed,

Comments below.

Post by Ed Willink
Hi Ed
I posted earlier making the same observation about stable URLs.
When updating a SimRel aggrcon contribution, it is much easier to do a
text edit on just one file to change the URL,

It is also much more error prone.

Post by Ed Willink
(then cut and paste to Install New Software... to check for typos /
broken repo).

The Repository Explorer is great for checking that a p2 repository is
well formed and that it actually contains the things you're expecting.

Post by Ed Willink
The aggrcon tooling is only necessary for 'global' changes
(addition/removal/reordering/renaming) such as features and committer names.

The tooling can also verify the integrity of the aggregation before you
do a commit.

Post by Ed Willink
I think the 'everything has changed' is because new lines evolve,
possibly because the aggrcon tooling has not picked up recent EMF
fixes, possibly because it still needs to impose the project
Unix+UTF-8 settings.

No, mostly not that type of problem.

Post by Ed Willink
(Some users favour some GIT config magic that I don't understand and
for which I have seen conflicting advice. Perhaps the confusion / lack
of compliance is a problem and might even be changing files.)

No, it's mostly just plain textual XML editing that's involved, and a
little bit wrong line endings...

Post by Ed Willink
IMHO Once the project specifies Unix+UTF-8 and tooling respects the
project settings, CM tool settings cease to be an issue.)
Regards
Ed Willink

Post by Ed Merks
Mickael,
I can see in the SimRel commits that Ed and Karsten have done SimRel
Thanks Karsten and Ed for the efforts over the weekend!
From the absence of commits for your changes, I assumed that
Corrosion would be using some generic URL to contribute to SimRel,
i.e., a URL for which the contents of the repository can change over
time such that you didn't need to update SimRel itself.  Looking at
the details, it looks like you're using
http://download.eclipse.org/corrosion/snapshots/ as the URL.  Several
other contributions you made 7 days ago use this same approach of
pointing at "snapshots".  I was under the impression that the general
policy for SimRel contributions is that the URLs should point at
stable locations (or that the version of the contributions should be
specified).  To avoid problems in the future, I would suggest that
your SimRel updates to use non-released versions (the development
stream builds) of your contributions ought to be done much earlier in
the SimRel process; then the problems would have been found much
earlier (or at least could have been found much earlier).
I'm also wondering now about the general policy of the URLs in SimRel
*.aggrcon.  I ask because I could certainly spare effort by pointing
http://download.eclipse.org/modeling/emf/emf/builds/milestone/latest
Then whenever I do a new milestone build it would automatically be in
SimRel.  That would be convenient for me, but I see several potential
1. I would have to be careful when I do my milestone builds.
2. I would never commit changes to SimRel, so I would never verify
that my latest contribution doesn't cause problems; only others
would notice problems caused by my fluctuating contributions,
i.e., when they commit their changes.
3. At the end of the SimRel release cycle, there would be no stable
set of URLs from which the results could be re-aggregated.
This all makes me wonder what is the general policy on the SimRel
contribution URLs and their stability.  I.e., is it possible (should
it be possible) to respin SimRel 2018-09 say two weeks from today and
end up with the same results as we do when we respin today?
While I'm questioning about how all this should work, I would like to
point out that it would be awfully nice that when I commit changes to
This seems to be the result of textual editing of the files.
I'd like to remind contributors that it's trivially easy to create a
specialized installation for working with the SimRel repo using the
Regards,
Ed

Post by Mickael Istria
New build of Corrosion that's available for SimRel contains a fix
for the blocker issue. A respin of SimRel should automatically grab it.
Hi PMC,
https://github.com/eclipse/corrosion/issues/131
<https://github.com/eclipse/corrosion/issues/131> which was
included in the build that's in SimRel.
It seems like we'd be able to fix it promptly.
So if it's easy and not controversial, we'd appreciate if a
respin can happen.
But if it's too hard,
Corrosion is a low popularity plugin, I expect that most
installation come from marketplace (Where we can publish a newer
version including the patch whenever we want) or by downloading
the zip (which represents 0.5% of all downloads). Also, I
believe Corrosion is not business-critical to us as
maintainers.The impact of this bug will be bad, for sure, but
maybe not bad enough...
Affected people will be mostly those who have already an EPP
package installed and run an upgrade against newer SimRel.
However, IIRC, this process is disabled by default.
Should we trigger a respin request process, or just live with a
broken Corrosion in SimRel or ... ?
--
Mickael Istria
Eclipse IDE
<https://www.eclipse.org/downloads/eclipse-packages/> developer,
for Red Hat Developers <https://developers.redhat.com/>
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc

_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[Karsten Thoms]

I suppose that from our side (Xtext) all necessary steps are done and the respin will occur. Otherwise, please guide us what we have to do and we’ll immediately address it. If there is a scheduled time for the respin please let us know.

Thanks,
~Karsten

[Mickael Istria]

Post by Ed Merks
From the absence of commits for your changes, I assumed that Corrosion
would be using some generic URL to contribute to SimRel, i.e., a URL for
which the contents of the repository can change over time such that you
didn't need to update SimRel itself.

Right.

Post by Ed Merks
Looking at the details, it looks like you're using
http://download.eclipse.org/corrosion/snapshots/ as the URL. Several
other contributions you made 7 days ago use this same approach of pointing
at "snapshots". I was under the impression that the general policy for
SimRel contributions is that the URLs should point at stable locations (or
that the version of the contributions should be specified). To avoid
problems in the future, I would suggest that your SimRel updates to use
non-released versions (the development stream builds) of your contributions
ought to be done much earlier in the SimRel process; then the problems
would have been found much earlier (or at least could have been found much
earlier)

I fully agree with that, and supports is fully, and I realize that by doing
this, I'm acting against a rule I support all the time and even I did write
down in the wiki.

One thing to notice is that while the doc is full of recommendation, it's
still possible for h4c|<3rs like me to not honor those rule. I'd like to
mention that if the build were failing in such case, it would prevent
people from pushing such bad content. To me, SimRel build is too permissive.

My faulty behavior is typically caused by prioritizing project community
(so the patch cascade as fast a possible in EPP) over SimRel
recommendations. Since Corrosion is a "leaf" project with very low
audience, I thought I could let SimRel pick whatever is the latest and then
to tag/promote the bits after SimRel release according to the content that
goes into SimRel. Unfortunately, because we don't have resources to do more
QA on Corrosion, a blocker was included in SimRel this time. The deep issue
here isn't the URL, but more the absence of testing/QA. It's somehow
exactly the same than releasing without testing
But I hope that with Corrosion (and others) becoming more mature and also
me -and hopefully some other people caring about the project at some point-
becoming more used to the new schedule and not feel surprised that it's
already too late, it will be easier to follow the rules.

This all makes me wonder what is the general policy on the SimRel

Post by Ed Merks
contribution URLs and their stability.

It's documented in
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Format
(as you can see, documentation is SimRel is perfect to cover your concerns,
it's really my own fault here, and -partly- the fault of the tool not
enforcing the rules strongly enough).

Post by Ed Merks
I.e., is it possible (should it be possible) to respin SimRel 2018-09 say
two weeks from today and end up with the same results as we do when we
respin today?

With URLs like /snapshots or /milestones and moveable content in them and
no specific version, it's very unlikely that the build is reproducible. But
again, if everyone were playing by the rules of
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Format
then it would be reproducible.

[Lorenzo Bettini]

Post by Ed Merks
I'd like to remind contributors that it's trivially easy to create a
specialized installation for working with the SimRel repo using the

Hi Ed

this is slightly offtopic, but since you mentioned this specialized
installation with Oomph for contributing to Simrel (which I wasn't aware
of), it might be very helpful if you could add this to
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build
e.g., in the configuration section.

cheers
Lorenzo