Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] What are the new simrel URLs for the post-Photon trains?
I like the idea of collapsing the various timestamped pre-GA milestone folders under /releases/[thing]/ down to a single aggregate repo once the release is done, since I imagine don't want/need/care about compositing the M1, M2, M3, RCx bits once the Final stuff is GA. 

And as you point out, we'd get better performance with fewer iterations though nested composite metadata.

Cheers,

Nick


On Fri, Jun 29, 2018 at 1:16 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:

Nick,

Comments below.


On 29.06.2018 18:04, Nick Boldt wrote:
I'm good with 2018-09 being the new folder for /staging/[thing]/ and /releases/[thing]/ as long as there's also a /staging/latest/ and /releases/latest/ that we can use to test rolling release updates.
Adding a staging/latest also seems like a good idea to me.  The releases/latest already exists.  Of course both needs to be updated periodically: staging/latest when the first new staging build exists and releases/latest when the final release exists (and is made public).

See further discussion on these BZ & the EPP list:


As to the structure/format/type of the /staging/2018-09/ folder and the /releases/2018-09/ folder, I expect it would be the same as we have today for the /photon/ folders: 

* /releases/[thing]/ is a composite of datestamped milestone releases
Yes.  Thought at the end of the cycle it could become a simple repository.  Or it could become a composite with a single datestamped release, like what the existing folders did, though in the older structure it was expected that a new child would be added for the .1, .2, and .3 update, which of course will no longer happen for 2018-09, leaving the option open for it to be a simple repository.   The advantage of a simple repository is that the client doesn't need to read a composite repo first in order to make another round trip to read the one simple repo.  Better for the client and the server if the repository is simple...
* /staging/[thing]/ is a simple repo, being the "latest" staging bits.

All good then?
Yes, that seems to the most consistent with the previous approach.  I like the idea of adding staging/latest as a nice addition.

Thanks as always for your constructive contributions.


On Thu, Jun 28, 2018 at 10:09 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:

Nick,

Comments below.


On 28.06.2018 15:49, Nick Boldt wrote:
I thought the intent from 2018-09 onward was that all the quarterly releases would share a common URL so they could be updates for each other, rather than treating them as separate, incompatible, and distinct.
But 2018-09 is an update for photon and all the other repos in what was always the common base URL.  Why do we need a new common one?

Thus we could have:


If we want unique releases... but we still need that /simrel/ folder to be a composite site of its children, so that http://download.eclipse.org/staging/simrel/ can be used to update from 2018-09 to 2019-06 and beyond.
No, we don't need that.  We don't have a composite for all releases and I don't think we should start having one because that will just grow and grow so using it will perform poorly and will be bad for the server.  So not only don't I think we need one we should avoid creating composites that are of questionable usage, i.e., ones that will grow unbounded over the years.  We already have releases/latest that people can use, and it always has one child with a well defined meaning (currently pointing at photon).

(And of course for every /staging/ folder there would be an equivalent /releases/ folder.)
Yes, but see my comment about the staging/photon folder being a simple repository but the correspondingly named one in releases/photon is a composite.  This is way I'm asking you to be clear about all the structure, including what's a simple repository and what's a composite repository.

Does that help to clarify the purpose and the need?
Yes, but it makes it clear that I disagree.  :-(  

I would propose that we keep exactly the current structure and use 2018-09 in place of where we currently use photon.   Perhaps the end result in in September 2018 will be that the folder 2018-09 starts out as a composite of all the milestones and release candidates, but at the end of the release cycle, it becomes a simple repository.    Alternatively it stays a composite with a single child, as is the case for photon, which will never have another child added to it...

Nick


On Thu, Jun 28, 2018 at 9:39 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:

FYI, For those who don't know what folders are there now, this is how it looks:

I thought the general consensus was to create a new 2018-09 in directly parallel to these.  So I'm not sure the point of a new intermediate container folder, because regardless of what we call it, won't it still have to have a subfolder with a name like 2018-09? Or are you suggesting simrel itself be directly the name for the 2018-09 release (because the name to be used for the next one)?

Perhaps you can outline what folders you think should/will all exist and which will represent composites and which will represent simple repositories?  For example, all the folders in staging are currently simple repositories.  All the folders in releases are currently composites with nested folders representing releases/milestones.  I could imagine the simple approach is we continue to follow this same approach and use 2018-09 in place of ++photon.  So I'm not sure exactly what you're proposing nor how that will look for ++++photon.

Regards,
Ed


On 28.06.2018 15:21, Nick Boldt wrote:
Greetings Planning Council,

I don't recall if we ever formalized what URL segment we agreed to use for the post-Photon train update sites.

So, I've asked webmaster to create two new folders called "simrel" for now:

If you have any better suggestions (quark? queue? tres? train?), or want to upvote the request, here's the BZ:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=536420

Cheers,

--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com


“The Only Thing That Is Constant Is Change” - Heraclitus


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com


“The Only Thing That Is Constant Is Change” - Heraclitus


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com


“The Only Thing That Is Constant Is Change” - Heraclitus


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com



“The Only Thing That Is Constant Is Change” - Heraclitus

Back to the top