> 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@fedoraproject.org>
Fedora Project Leader
--
websites mailing list
websites@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/websites@lists.fedoraproject.org
No comments:
Post a Comment