Skip to main content

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

Hi Ed,

On Tue, Jun 27, 2017 at 2:04 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:

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

So we agree it should be a project release requirement (or at least suggestion), not something bound to SimRel nor somethign that seems to fit well in a "Final Daze"

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

Sure, but the availability of the project contributors may change. And if the amount of work is the same, I don't get why we should delay stuff just because project is in SimRel.

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

Indeed, bits shouldn't move, I over-interpreted. What I tried to refer to is to "hide bits" and then "make them visible". Why requesting those 2 additional steps so late in the train?

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.

While I agree about the ideal scenario, let's consider some real user stories: some projects never dealt with p2.mirrorsUrl because it's not that mentioned in the typical project guidance and requirements, and learn about it only now, as part of a Final Daze. My point is not to remove the requirement/suggestion for p2.mirrorsUrl, but more to remove it from the Final Daze and to make it part of another part of the process (typically project release) to reduce stress on SimRel and ease progressive adoption of good practices by projects, independently of SimRel.
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  With a mirror URL, the download server is not touched at all, i.e., p2 will directly download artifacts from the mirrors.

Thanks, I know what a mirror is :P
But in the context of SimRel, do you really expect end-users to hit directly the individual project sites? In the vast majority of cases, they simply take . This is the repo that's shipped by SimRel and need to be optimized in a Final Daze. Individual projects shouldn't be affected by a Final Daze of the SimRel repo.

No!!!  With mirror URLs, the mirrors are directly accessed with no further access to  With transparent mirroring, the download server remains a bottleneck because it must be consulted in order to redirect "transparently" to some other site.

I understand your concerns and I'm curious about the actual metrics we'll get from download stats with transparent mirroring.
Let's just ignore this topic as part of the "Drop project action items for Simrel Final Daze" attempt as it's not much related.
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.

Still, why preventing projects to update the doc as soon as it's ready?

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. 

Ok, so we're being honest: neither SWTBot nor LSP4E nor most project I've ever been caring about for SimRel did follow that rule neither.
You could ignore some of the rules. :-P  Who will notice?

That's where I hoped this discussion would lead: why enforcing some rules that project either can't and don't want to follow? Wouldn't it be simpler to drop the concept of Final Daze so it would be clear that projects can behave as best for them and still get into SimRel repo?
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...

This is true for the SimRel repo which does require this extra-work. What I don't get with the Final Daze is why it has to drill-down to individual repositories.

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.

This becomes a project-specific choice and issue. Some project are very backward compatible, some others aren't... The goal is to keep them as productive as they can be, and there isn't one process that's going to work for the dozens of projects in SimRel. SimRel has to be more flexible and to remove some of its constraints regarding timing unless they're proven to create big added value of SimRel itself or for the contributing project.

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

So we agree that those rules are only there for intimidation but are actually not enforced? If so, what about just dropping them, save some stress to contibutors and some mailing-list discussions?

Back to the top