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.
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:
- I would have to be careful when I do my milestone builds.
- 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.
- 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.
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
