<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 9, 2021 at 9:54 AM Adriaan de Groot <<a href="mailto:groot@kde.org">groot@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Frameworks 5.86 haven't been released yet; from the calendar it looks like <br>
that will happen next week. However, there's a couple of Linux distro's that <br>
have packages up already. This makes the <a href="http://repology.org" rel="noreferrer" target="_blank">repology.org</a> feed for frameworks a <br>
little weird -- 5.86.0 is "green" because it's latest, because it's available <br>
from two (?) distro's, but it's not officially released.<br>
<br>
Nearly everyone is red, because they ship the released 5.85.0.<br>
<br>
Regular people who might want to build-from-source (released tarballs, not <br>
git) can't even get the 5.86 tarballs yet.<br>
<br>
I happen to have access to the FreeBSD packaging "stage" tree, so I can see <br>
that Tobias -- who has access to that tree, and **also** access to the pre-<br>
release tarballs -- has prepared the packages for the release, but not pushed <br>
the button to move it from staging to the real tree. Pushing that button would <br>
break source builds for me, a regular(-ish) user, because I can't fetch the <br>
pre-release tarballs.<br>
<br>
Anyway, long-story short:<br>
- should distro's be packaging up pre-release tarballs?<br></blockquote><div><br></div><div>That is the intention of providing the pre-release tarballs, yes.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- is there a polite tap-on-the-shoulder kind of message to send to distro's if <br>
the answer is "no", to remind them not to push out packages before the dust <br>
settles? (e.g. for respins &c)<br></blockquote><div><br></div><div>If memory serves, the agreement for pre-release tarballs is that distributions may package and test them internally, but they're not to make them available to general users.</div><div>Where possible this should be achieved by protecting access to the repository/archives, however if distribution systems don't allow for that then they are supposed to make use of a location that is not advertised and only share the details of that location with people in their own teams.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
[ade]</blockquote><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div>