So, we have this bug* where some images are failing to be built, and it happened that the SoaS spin and Design and Jam labs ended up not succeeding in what became the official release. They aren't release blocking, so this is fine "by the books", but it seems unfortunate to miss them due to what's basically a tools bug rather than something inherently wrong with them.
Obviously they missed the official cut and won't get synced out with the rest, but I think the download numbers for these are niche enough that it's probably okay to host them separately.
As I understand it, someone could just keep submitting the builds until they happen to work, right? (And this might actually provide some valuable debug info, because we can compare what works and what doesn't.) Then, we could put those in /pub/alt or something and have the spins/labs websites link to that. (These could be then signed with the official key and etc.)
Or, Adam W suggested that we could instead link to nightlies, with a footnote or something on the websites.
* https://bugzilla.redhat.com/show_bug.cgi?id=1315541
On Mon, Jun 20, 2016 at 09:15:41AM -0400, Matthew Miller wrote:
So, we have this bug* where some images are failing to be built, and it happened that the SoaS spin and Design and Jam labs ended up not succeeding in what became the official release. They aren't release blocking, so this is fine "by the books", but it seems unfortunate to miss them due to what's basically a tools bug rather than something inherently wrong with them.
Peter tells me there's a releng meeting in an hour or so... can we add this to that agenda?
On Monday, June 20, 2016 9:15:41 AM CDT Matthew Miller wrote:
So, we have this bug* where some images are failing to be built, and it happened that the SoaS spin and Design and Jam labs ended up not succeeding in what became the official release. They aren't release blocking, so this is fine "by the books", but it seems unfortunate to miss them due to what's basically a tools bug rather than something inherently wrong with them.
Jam failed due to package issues, its package set was not installable, dnf aborted the transactionso anaconda failed to install, it will be getting removed and will have to follow the process for a new spin if it is to ever come back, same as any spin that misses the boat, however given that SoaS and Design Suite were not at fault they do not have to go though the review process again. though looking at the spins wiki pages, they are massively outdated as no one is really guding the spins anymore. https:// fedoraproject.org/wiki/Spins_SIG the list of spins for fedora 24 is incorrect it is missing Astronomy for instance. The policy may have only ever been documented in emails to the list.
Obviously they missed the official cut and won't get synced out with the rest, but I think the download numbers for these are niche enough that it's probably okay to host them separately.
As I understand it, someone could just keep submitting the builds until they happen to work, right? (And this might actually provide some valuable debug info, because we can compare what works and what doesn't.) Then, we could put those in /pub/alt or something and have the spins/labs websites link to that. (These could be then signed with the official key and etc.)
Or, Adam W suggested that we could instead link to nightlies, with a footnote or something on the websites.
I think shipping some tested nightly is the only viable option, if the image looks like it was part of the release with teh same naming etc it will confuse users.
As we move into a more automated way doing one off things like this is going to get harder and harder to accomodate and do anything about. Relaistically at this point doing anything here is more up to websites than it is releng, websites will have to do something that explains things missed the boat. and point to some non official space in pub/alt where we put the images. we have to be very clear they are not part of the release, there will be no torrents for instance, the compase and release metadata does not know about them, they can not be official, If we are ever going to trust the metadata it has to be trustable.
Dennis
On Mon, Jun 20, 2016 at 09:32:23AM -0500, Dennis Gilmore wrote:
Jam failed due to package issues, its package set was not installable, dnf aborted the transactionso anaconda failed to install, it will be getting removed and will have to follow the process for a new spin if it is to ever come back, same as any spin that misses the boat, however given that SoaS and
Okay, that's fair for Jam.
As we move into a more automated way doing one off things like this is going to get harder and harder to accomodate and do anything about. Relaistically at this point doing anything here is more up to
This seems backwards to me. As we get more complicated and develop automation to assist with that complication, we need to get _more_ flexible, not less. I'd love for Spins to be able to ship when the SIG for each one determines that their thing is ready - if someone wants to fix up Jam, release it next month or whatever.
For that matter, it'd be nice to have the option for the main Editions - if there's something that only affects Workstation or Server, don't hold up the other (or the underlying release) for it.
From a PR point of view, the releases don't drive press like they used to - I think we'd actually be better served by more, smaller announcements. From a user adoption point of view, releases aren't the driver either - data shows a download spike for new releases, but overall the total Fedora users curve grows independently from that. People come for whatever release is current and don't generally wait for the splash of the next one.
So, we discussed this at the releng meeting this morning.
#agreed The least amount of 1 off work is to ship some tested nightlies in /pub/alt/unoffical/release/24/ just the isos, signed checksums and some manifest files that list all the srpms to keep legal happy
#info keeping the images seperate and named differently will ensure that the metadata and what is in PDC about the compose and release is correct
So, the last nightlies I see for those 2 spins are:
SoaS from the 14th (15th and 16th failed): http://koji.fedoraproject.org/koji/taskinfo?taskID=14484555
Design (also from the 14th):
http://koji.fedoraproject.org/koji/taskinfo?taskID=14484528
Next steps:
* would be nice if some folks could do some quick testing of these and make sure they boot and run and such.
* Then, Dennis can put them in alt somewhere with signed checksums and manifests.
* Websites would need to add some kind of blurb and point to them instead of the main release versions. Someone want to file a ticket?
* Marketing/announcement needs to note that they exist, but are nightly composes, not exactly the same as release. Can someone notify marketing?
kevin
On Mon, Jun 20, 2016 at 11:13:37AM -0600, Kevin Fenzi wrote:
- Marketing/announcement needs to note that they exist, but are nightly composes, not exactly the same as release. Can someone notify marketing?
I can. I currently removed them from the annoucement but can either a) put them back or b) write a separate post the day after.
On Monday, June 20, 2016 12:48:03 PM CDT Matthew Miller wrote:
On Mon, Jun 20, 2016 at 09:32:23AM -0500, Dennis Gilmore wrote:
Jam failed due to package issues, its package set was not installable, dnf aborted the transactionso anaconda failed to install, it will be getting removed and will have to follow the process for a new spin if it is to ever come back, same as any spin that misses the boat, however given that SoaS and
Okay, that's fair for Jam.
As we move into a more automated way doing one off things like this is going to get harder and harder to accomodate and do anything about. Relaistically at this point doing anything here is more up to
This seems backwards to me. As we get more complicated and develop automation to assist with that complication, we need to get _more_ flexible, not less. I'd love for Spins to be able to ship when the SIG for each one determines that their thing is ready - if someone wants to fix up Jam, release it next month or whatever.
We are not resourcesd or setup for something like that. We would need some number of new resources approaching on probably 4-5 maybe more people in order to do anything. We are doing what we can with the resources we have. In order to do more and do it faster something has to give. that something today is the hacks to do thinsg off to the side.
For that matter, it'd be nice to have the option for the main Editions
- if there's something that only affects Workstation or Server, don't
hold up the other (or the underlying release) for it.
From a PR point of view, the releases don't drive press like they used to - I think we'd actually be better served by more, smaller announcements. From a user adoption point of view, releases aren't the driver either - data shows a download spike for new releases, but overall the total Fedora users curve grows independently from that. People come for whatever release is current and don't generally wait for the splash of the next one.
What you are talking about is essentailly forking the distribution into multiple distributions, Which needs a lot more resources. there is additional legal complications over things like source matching that we ignore today due to having the Everything repo with the matching sources. we would have to make many more repositoryies, extra stress and load on infrastructure and mirrors, release engingeering, QA, and many other parts of the ecosystem. I think we need to talk because there is only so much we can do given what resourcing we have.
Dennis
rel-eng@lists.fedoraproject.org