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