Mickael,
Comments below.
On 27.06.2017 13:32, Mickael Istria wrote:
Hi all,
You probably all noticed the "Final Daze" email recently. That has
brought some questions and concerns for some newcomers. I'll go into
details in a few lines, but first, I'd like to ask these generic
questions: What is the value of the Final Daze? What's its cost?
For the cost it's obvious:
* releng effort for any participating projects (setting up
p2.mirrorsUrl for instance)
That should generally be done for update sites with a significantly long
life cycle, i.e., not nightly builds but weekly builds.
* delaying of the release of the individual project although it's
ready and approved
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.
* Deadlines don't scale: what happens if a project owner cannot move
the bits on the right time to the right place?
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...
* delaying announcement -although a particularity of some project
makes it better to announce release immediately...
I would imagine the announcement (authoring) is the cost, and the timing
is not a significant part of that cost.
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".
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 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, 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.
* Doesn't the Foundation plan to enable a transparent mirroring system
very soon that would make all this p2.mirrorsUrl useless?
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.
* Making deliverables invisible: same as the topic about
p2.mirrorsUrl. Do actual end-user hit the project repository directly?
And if they do in advance while the release is ready, why not letting
them do so?
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.
Overall, I have the impression that this Final Daze of SimRel adds
some complexity, constraints and stress there for some cost of
project, and no added-value to typical end-users.
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...
It would most likely be better to get rid of some of those timing
constraints, let project release as usual they want/can conforming to
the usual processes -even if it's earlier-, and focus on the actual
entry point of Simultaneous Release which is the SimRel repo without
putting additional pressure on projects.
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. That's what the train is for and
the train needs some days to mirror before being made public...
So just abandoning the Final Daze TODO-list would be a good
simplification.
What do you think?
Yes and no. :-P 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....
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, at Red Hat Developers <https://developers.redhat.com/>
community
_______________________________________________
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
_______________________________________________
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
