Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze" in SimRel?

On 06/27/2017 08:04 AM, Ed Merks wrote:
The update sites are only hidden by virtue of not telling the user the location of the update site. Making it visible is mostly about publishing the location in documentation somewhere, or by updating a composite to point at it.
Blocking release availability isn't really making projects feel more agile thanks to SimRel...
To be honest, for the EMF builds, we just kind of ignored this. We don't do any big announcement, but someone installing from various composites will install EMF 2.13.

In many cases, it will work fine if someone updates their composites early, but not necessarily all cases. At least, historically, there have been cases where a user will be told "updates are available" but then when they try to apply them will be told "those updates conflict" with something else they have installed, and then given a list of (possibly confusing) choices (such as, "remove web tools so that emf can be updated?" [to paraphrase, and it is just a hypothetical example]). Perhaps, these days, these mismatches would occur less often than in the past but I suspect not completely and the more projects violated the "Simultaneous" aspect of update sites the more likely users would see issues. That is the core technical reason why there is a Simultaneous Release in the first place.

Another reason (again, historically) is more mechanical: If some projects (especially large ones) were available for updates early then potentially hundreds of thousands of "update downloads" would be occurring at the same time the mirrors were trying to download gigabits (from other projects) to get fully populated and they would less able to do so. In other words, a network bottleneck: downloads for updates would be slow since there were so few mirrors, and mirrors could not get populated because there were so many downloads. You can avoid this bottleneck by having bits in place (so mirrors can get them) but to not update the composites until the appointed day (so that users will not be doing mass updates early).

I am glad when I see efforts made to improve the Sim Rel processes, but I wanted to be sure you kept these factors in mind as you did. These factors tend to be forgotten when they do not occur -- and they have not occurred for many years (I believe) because most projects follow the recommended procedures.

Back to the top