> ============================================================
> New/Changed Alpha Release Criteria
> ============================================================
> The installer must be able to install each of the release blocking
> desktops, as well as the minimal package set, with each supported
> installation method
>
> The installer must be able to complete an installation using
> automatic
> partitioning to any sufficiently large target disk, whether
> unformatted, empty, or containing any kind of existing data
>
> The installer must allow the user to select which of the disks
> connected to the system will be affected by the installation process.
> Disks not selected as installation targets must not be affected by
> the
> installation process in any way
>
> ============================================================
> New/Changed Beta Release Criteria
> ============================================================
> The installer must be able to complete an installation using
> automatic
> partitioning to a validly-formatted disk with sufficient empty space,
> using the empty space and installing a bootloader but leaving the
> pre-existing partitions and data untouched
All seem reasonable.
>
> === This is still under review - waiting for input ===
> The installer's custom partitioning mode must be capable of the
> following:
> * Creating, destroying and assigning mount points to partitions of
> any specified size using most commonly-used filesystem types
> * Creating encrypted partitions
> * Rejecting obviously invalid operations without crashing
>
If you think about it, it's funny that we consider autopart to be "easier", and we require it earlier to be working than custom part, that we consider "harder" (now we even think about moving most custom part criteria to Final). But Alpha/Beta are for hardcore users (more manual part) and Final is for general users (more autopart). Isn't that a bit... weird? I still wonder whether we should dictate which parts of UI work and which parts do not, as long as no user data are unintentionally destroyed.
Anyhow, this is just a food for thought, I'm OK with those criteria.
> For each one of the release-blocking package sets ('minimal', and the
> package sets for each one of the release-blocking desktops), it must
> be
> possible to successfully complete an upgrade from a fully updated
> installation of the previous stable Fedora release with that package
> set installed, using any officially recommended upgrade mechanisms.
> The
> upgraded system must meet all release criteria.
>
> ============================================================
> New/Changed Final Release Criteria
> ============================================================
>
> For each one of the release-blocking package sets ('minimal', and the
> package sets for each one of the release-blocking desktops), it must
> be
> possible to successfully complete an upgrade from a fully updated
> installation of the previous stable Fedora release with that package
> set installed, using all officially recommended upgrade mechanisms.
> The
> upgraded system must meet all release criteria.
Hopefully with FedUp we will have just a single one officially recommended upgrade mechanism and we will be able to leave out this criterion. But since we are quite in the dark now, it makes sense to split it as we did.
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
