Peter Robinson wrote:
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.
IMHO, we should have at most 1 week of strict freeze. If we decide that we
have to slip anyway, then we should pull in ALL updates pending stable and
restart the release process (freeze, spin RCs, test) from there.
(That would also make it less painful to slip multiple times and thus
decrease the pressure to rush out quick hacks to work around blockers
instead of clean fixes.)
I also think that the decision:
* when an image is a Go,
* what issues to consider as blockers and
* what new builds to take as freeze overrides
ought to be made by the WG/SIG responsible for the individual deliverable.
(And this is NOT a personal power grab attempt. I am no longer a voting
member of the KDE SIG, for reasons detailed on the kde mailing list.) The
current process where the SIG/WG has to argue for every single freeze
override they want to take in, and have rel-eng/QA reject some of them, is
just broken (and there I can speak from experience, with my 8 years of KDE
SIG involvement).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
