Re: contingency plan for the failed-to-build spins/labs?

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

contingency plan for the failed-to-build spins/labs?

[Stephen John Smoogen]

On Jun 20, 2016 12:48, "Matthew Miller" <mattdm(a)fedoraproject.org&gt; 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.
>  
Then that needed to be specified and coded for in the beginning versus at
the end. The problem is that the automation was written by groups doing
other things and with the idea of lowering the tire fires of 2015 while
also trying to get all of the special things we were doing. That means a
lot of flexibility was not coded in because that was more code paths than
anyone had time to look at. And that will continue to be the case because
no one is stopping the train anywhere

>  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.
>
>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  
https://lists.fedoraproject.org/admin/lists/[e-mail]

contingency plan for the failed-to-build spins/labs?

[Kevin Fenzi]

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

contingency plan for the failed-to-build spins/labs?

[Matthew Miller]

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.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

contingency plan for the failed-to-build spins/labs?

[Robert Mayr]

2016-06-20 19:13 GMT+02:00 Kevin Fenzi <kevin(a)scrye.com&gt;:

>  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?
>
>  
Filed:
https://fedorahosted.org/fedora-websites/ticket/397

-- 
Robert Mayr
(robyduck)

contingency plan for the failed-to-build spins/labs?

[Dennis Gilmore]

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