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