12:03 p.m.
Greetings.
I'd like to propose some changes to the spins process for F20.
I'm sending this just to the spins and test lists first, to try and hash
out things, then we can move on to running it the devel list once we
have more concrete plans.
http://fedoraproject.org/wiki/Releases/20/Spins shall be the cannonical
list of approved spins by the sig.
A Milestone is one of Alpha, Beta, Final.
A basic spin test will be created (Or perhaps we can re-use the Basic
desktop test, or whatever QA folks would prefer). This basic spin test
will test:
At Alpha:
* The image composes.
* The image boots with any method
* The liveuser user can login
* The user can apply updates
At Beta:
* All Alpha tests, and
* The image meets it's size goal
* The image boots with all supported live media boot methods.
At Final:
* All Beta test and
* No selinux denials on boot/login
At the Alpha milestone, all approved spins will be created by rel-eng.
Each approved spin MUST have at least 2 people fill in the Basic spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
can try again at the next milestone, but the image is NOT shipped for
that milestone. if an image doesn't get 2 people filling in Basic spin
tests, the image is dropped for that cycle and IS NOT SHIPPED FOR THAT
RELEASE! Such images can be reapproved by the spins sig for the next
cycle.
At the Beta milestone, only those images that got testing in the Alpha
milestone will be produced.
At the Final milestone, only those images that were tested at the Beta
release will be produced.
The http://fedoraproject.org/wiki/Releases/20/Spins page will be
enhanced with a 'Alpha/Beta/Final' field, where we can note what spins
are in what state.
Questions/Feedback needed on:
- Is 2 people too many? Should it just be 1? or More?
- Are there other Basic tests we should require?
- Is there a better way to track things than that wiki page?
- Is there a good way to make sure all spins maintainers are aware of
these changes and are not surprised by them?
Anything else?
kevin
12:56 p.m.
On Fri, Jul 05, 2013 at 11:03:02 -0600,
Kevin Fenzi <kevin(a)scrye.com> wrote:
At Alpha:
* The image boots with any method
At Beta:
* The image boots with all supported live media boot methods.
How are those criteria different than alpha and beta? What are the
exact methods being proposed for testing? I know of optical media,
dd to usb drive, livecd-iso-to-disk to usb drive, but I think there is
another uitlity as well. Optical media testing costs people money to test.
Are these tests to vms or real hardware?
What arches need to be tested?
Each approved spin MUST have at least 2 people fill in the Basic spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
So they have to be the same inage? (i.e. Can two different people successfully
test different images to qualify or they they both need to test the
same image?)
The http://fedoraproject.org/wiki/Releases/20/Spins page will be
enhanced with a 'Alpha/Beta/Final' field, where we can note what spins
are in what state.
Who is going to do this? (Both from a do the work and is authorized to
say that sufficient testing was done and that the tests were successful,
perspectives.)
- Is 2 people too many? Should it just be 1? or More?
Realistically it will be hard to get 2 people to test some of the spins
in the current environment. That doesn't mean we can't require it, but there
could be some frustration down the road for people who work on spins and
can't convince someone else to help them with testing.
- Is there a good way to make sure all spins maintainers are aware of
these changes and are not surprised by them?
In theory they are all supposed to be reading the spins list, but each
spin is supposed to have at least one documented maintainer with an email
address to reach them at and it might be nice to send them one off email
given the significance of this change.
I am guessing the above applies to getting ISOs produced for the releases
and will not (immediately) affect the status of their ks in the kickstart
packages.
Anything else?
Are we going to try to implement freezes for spins for F20 or is that
something we want to put off until later?
3:18 p.m.
On 2013-07-05 10:03, Kevin Fenzi wrote:
Greetings.
I'd like to propose some changes to the spins process for F20.
I'm sending this just to the spins and test lists first, to try and
hash
out things, then we can move on to running it the devel list once we
have more concrete plans.
http://fedoraproject.org/wiki/Releases/20/Spins shall be the cannonical
list of approved spins by the sig.
A Milestone is one of Alpha, Beta, Final.
A basic spin test will be created (Or perhaps we can re-use the Basic
desktop test, or whatever QA folks would prefer). This basic spin test
will test:
At Alpha:
* The image composes.
* The image boots with any method
* The liveuser user can login
* The user can apply updates
At Beta:
* All Alpha tests, and
* The image meets it's size goal
* The image boots with all supported live media boot methods.
At Final:
* All Beta test and
* No selinux denials on boot/login
We already have test cases for all of these. No need for new ones.
At the Alpha milestone, all approved spins will be created by
rel-eng.
Each approved spin MUST have at least 2 people fill in the Basic spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
can try again at the next milestone, but the image is NOT shipped for
that milestone. if an image doesn't get 2 people filling in Basic spin
tests, the image is dropped for that cycle and IS NOT SHIPPED FOR THAT
RELEASE! Such images can be reapproved by the spins sig for the next
cycle.
I think this is going way too far.
Specifically: I think *one* test for each spin is more realistic. I
don't think we need to block spins for being oversize, or for SELinux
denials. They're spins. I don't think we can overreach on quality
requirements.
- Is 2 people too many? Should it just be 1? or More?
See above.
- Are there other Basic tests we should require?
No. That's actually all we require from the *release blocking* live
images at Alpha.
- Is there a better way to track things than that wiki page?
Not at present, no. WikiTCMS isn't so bad once you get used to it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:44 p.m.
On 07/05/2013 05:03 PM, Kevin Fenzi wrote:
Greetings.
I'd like to propose some changes to the spins process for F20.
I'm sending this just to the spins and test lists first, to try and hash
out things, then we can move on to running it the devel list once we
have more concrete plans.
You should rather be reaching out to the sub community surrounding those
spins.
http://fedoraproject.org/wiki/Releases/20/Spins shall be the cannonical
list of approved spins by the sig.
A Milestone is one of Alpha, Beta, Final.
A basic spin test will be created (Or perhaps we can re-use the Basic
desktop test, or whatever QA folks would prefer). This basic spin test
will test:
At Alpha:
* The image composes.
* The image boots with any method
* The liveuser user can login
* The user can apply updates
???
You do realize at alpha we have the most fluctuation of the installer,
the base OS stack including X right so you cannot require spins to pass
any tests that might be affected by it right?
At Beta:
* All Alpha tests, and
??
* The image meets it's size goal. <-- This makes resonable
alpha goal we really should not be dealing with size issue after alpha not limited to
spins...
* The image boots with all supported live media boot methods.
There is no such thing as support so please stop labelling things as
such seriously.
Any of the available boot method should suffice here.
At Final:
* All Beta test and
Which beta test would that be?
* No selinux denials on boot/login
Makes sense
At the Alpha milestone, all approved spins will be created by
rel-eng.
Each approved spin MUST have at least 2 people fill in the Basic spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
can try again at the next milestone, but the image is NOT shipped for
that milestone. if an image doesn't get 2 people filling in Basic spin
tests, the image is dropped for that cycle and IS NOT SHIPPED FOR THAT
RELEASE! Such images can be reapproved by the spins sig for the next
cycle.
???
It should be sufficient for a single individual to go through all
related tests for a spin.
People creating spins should be allowed to create sub community
surrounding their spins and will not be able to do that with those
insane requirements.
At the Beta milestone, only those images that got testing in the
Alpha
milestone will be produced.
At the Final milestone, only those images that were tested at the Beta
release will be produced.
The http://fedoraproject.org/wiki/Releases/20/Spins page will be
enhanced with a 'Alpha/Beta/Final' field, where we can note what spins
are in what state.
Questions/Feedback needed on:
- Is 2 people too many? Should it just be 1? or More?
- Are there other Basic tests we should require?
- Is there a better way to track things than that wiki page?
- Is there a good way to make sure all spins maintainers are aware of
these changes and are not surprised by them?
Anything else?
https://admin.fedoraproject.org/mailman/listinfo/spins
Bear in mind that anything you decide here should be applicable to the
Gnome live spin as well.
JBG
11:57 a.m.
On Fri, 05 Jul 2013 13:18:49 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
...snip...
We already have test cases for all of these. No need for new ones.
ok. How can we denote the ones we desire tested for these?
Basic Desktop?
> At the Alpha milestone, all approved spins will be created by
> rel-eng.
>
> Each approved spin MUST have at least 2 people fill in the Basic
> spin test matrix for at least 1 TC or RC. If the image fails,
> maintainers can try again at the next milestone, but the image is
> NOT shipped for that milestone. if an image doesn't get 2 people
> filling in Basic spin tests, the image is dropped for that cycle
> and IS NOT SHIPPED FOR THAT RELEASE! Such images can be reapproved
> by the spins sig for the next cycle.
I think this is going way too far.
ok.
Specifically: I think *one* test for each spin is more realistic. I
don't think we need to block spins for being oversize, or for SELinux
denials. They're spins. I don't think we can overreach on quality
requirements.
> - Is 2 people too many? Should it just be 1? or More?
See above.
Fair enough. If thats the consensus, thats ok with me.
> - Are there other Basic tests we should require?
No. That's actually all we require from the *release blocking* live
images at Alpha.
> - Is there a better way to track things than that wiki page?
Not at present, no. WikiTCMS isn't so bad once you get used to it.
Right.
kevin
12:01 p.m.
On Fri, 05 Jul 2013 20:44:32 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
On 07/05/2013 05:03 PM, Kevin Fenzi wrote:
> Greetings.
>
> I'd like to propose some changes to the spins process for F20.
> I'm sending this just to the spins and test lists first, to try and
> hash out things, then we can move on to running it the devel list
> once we have more concrete plans.
You should rather be reaching out to the sub community surrounding
those spins.
The maintainers of the spins should be subscribed to the spins list
where I sent this. If they have 'sub communities' they should feel free
to pass along to them or ask them to chime in.
???
You do realize at alpha we have the most fluctuation of the
installer, the base OS stack including X right so you cannot require
spins to pass any tests that might be affected by it right?
I would expect them to pass any tests that release blocking spins
pass... why not?
>
> At Beta:
>
> * All Alpha tests, and
??
> * The image meets it's size goal. <-- This makes resonable alpha
> goal we really should not be dealing with size issue after alpha
> not limited to spins...
Feel free to propose moving that.
> * The image boots with all supported live media boot methods.
There is no such thing as support so please stop labelling things as
such seriously.
I was just copying from the wiki:
https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Initializa...
"All release-blocking images must boot in their supported
configurations."
Any of the available boot method should suffice here.
>
>
> At Final:
>
> * All Beta test and
Which beta test would that be?
The ones above in "At Beta"
> * No selinux denials on boot/login
Makes sense
> At the Alpha milestone, all approved spins will be created by
> rel-eng.
>
> Each approved spin MUST have at least 2 people fill in the Basic
> spin test matrix for at least 1 TC or RC. If the image fails,
> maintainers can try again at the next milestone, but the image is
> NOT shipped for that milestone. if an image doesn't get 2 people
> filling in Basic spin tests, the image is dropped for that cycle
> and IS NOT SHIPPED FOR THAT RELEASE! Such images can be reapproved
> by the spins sig for the next cycle.
???
It should be sufficient for a single individual to go through all
related tests for a spin.
ok. So far sounding like folks want just one ack.
Anyone feel strongly it should be more?
People creating spins should be allowed to create sub community
surrounding their spins and will not be able to do that with those
insane requirements.
If they have a "sub community" shouldn't that mean there's at least
one other person in it that could test?
Bear in mind that anything you decide here should be applicable to
the Gnome live spin as well.
The KDE and Desktop (Gnome) spins are not included here, as they are
release blocking, so they already have their own critera.
kevin
12:50 p.m.
On 07/06/2013 05:01 PM, Kevin Fenzi wrote:
> People creating spins should be allowed to create sub community
> surrounding their spins and will not be able to do that with those
> insane requirements.
If they have a "sub community" shouldn't that mean there's at least
one other person in it that could test?
Not necessary when they initially create the spin we ( the community
service sub-communities releng/infra/qa/design/marketing ) should be
supportive to allow it to establish a sub-community surrounding that
spin for up to 3 release cycle. Even if not in the end it would just
mean more work for that individual it's just easier for him if there are
more.
And if that individual fails to meet the criteria and what other
requirements that will decide here the spin wont be shipped.
However I argue the way forward for spins is to allow each of the spins
to control their own release cycle and the spins owner themselves having
to learning and do the necessary work from the releng side ( handle the
entire process and stand or fall with it instead of tapping into
existing releng resources ) encase they want to deviate from the
"default" release cycle by for example adapting their spin release cycle
to their upstream but that topic I was just going to discuss well first
with Adam and Tim and the rest of the QA and Releng community at flock
along with the idea of applying the steady release cycle to "base/coreOS
and X" only.
> Bear in mind that anything you decide here should be applicable to
> the Gnome live spin as well.
The KDE and Desktop (Gnome) spins are not included here, as they are
release blocking, so they already have their own critera.
Our release blocking criteria is not limited to Gnome and KDE but all
spins. ( same thing should apply to primary/secondary arch as well from
my pov )
If our criteria cant cover that then that's a design flaw as I see it in
our criteria process because it should be sufficient for spins having to
meet what is defined there and apply to the bits the relevant spin ships
and that's something we ( QA ) need to fix.
Our QA first and foremost function as I see it is to cover the
installer,base/core OS and X any testing outside that should be handled
by the relevant sub community.
Gnome desktop users for Gnome,KDE for KDE XFCE/LXDE and so on.
Basically what ever spins add on top of base/coreOS and X should work at
their release time and meet the existing criteria as I see since I dont
see the need for us to complicate the process more than that on top of
having to learn and handle the entire releng release process and testing
to the bits they ship with the exception of "base/core OS and X".
I do believe that will solve the underlying problem which spurred this
discussion and change in the spins process in the first place.
JBG
5:43 p.m.
Kevin Fenzi (kevin(a)scrye.com) said:
Each approved spin MUST have at least 2 people fill in the Basic
spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
can try again at the next milestone, but the image is NOT shipped for
that milestone. if an image doesn't get 2 people filling in Basic spin
tests, the image is dropped for that cycle and IS NOT SHIPPED FOR THAT
RELEASE! Such images can be reapproved by the spins sig for the next
cycle.
At the Beta milestone, only those images that got testing in the Alpha
milestone will be produced.
I'd allow for building and testing things that failed in alpha, if there are
changes to fix those failures. Similarly for beta -> final.
Bill
7:11 p.m.
On 2013-07-06 10:50, Jóhann B. Guðmundsson wrote:
>> Bear in mind that anything you decide here should be
applicable to
>> the Gnome live spin as well.
> The KDE and Desktop (Gnome) spins are not included here, as they are
> release blocking, so they already have their own critera.
Our release blocking criteria is not limited to Gnome and KDE but all
spins. ( same thing should apply to primary/secondary arch as well
from my pov )
If our criteria cant cover that then that's a design flaw as I see it
in our criteria process because it should be sufficient for spins
having to meet what is defined there and apply to the bits the
relevant spin ships and that's something we ( QA ) need to fix.
Well, it depends what you mean by 'apply to'.
They don't 'apply to' spins beyond GNOME and KDE in the sense that we
block the release if the criteria aren't met for any other spin. We
don't.
But you can say they 'apply to' other spins in the sense that, if you're
trying another spin, you can use the release criteria and validation
test case set as a guide, sure.
Our QA first and foremost function as I see it is to cover the
installer,base/core OS and X any testing outside that should be
handled by the relevant sub community.
Gnome desktop users for Gnome,KDE for KDE XFCE/LXDE and so on.
In practice, I don't think we can get away with passing off testing of
the 'release blocking' desktops to SIGs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:25 p.m.
On 07/10/2013 12:11 AM, Adam Williamson wrote:
In practice, I don't think we can get away with passing off testing of
the 'release blocking' desktops to SIGs.
In reality I have a hard time believing that the board reaches the
conclusion that continuing to have an default and those two conditioning
to be the release blocking desktop is the way forward.
The KDE community already is testing their own spin against the criteria
as do the others except Gnome and I think 19 release cycle should be
sufficient for the Gnome sub-community to step in and start doing their
own testing while we in QA return back to our roots and focus on
covering the installer and the base/core OS and arguably X and cover to
the best of the ability the platform that all other sub-community are
building upon.
We already are going to be facing a lot of base/core os moving parts in
this release cycle within the insanely short release cycle that has been
decided for us and if we are not going to be "slipping" we need to start
choosing which part's we will be focusing on.
JBG
10:36 a.m.
So, there was some feedback (mostly from QA), but pretty much nothing
from spin owners.
I guess next step is for me to write up the proposal again with
feedback pulled in and post to devel?
Any other feedback before I do so?
Or anyone else have desire to write up things? :)
kevin
1:22 a.m.
On 07/26/2013 05:36 PM, Kevin Fenzi wrote:
So, there was some feedback (mostly from QA), but pretty much
nothing
from spin owners.
I guess next step is for me to write up the proposal again with
feedback pulled in and post to devel?
Any other feedback before I do so?
Or anyone else have desire to write up things? :)
kevin
The Fedora Jam team (music-creation SIG) can manage at least 2 test
matrices for F20. I think we have some good support there.
But our case is somewhat easier - we are simply adding packages to the
KDE spin. It is not as if we are providing an alternate desktop or
anything. Any errors we catch will probably be picked up by QA as well.
Brendan
3:43 a.m.
On Jul 5, 2013 10:03 AM, "Kevin Fenzi" <kevin(a)scrye.com> wrote:
Greetings.
I'd like to propose some changes to the spins process for F20.
I'm sending this just to the spins and test lists first, to try and hash
out things, then we can move on to running it the devel list once we
have more concrete plans.
http://fedoraproject.org/wiki/Releases/20/Spins shall be the cannonical
list of approved spins by the sig.
A Milestone is one of Alpha, Beta, Final.
A basic spin test will be created (Or perhaps we can re-use the Basic
desktop test, or whatever QA folks would prefer). This basic spin test
will test:
At Alpha:
* The image composes.
* The image boots with any method
* The liveuser user can login
* The user can apply updates
At Beta:
* All Alpha tests, and
* The image meets it's size goal
* The image boots with all supported live media boot methods.
At Final:
* All Beta test and
* No selinux denials on boot/login
At the Alpha milestone, all approved spins will be created by rel-eng.
Each approved spin MUST have at least 2 people fill in the Basic spin
test matrix for at least 1 TC or RC. If the image fails, maintainers
can try again at the next milestone, but the image is NOT shipped for
that milestone. if an image doesn't get 2 people filling in Basic spin
tests, the image is dropped for that cycle and IS NOT SHIPPED FOR THAT
RELEASE! Such images can be reapproved by the spins sig for the next
cycle.
At the Beta milestone, only those images that got testing in the Alpha
milestone will be produced.
At the Final milestone, only those images that were tested at the Beta
release will be produced.
The http://fedoraproject.org/wiki/Releases/20/Spins page will be
enhanced with a 'Alpha/Beta/Final' field, where we can note what spins
are in what state.
Questions/Feedback needed on:
- Is 2 people too many? Should it just be 1? or More?
- Are there other Basic tests we should require?
- Is there a better way to track things than that wiki page?
- Is there a good way to make sure all spins maintainers are aware of
these changes and are not surprised by them?
Anything else?
kevin
Hi Kevin,
I think we are going at it a little backwards and creating double work for
ourselves.
For example the MATE-Compiz spin is the same thing that gets pressed on the
DVD with the addition of some compiz packages.
As long as the proper QA is done there, and some minor sanity checks done
on the spins, why all the extra work?
Just a thought.
Dan
11:24 a.m.
On Sat, 27 Jul 2013 08:22:25 +0200
Brendan Jones <brendan.jones.it(a)gmail.com> wrote:
On 07/26/2013 05:36 PM, Kevin Fenzi wrote:
> So, there was some feedback (mostly from QA), but pretty much
> nothing from spin owners.
>
> I guess next step is for me to write up the proposal again with
> feedback pulled in and post to devel?
>
> Any other feedback before I do so?
> Or anyone else have desire to write up things? :)
>
> kevin
>
The Fedora Jam team (music-creation SIG) can manage at least 2 test
matrices for F20. I think we have some good support there.
Cool.
But our case is somewhat easier - we are simply adding packages to
the KDE spin. It is not as if we are providing an alternate desktop
or anything. Any errors we catch will probably be picked up by QA as
well.
Sure, but there could be errors in the packages you add, their
interaction with the rest of the desktop or compose issues, etc.
kevin
11:26 a.m.
On Sat, 27 Jul 2013 01:43:29 -0700
Dan Mashal <dan.mashal(a)gmail.com> wrote:
Hi Kevin,
I think we are going at it a little backwards and creating double
work for ourselves.
For example the MATE-Compiz spin is the same thing that gets pressed
on the DVD with the addition of some compiz packages.
Sure, the packages are the same...
As long as the proper QA is done there, and some minor sanity checks
done on the spins, why all the extra work?
Well, it's composed and run in a completely different path.
A bug in a package might not show up on a dvd install, where it might
show up running from live media. Additionally compose tools are
different between the two, so something that might prevent the live
media from composing could work fine for the dvd and vice versa.
I agree there's overlap in the packages, and we should try not to
cover ground we already covered.
Just a thought.
Dan
kevin
3:34 p.m.
On 07/05/2013 07:03 PM, Kevin Fenzi wrote:
<snip>
I would like to see new spins managed through trac.
I am concerned that forgotten spins create unnecessary work for releng,
and I think your proposal mitigates this somewhat. There seem to be a
lot of flash in the pan projects concerning spins (GSOC anyone?) that
the rest of us end up maintaining.
Your proposal seems sound to me. I think even one sign-off per spin is
adequate, although we will aim for two.
6:20 p.m.
On 27 July 2013 17:24, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 27 Jul 2013 08:22:25 +0200
Brendan Jones <brendan.jones.it(a)gmail.com> wrote:
> On 07/26/2013 05:36 PM, Kevin Fenzi wrote:
> > So, there was some feedback (mostly from QA), but pretty much
> > nothing from spin owners.
> >
> > I guess next step is for me to write up the proposal again with
> > feedback pulled in and post to devel?
> >
> > Any other feedback before I do so?
> > Or anyone else have desire to write up things? :)
> >
> > kevin
> >
> The Fedora Jam team (music-creation SIG) can manage at least 2 test
> matrices for F20. I think we have some good support there.
Cool.
> But our case is somewhat easier - we are simply adding packages to
> the KDE spin. It is not as if we are providing an alternate desktop
> or anything. Any errors we catch will probably be picked up by QA as
> well.
Sure, but there could be errors in the packages you add, their
interaction with the rest of the desktop or compose issues, etc.
True, though what we mainly find if anything (unless a distro-wide or
KDE spin bug) seems to be compose issues. Actually it's a pity the
formulas idea hasn't really caught anyone's imagination yet.
--
imalone
http://ibmalone.blogspot.co.uk
3:41 a.m.
On 07/29/2013 01:20 AM, Ian Malone wrote:
On 27 July 2013 17:24, Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Sat, 27 Jul 2013 08:22:25 +0200
> Brendan Jones <brendan.jones.it(a)gmail.com> wrote:
>
>> On 07/26/2013 05:36 PM, Kevin Fenzi wrote:
>>> So, there was some feedback (mostly from QA), but pretty much
>>> nothing from spin owners.
>>>
>>> I guess next step is for me to write up the proposal again with
>>> feedback pulled in and post to devel?
>>>
>>> Any other feedback before I do so?
>>> Or anyone else have desire to write up things? :)
>>>
>>> kevin
>>>
>> The Fedora Jam team (music-creation SIG) can manage at least 2 test
>> matrices for F20. I think we have some good support there.
>
> Cool.
>
>> But our case is somewhat easier - we are simply adding packages to
>> the KDE spin. It is not as if we are providing an alternate desktop
>> or anything. Any errors we catch will probably be picked up by QA as
>> well.
>
> Sure, but there could be errors in the packages you add, their
> interaction with the rest of the desktop or compose issues, etc.
True, though what we mainly find if anything (unless a distro-wide or
KDE spin bug) seems to be compose issues. Actually it's a pity the
formulas idea hasn't really caught anyone's imagination yet.
I'm really not sure how this is supposed to work. I am hesitant to do
anything outside of RPM. Matthew M's flock proposal also makes me
somewhat uneasy. Maybe I need to keep up with the times...
If rings or formulas are just sets of packages, we have that already. If
they are alternate config files based on use cases in /etc/sysconfig I
can see the merit in that, but I would rather install an application
which changes those things and let me know when its doing it.
3917
days inactive
3941
days old
17 comments
8 participants
participants (8)
-
Adam Williamson -
Bill Nottingham -
Brendan Jones -
Bruno Wolff III -
Dan Mashal -
Ian Malone -
Jóhann B. Guðmundsson -
Kevin Fenzi