Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-17 Thread Kevin Kofler
Jan Kurik wrote:
> Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
> Spins, Labs and the base container image rather than just the main
> Fedora Editions.

While I agree that this needs to be handled the same way for Editions and 
Spins (because I think this distinction is arbitrary to begin with), I think 
we should actually drop those fields in the Editions instead of trying to 
fill them in everywhere. A Fedora installation can be customized in many 
ways. In the end, what you get is and should be Fedora, no matter what media 
you initially installed from. Any VARIANT distinction is just meaningless.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RZPOTF45VQDB5URNESPEMQ5ABY6WXKUK/


Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-15 Thread Matthew Miller
On Tue, May 15, 2018 at 01:15:53PM -0400, Josh Boyer wrote:
> That's different from counting "we have 87 Fedora Server installs!" based
> on variant though.  I'm simply suggesting that in our statistics gathering,
> we take any measurement there with a grain of salt.  With a mutable package
> set post-installation, there are any number of combinations that can
> falsely provide what the machine is.  For example, it is trivial to install
> Server and then add KDE to it.  Now you have something identified as Server
> that is really more of a Workstation (and a KDE one at that), simply
> because the user chose to use the Server iso to start with.  Variant is an
> artifact creation-time suggestion, not a description of a system or it's
> actual usage post-install.

Oh, absolutely. I think, though, even if it's salted a bit, it's still
a pretty good indicator of intent.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-15 Thread Matthew Miller
On Tue, May 15, 2018 at 12:49:44PM -0400, Stephen Gallagher wrote:
> The fedora-release-$VARIANT subpackage also provides a set of Requires:
> that indicates a minimum set of packages that must be on the system for it
> to still call itself "Server Edition". (For example, if you tried to remove
> the 'cockpit-ws' package, it would result in fedora-release-server being
> removed and /etc/os-release going back to the non-edition content)
> 
> So we *can* rely on this indicating a minimum level of functionality on the
> system.

We could do something similar for the spin subpackages as well -- do
you think that should be part of this initial plan?



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-15 Thread Josh Boyer
On Tue, May 15, 2018 at 12:50 PM Stephen Gallagher 
wrote:



> On Tue, May 15, 2018 at 12:29 PM Josh Boyer 
wrote:

>> On Tue, May 15, 2018 at 12:21 PM Jan Kurik  wrote:

>> > = Proposed System Wide Change: Let's Label Our Variants! =
>> > https://fedoraproject.org/wiki/Changes/Label_Our_Variants


>> > Owner(s):
>> >* Matthew Miller 
>> >* Mohan Boddu 


>> > Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
>> > Spins, Labs and the base container image rather than just the main
>> > Fedora Editions.



>> > == Detailed description ==
>> > Right now, we use the VARIANT field (and machine-readable VARIANT_ID)
>> > in /etc/os-release) only for the main Fedora Editions (and Fedora
>> > Cloud Base, because of its history as an edition previously). This
>> > means we can't tell the difference between a KDE desktop spin, a
>> > container image, or just a generic netinstall constructed into a
>> > custom system unlike any of our various flavors. Let's start using it
>> > widely.

>> Variant definitions seem like they're really only valid for things like
>> install media and container images.  They express intent well enough for
>> what the spin or Edition is for, but after installation the package set
>> deviates widely.  We can't assume something that has the Server variant
in
>> /etc/os-release is actually representative of anything Fedora ships as
>> Server without doing a package comparison along the way.  If we're using
>> variant to count anything, I think we need to scope it only to "initial
>> installations".


> The fedora-release-$VARIANT subpackage also provides a set of Requires:
that indicates a minimum set of packages that must be on the system for it
to still call itself "Server Edition". (For example, if you tried to remove
the 'cockpit-ws' package, it would result in fedora-release-server being
removed and /etc/os-release going back to the non-edition content)

> So we *can* rely on this indicating a minimum level of functionality on
the system.

I have nothing against using variants or applying them to describe minimum
functionality.  Minimum function is good and we should retain that.

