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
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 <[email protected]
<mailto:[email protected]>> wrote:
Hi PMC,
Corrosion suffers from a blocking issue:
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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
