On Jul 10, 2013 6:08 PM, "Brendan Conoboy" <b...@redhat.com> wrote: > > On 07/10/2013 02:25 PM, Adam Williamson wrote: >> >> No. The release blocking desktops are KDE and GNOME. This is stated in >> the preamble of all release criteria pages, for lack of anywhere better >> to state it. > > > If we were only proposing headless ARM servers for primary how would these criteria apply? The changes to the build system would be the same with our without these desktops in either case. Note I'm not asking Adam specifically; it's a question for the room. > I was thinking the same thing earlier. I think Adamw and jreznik would both say that we should modify the release criteria for that. I think mjg is more of the opinion that the fedora distribution means that certain things including the default desktop are available and that a different target, like headless servers, should be a spin. I believe that he's left open the option to rethink how spins and primary arch overlap so that arm with a headless server spin could be primary but not called fedora.
I think I agree with mjg that we should divorce pa status from the particular fedora spins that can be made from them. I don't think I agree as much that the packageset of a particular spin is what defines what deserves the fedora name: I wouldn't have a problem with an arm packageset that couldn't support the default desktop. There probably is a minimal packageset, though. the kernel, glibc, gcc, and rpm would all be on my list. Given that fesco has a policy about the package depsolver having to be the same on all spins, probably the current depdolving package manager as well. Default init system and bash are also likely although someone might be able to make a case for alternatives to the defaults being okay... with emphasis on "might". Getting back to the release criteria; if we are moving towards a model where a headless server spin was fine as the only product for an arch I think we'd need to start looking at release criteria being applied more purely to spins. This might require big changes to how we think about validating a release. -Toshio
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
