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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jun 20, 2016 12:48, "Matthew Miller" <mattdm@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx>
> Fedora Project Leader
> --
> websites mailing list
> websites@xxxxxxxxxxxxxxxxxxxxxxx
> https://lists.fedoraproject.org/admin/lists/websites@xxxxxxxxxxxxxxxxxxxxxxx

--
websites mailing list
websites@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/websites@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Users]     [Linux ARM]     [ARM Kernel]     [Older Fedora Users]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux