Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [tools-pmc] SimRel 2018-09 Release Candidate 2 (RC2) staging repo is complete


Comments below.

On 17.09.2018 09:44, Ed Willink wrote:

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.

(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.

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.

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.

(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...

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


Ed Willink

On 17/09/2018 08:12, Ed Merks wrote:


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 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:

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:


On 17.09.2018 08:33, Mickael Istria wrote:
New build of Corrosion that's available for SimRel contains a fix for the blocker issue. A respin of SimRel should automatically grab it.

On Fri, Sep 14, 2018 at 12:29 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

Corrosion suffers from a blocking issue: 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 developer, for Red Hat Developers

Mickael Istria
Eclipse IDE developer, for Red Hat Developers

tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top