That's different from counting "we have 87 Fedora Server installs!" based
on variant though.  I'm simply suggesting that in our statistics gathering,
we take any measurement there with a grain of salt.  With a mutable package
set post-installation, there are any number of combinations that can
falsely provide what the machine is.  For example, it is trivial to install
Server and then add KDE to it.  Now you have something identified as Server
that is really more of a Workstation (and a KDE one at that), simply
because the user chose to use the Server iso to start with.  Variant is an
artifact creation-time suggestion, not a description of a system or it's
actual usage post-install.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-15 Thread Stephen Gallagher
On Tue, May 15, 2018 at 12:29 PM Josh Boyer 
wrote:

> On Tue, May 15, 2018 at 12:21 PM Jan Kurik  wrote:
>
> > = Proposed System Wide Change: Let's Label Our Variants! =
> > https://fedoraproject.org/wiki/Changes/Label_Our_Variants
>
>
> > Owner(s):
> >* Matthew Miller 
> >* Mohan Boddu 
>
>
> > Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
> > Spins, Labs and the base container image rather than just the main
> > Fedora Editions.
>
>
>
> > == Detailed description ==
> > Right now, we use the VARIANT field (and machine-readable VARIANT_ID)
> > in /etc/os-release) only for the main Fedora Editions (and Fedora
> > Cloud Base, because of its history as an edition previously). This
> > means we can't tell the difference between a KDE desktop spin, a
> > container image, or just a generic netinstall constructed into a
> > custom system unlike any of our various flavors. Let's start using it
> > widely.
>
> Variant definitions seem like they're really only valid for things like
> install media and container images.  They express intent well enough for
> what the spin or Edition is for, but after installation the package set
> deviates widely.  We can't assume something that has the Server variant in
> /etc/os-release is actually representative of anything Fedora ships as
> Server without doing a package comparison along the way.  If we're using
> variant to count anything, I think we need to scope it only to "initial
> installations".
>
>
The fedora-release-$VARIANT subpackage also provides a set of Requires:
that indicates a minimum set of packages that must be on the system for it
to still call itself "Server Edition". (For example, if you tried to remove
the 'cockpit-ws' package, it would result in fedora-release-server being
removed and /etc/os-release going back to the non-edition content)

So we *can* rely on this indicating a minimum level of functionality on the
system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: F29 System Wide Change: Let's Label Our Variants!

2018-05-15 Thread Josh Boyer
On Tue, May 15, 2018 at 12:21 PM Jan Kurik  wrote:

> = Proposed System Wide Change: Let's Label Our Variants! =
> https://fedoraproject.org/wiki/Changes/Label_Our_Variants


> Owner(s):
>* Matthew Miller 
>* Mohan Boddu 


> Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
> Spins, Labs and the base container image rather than just the main
> Fedora Editions.



> == Detailed description ==
> Right now, we use the VARIANT field (and machine-readable VARIANT_ID)
> in /etc/os-release) only for the main Fedora Editions (and Fedora
> Cloud Base, because of its history as an edition previously). This
> means we can't tell the difference between a KDE desktop spin, a
> container image, or just a generic netinstall constructed into a
> custom system unlike any of our various flavors. Let's start using it
> widely.

Variant definitions seem like they're really only valid for things like
install media and container images.  They express intent well enough for
what the spin or Edition is for, but after installation the package set
deviates widely.  We can't assume something that has the Server variant in
/etc/os-release is actually representative of anything Fedora ships as
Server without doing a package comparison along the way.  If we're using
variant to count anything, I think we need to scope it only to "initial
installations".

josh

> == Scope ==
> * Proposal owners:
> Update the fedora-release package with subpackages for the various
> non-edition outputs. The "convert-to-edition" script may also be
> extended to handle non-editions, but this is not a required part of
> this change proposal.

> * Other developers:
> Maintainers of spins and labs will need to add the appropriate
> fedora-release-… subpackage to the appropriate kickstart file or comps
> group.

> * Release engineering:
> Release Engineering owns the fedora-release package.

> * List of deliverables:
> Workstation and Server deliverables already contain this, and so are
> not affected. The KDE Plasma Desktop Spin will be changed. There is no
> overall change to the list of deliverables itself.

> * Policies and guidelines:
> There was a previous decision to only do this for Editions. This
> change would update that. We would also update the Spins documentation
> to add this as a new step in that pricess.

> * Trademark approval:
> not needed for this Change


> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org