Re: [cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze"

[Ed Merks <ed.merks@xxxxxxxxx>]

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 developer, at Red Hat Developers community

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev