Thanks for sharing this David, it's quite helpful! On Tue, Jun 27, 2017 at 10:11 PM, David Williams <[email protected]> wrote:
> 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. > I agree with you that recent changes in EPP package being made more "modular" make this kind of issues less probable. I also agree that this kind of p2 issues are still possible if users does a mix of multiple p2 sources. In such case of additional sources being added, we cannot control what's added, so I don't think we're really in the scope of SimRel. Or at least, that this user-story isn't really what we and users are expecting of SimRel (SimRel is a big p2 repo which we know all content work consistently one with the other, nothing more). > 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). > Ok. Do you agree with Ed and I that having projects setting up the mirror when they *release* (typically a few weeks before SimRel release) would prevent this issue from happening? > 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. Yes, and thanks for sharing those. It's a matter of trade-off between the responsibility of a project and the responsibility of SimRel. I think it's also important to make the scope of SimRel clear enough (for example "SimRel builds an aggregated p2 repository of projects conforming to quality guidelines and tested to work together in the same p2 repository") and to see what should remain the responsibility of SimRel (build+test+release of the SimRel repo), what should be the responsibility of individual project release process (p2.mirrorsUrl in individual p2 repos, do not leak p2 repositories as touchpoints or other without informing users), and what should be the responsibility of users (avoid mixing p2 repositories unless they feel like p2 experts)...
_______________________________________________ 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
