|Re: [cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze" in SimRel?|
That should generally be done for update sites with a significantly long life cycle, i.e., not nightly builds but weekly builds.* releng effort for any participating projects (setting up p2.mirrorsUrl for instance)
That's mostly an issue of announcements and "making the update site visible"...Â The amount of work does not change depending on when it's done.* delaying of the release of the individual project although it's ready and approved
The bits shouldn't move.Â Mirror depends on the bits staying in place.Â The bits should be there for a long time already.Â They can be placed where they should be immediately...* Deadlines don't scale: what happens if a project owner cannot move the bits on the right time to the right place?
The p2 update site should be in place and should already include the mirrors URL.ÂÂ This is just generally a good thing even if not on the release train.Â Timing should not be an issue.
For the risk: tweaking p2 metadata to set up p2.mirrorsUrl in the last week before release is definitely something most of us would prefer to avoid, especially in the context of a "Daze".
No, mirrors are super important because without mirror URLs, all requests for artifacts will be served by download.eclipse.org.Â With a mirror URL, the download server is not touched at all, i.e., p2 will directly download artifacts from the mirrors.For the value, it's more discussable:
* end-users only care about SimRel repo, EPP packages and installer. Those are the only artifacts they face. They're actually not much dealing with individual p2 repos, so all optimization regarding p2.mirrorsURL at that point of time most likely have a very low impact on users and bandwidth in general.
No!!!Â With mirror URLs, the mirrors are directly accessed with no further access to download.eclipse.org.Â With transparent mirroring, the download server remains a bottleneck because it must be consulted in order to redirect "transparently" to some other site.
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.
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.ÂBlocking release availability isn't really making projects feel more agile thanks to SimRel...
You could ignore some of the rules. :-PÂ Who will notice?
But of course for projects with "deep dependencies" on other projects, the user will prefer to get all dependencies from the train, and of course the train repo must be made visible after there are mirrors for it, so there is a inherent delay process in order to do this right...
Yes, that not unreasonable.Â But as I said, what's the point of announcing your project's release if you have to tell the users where to get all the released dependencies.
There's no police to monitor what you do with your project, and there will be no lawyers sent after you if you fail to comply.Â And, if there are lots of dependencies on your project, you can't be kicked off the train....