Bug 471137

Comment 1 Alexander Nyßen 2015-06-26 12:09:09 EDT

That's true, we currently merge our releases into a single site.

Comment 2 Ed Willink 2015-06-26 12:58:48 EDT

(In reply to Alexander Nyßen from comment #1)
> That's true, we currently merge our releases into a single site.

which also corrupts e.g. SR0 with SR1.

Comment 3 Alexander Nyßen 2015-06-26 13:01:57 EDT

(In reply to Ed Willink from comment #2)
> (In reply to Alexander Nyßen from comment #1)
> > That's true, we currently merge our releases into a single site.
> 
> which also corrupts e.g. SR0 with SR1.

No, why should it?

Comment 4 Ed Willink 2015-06-26 13:27:04 EDT

Because there is no 'key' to access SR0. A simple repo provides typically just the latest since that is all the consumer can ask for.

In my Hudson Buckminster *.rmap I need to specify something like :

      <rm:uri format="{0}/tools/gef/updates/releases/3.10.0">

but have to make do with

      <rm:uri format="{0}/tools/gef/updates/releases">

which is ok today since 3.10.0 is the best content, but after SR1, SR0 is corrupted (occluded) by the SR1 content, and after Neon, a LTS Mars maintenance build gets really hard.

Comment 5 Alexander Nyßen 2015-06-26 14:26:00 EDT

(In reply to Ed Willink from comment #4)
> Because there is no 'key' to access SR0. A simple repo provides typically
> just the latest since that is all the consumer can ask for.
> 
> In my Hudson Buckminster *.rmap I need to specify something like :
> 
>       <rm:uri format="{0}/tools/gef/updates/releases/3.10.0">
> 
> but have to make do with
> 
>       <rm:uri format="{0}/tools/gef/updates/releases">
> 
> which is ok today since 3.10.0 is the best content, but after SR1, SR0 is
> corrupted (occluded) by the SR1 content, and after Neon, a LTS Mars
> maintenance build gets really hard.

I would not expect clients to consume 3.10.0 after we have officially released a compatible 3.10.1 bugfix release. And even if, we do not remove the SR0 contents from the releases site when publishing SR1, so both are still available. And I know of build systems that support upper version constraints...

Comment 6 Ed Willink 2015-06-26 14:38:32 EDT

You seem to miss the point.

It is conventional to consume products with e.g. a 3.9 to 4.0 bound range, but a maintenance build should be reproducble, so the contributions to the build are determined by the builder without modifying source code or features.

Other projects with a composite releases repo and/or individual releases repo satisfy this without a problem. It is the irregular GEF repo that is inhibiting conventional usage and reproducible builds.

You might not expect consumers to require SR0 after SR1 but accidents happen, SR1 might be bad. Much more commonly, SR1 may be suspected to be bad, so narrowing down a releng nightmare requires SR0 to be used to demonstrate that SR1 is not bad. Given our current excitements with changing Java versions and license certificates, provision of releases is particularly important.

Comment 7 Alexander Nyßen 2015-06-27 03:43:43 EDT

(In reply to Ed Willink from comment #6)
> You seem to miss the point.
> 
> It is conventional to consume products with e.g. a 3.9 to 4.0 bound range,
> but a maintenance build should be reproducble, so the contributions to the
> build are determined by the builder without modifying source code or
> features.
> 
> Other projects with a composite releases repo and/or individual releases
> repo satisfy this without a problem. It is the irregular GEF repo that is
> inhibiting conventional usage and reproducible builds.
> 
> You might not expect consumers to require SR0 after SR1 but accidents
> happen, SR1 might be bad. Much more commonly, SR1 may be suspected to be
> bad, so narrowing down a releng nightmare requires SR0 to be used to
> demonstrate that SR1 is not bad. Given our current excitements with changing
> Java versions and license certificates, provision of releases is
> particularly important.

I think I got the point quite fine. I know the advantages of a composite repo, and had planned migrating to it already (when switching to a HIPP and discontinuing support for drop files). 

Its more that I don't like the way you are arguing here. The repo has been like this since 2008 and it did not suddenly become 'irregular' or 'corrupt'. And using respective p2 and tycho technologies I am sure I can reconstruct each individual release from it properly. If we would ship a 'bad' SR, we could still ship a hotfix, so I would still expect adopters to not fall back to an SR0 after we have shipped SR1. And if they wanted, they could still use a drop file, which is still available for each release, or they could consume our contribution from the respective simrel repo. So the fact that our update site is not yet a composite site is not the blocker your argumentation implies.

Comment 8 Ed Willink 2015-06-27 03:54:35 EDT

(In reply to Alexander Nyßen from comment #7)
> fact that our update site is not yet a composite site is not the blocker
> your argumentation implies.

It is certainly not a blocker (it's major).

I noticed the problem when upgrading my MARS release build to a MARS maintenance build. I'm unable to tie down the release precisely.

GEF has had very good stability over the years which is perhaps why this has not been observed before.

I raise the bug to highlight the deviation from best practice.

Comment 9 Alexander Nyßen 2015-07-10 04:37:04 EDT

I migrated the releases site into the composite site as part of bug #471151. Resolving as fixed in 3.10.1M2.