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?

Mickael,

Comments below.


On 27.06.2017 14:30, Mickael Istria wrote:
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"
Yes, projects should just do this as good citizens to help keep the download server from being overloaded.

* 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.
As I said, I just ignored this for EMF.

* 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?
It could be a problem if your project depends on releases of other projects (because it depends on things new to that release), but the train with those bits isn't available yet...  That's not the case for EMF so I don't worry about this...


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.
Yes, learning it late is kind of bad.
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.
I totally agree.  It should be just part of building a good long-lived update site at Eclipse regardless of being on the train.
 
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.

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?
With discovery URLs and p2 update site touch points, that might well happen, yes.
In the vast majority of cases, they simply take http://download.eclipse.org/releases/oxygen . 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 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.

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.
Yes, if transparent mirroring helps the server that's great, but there's nothing better than having the server not be hit at all so that it can focus on serving up metadata and not be involved in artifact transactions at all, even in a minimal way.
 
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?
I think it's probably more an issue of user confusion.  It's certain conceptually easier for the user to see all projects released at once.  And, as I said above, it's an issue of dependencies.  The train is all about getting a consistent set of dependencies all in one place for one stop shopping.   But in the end, projects can and some do release on their own schedules, independent of the train...

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.
Wicked. Evil!!
 
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?
I can see why it's good practice to announce and make available all projects at once.  If there are reasonable reasons that some projects not to do that, it shouldn't be a big deal.
 
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, the mirror stuff is just general best practice, and of course simple repositories need to be available to mirror them.  So it's mostly an issue of when project releases become visible in composite repositories, i.e., in a "releases" composite.  I can see some value in having all this happen at once, but it is a burden this time of year to make that happen.  Dennis Hübner does the releng work for EMF and I'm not going to make life more complicated for him.  If it's easier to make this available earlier, I'm fine if he does that.  I'm just grateful he does the work at all!!

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.
Yes, I think it should be more of a guideline than a strict rule...

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

:D
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?
I think as a guideline it is good practice to make it all look coordinated, but if they're a source of stress, the project should do what's best for the project.  But that's just my opinion. :-)


_______________________________________________
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


Back to the top