So, we had a fudcon session about spins, but it was merged with the talk on Fedora Formulas and we didn't really decide anything about spins.
Formulas aren't going to fully replace spins, and even if they do, they likely won't be ready for f19 anyhow, so we need to figure out what we do for f19 now.
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Thoughts? counter proposals?
kevin
On Fri, Jan 25, 2013 at 13:54:04 -0700, Kevin Fenzi kevin@scrye.com wrote:
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
I guess using this list mostly. If there is something we need a meeting for, we can schedule one. If people want to really start working on future stuff, that might justify more meetings, but that is really separate than what we need to prepare for F19.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Does releng use the koji builds these days, or do they still have a separate compose and if so, where would we look to test the images that are going to be released?
Are we going to start doing all spins at alpha and beta again? For a while we had only been doing the desktop spins. This makes it easier for oversights to go unnoticed.
We could still use a cat herder if someone wants to volunteer for the job.
On 01/25/2013 10:38 PM, Bruno Wolff III wrote:
On Fri, Jan 25, 2013 at 13:54:04 -0700, Kevin Fenzi kevin@scrye.com wrote:
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
I guess using this list mostly. If there is something we need a meeting for, we can schedule one. If people want to really start working on future stuff, that might justify more meetings, but that is really separate than what we need to prepare for F19.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Does releng use the koji builds these days, or do they still have a separate compose and if so, where would we look to test the images that are going to be released?
Are we going to start doing all spins at alpha and beta again? For a while we had only been doing the desktop spins. This makes it easier for oversights to go unnoticed.
We could still use a cat herder if someone wants to volunteer for the job.
What about requiring submitters to create a ticket a trac ticket when spins are ready for wrangler?
If these tickets are sent to the list people can informally review them if they wish.
Am Freitag, den 25.01.2013, 23:21 +0100 schrieb Brendan Jones:
What about requiring submitters to create a ticket a trac ticket when spins are ready for wrangler?
That's exactly what I have in mind. I am currently working on a template and updating the wiki.
I'd like to take the opportunity to apologize to you and everybody else whose spin did not make it into F18. I tried to push things, but when I became aware of the new spins, it was already past the spins/feature submission deadline. Both I and the process itself have failed and I am fully taking the blame.
Let's make it better for F19!
Kind regards, Christoph
On 01/27/2013 02:57 PM, Christoph Wickert wrote:
Am Freitag, den 25.01.2013, 23:21 +0100 schrieb Brendan Jones:
What about requiring submitters to create a ticket a trac ticket when spins are ready for wrangler?
That's exactly what I have in mind. I am currently working on a template and updating the wiki.
Excellent!
I'd like to take the opportunity to apologize to you and everybody else whose spin did not make it into F18. I tried to push things, but when I became aware of the new spins, it was already past the spins/feature submission deadline. Both I and the process itself have failed and I am fully taking the blame.
The apology is really appreciated. In hindsight, we probably could have jumped up and down more to get attention, but we really had no idea how understaffed the Spins team were. We just assumed "stuff was being done".
Now that it looks like I may have some more time on my hands during the F18 period, I will join the Spins SIG and help out where I can. Let me know if there's anything I can do to help.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 15:38:54 -0600 Bruno Wolff III bruno@wolff.to escribió:
On Fri, Jan 25, 2013 at 13:54:04 -0700, Kevin Fenzi kevin@scrye.com wrote:
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
I guess using this list mostly. If there is something we need a meeting for, we can schedule one. If people want to really start working on future stuff, that might justify more meetings, but that is really separate than what we need to prepare for F19.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
I agree we should make sure that 2 at least 2 people sign off before we ship a spin. QA does not have the resources to test all spins, the only way to do it as part of QA would be to have more people get involved in QA.
Does releng use the koji builds these days, or do they still have a separate compose and if so, where would we look to test the images that are going to be released?
Releng has used koji for quite a few releases now, before the nightlies were done in koji.
Are we going to start doing all spins at alpha and beta again? For a while we had only been doing the desktop spins. This makes it easier for oversights to go unnoticed.
No we will not be doing all spins at alph and Beta only GA, the nightlies are there for testing all of them. its not that they are not being made just how they are made and shipped.
I honestly want to kill off spins as it stands. make just the 5 desktop spins as livecds. redefine things in someother way. maybe its going to be f20 or later before we can. but I do think we need to look at better ways to get the end results.
Dennis
On Mon, Jan 28, 2013 at 14:30:43 -0600, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 15:38:54 -0600 Bruno Wolff III bruno@wolff.to escribió:
Are we going to start doing all spins at alpha and beta again? For a while we had only been doing the desktop spins. This makes it easier for oversights to go unnoticed.
No we will not be doing all spins at alph and Beta only GA, the nightlies are there for testing all of them. its not that they are not being made just how they are made and shipped.
Since releng is using koji, this isn't that important. One can check the nightlies to make sure things are working. I was worried that looking at the nightlies might not show problems occuring in releng's build process.
I honestly want to kill off spins as it stands. make just the 5 desktop spins as livecds. redefine things in someother way. maybe its going to be f20 or later before we can. but I do think we need to look at better ways to get the end results.
Suprisingly I am not that big of a fan of having lots of prebuilt live images. I think building them when you want them is better, since you start with up to date packages. Having the recipies (whether ks files or this new ansible proposal) seems better. With us dropping the CD size limit, we might be able to post a single DVD sized live image that allows people to try out all of the desktops.
On 01/28/2013 10:05 PM, Bruno Wolff III wrote:
On Mon, Jan 28, 2013 at 14:30:43 -0600, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 15:38:54 -0600 Bruno Wolff III bruno@wolff.to escribió:
Are we going to start doing all spins at alpha and beta again? For a while we had only been doing the desktop spins. This makes it easier for oversights to go unnoticed.
No we will not be doing all spins at alph and Beta only GA, the nightlies are there for testing all of them. its not that they are not being made just how they are made and shipped.
Since releng is using koji, this isn't that important. One can check the nightlies to make sure things are working. I was worried that looking at the nightlies might not show problems occuring in releng's build process.
I honestly want to kill off spins as it stands. make just the 5 desktop spins as livecds. redefine things in someother way. maybe its going to be f20 or later before we can. but I do think we need to look at better ways to get the end results.
Suprisingly I am not that big of a fan of having lots of prebuilt live images. I think building them when you want them is better, since you start with up to date packages. Having the recipies (whether ks files or this new ansible proposal) seems better. With us dropping the CD size limit, we might be able to post a single DVD sized live image that allows people to try out all of the desktops.
I somewhat agree. I think most spins could be better serviced by comps groups selectable via anaconda.
In the audio spin for example, there are still some requirements which aren't available at install time, namely additional kernel parameters and group ownership. These are things I would like to talk with the anaconda team over the next release cycle.
Having said that, having a Live CD for use with USB overlay is very attractive for musicians on the move. Having something working out of the box in such a way is one of the main reasons we chose the Spin road. If it was possible to roll you own spin on demand (ie a webbased UI which provides all the available .ks files as a base), we could do away with Spins altogether. Some of the formula concepts were interesting too.
在 2013-1-29 PM5:02，"Brendan Jones" brendan.jones.it@gmail.com写道：
If it was possible to roll you own spin on demand (ie a webbased UI which
provides all the available .ks files as a base), we could do away with Spins altogether. Some of the formula concepts were interesting too.
Just like susestudio?
On 01/29/2013 10:10 AM, Christopher Meng wrote:
在 2013-1-29 PM5:02，"Brendan Jones" <brendan.jones.it@gmail.com mailto:brendan.jones.it@gmail.com>写道：
If it was possible to roll you own spin on demand (ie a webbased UI
which provides all the available .ks files as a base), we could do away with Spins altogether. Some of the formula concepts were interesting too.
Just like susestudio?
That's really nice. Its a bit buggy, but for sure I can see its benefits. Lots of stuff you can do here.
Aside: in terms of audio, Fedora eclipses Suse by number and variety of packages which is nice to know :) Am running a test now and report back on how long it takes etc
On 01/29/2013 10:10 AM, Christopher Meng wrote:
在 2013-1-29 PM5:02，"Brendan Jones" <brendan.jones.it@gmail.com mailto:brendan.jones.it@gmail.com>写道：
If it was possible to roll you own spin on demand (ie a webbased UI
which provides all the available .ks files as a base), we could do away with Spins altogether. Some of the formula concepts were interesting too.
Just like susestudio?
spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
In total about 7 minutes - as I said earlier, missing a lot of packages for my usecase, but all in all a very nice experience.
I think I chose .RAW format which is useless here for virtual box, will try with qemu and get back to all.
On Tue, Jan 29, 2013 at 10:02:13 +0100, Brendan Jones brendan.jones.it@gmail.com wrote:
If it was possible to roll you own spin on demand (ie a webbased UI which provides all the available .ks files as a base), we could do away with Spins altogether. Some of the formula concepts were interesting too.
I would expect that to be a bit slow to run for a web service. I can also see issues with expecting people to already have a Fedora installation for building custom live images. We could provide relatively up to date images for some reasonable number of images, like we do for the nightly testing images, but those won't be getting QA'd, so we'd need to make that clear.
I heard that someone has developed a multiple desktop installtion dvd? In alt.fp.o.
But it's 8.1GB at all. A live multi desktop version may be too large for a 4.7 GB DVD...
On Tue, Jan 29, 2013 at 17:06:07 +0800, Christopher Meng cickumqt@gmail.com wrote:
I heard that someone has developed a multiple desktop installtion dvd? In alt.fp.o.
But it's 8.1GB at all. A live multi desktop version may be too large for a 4.7 GB DVD...
I believe that one has several complete live images that you pick from when booting. I was thinking of one live image that you pick which desktop to login to at the gdm page. (That does require using gdm, and some of the desktop spins normally use a different login manager.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Tue, 29 Jan 2013 07:59:37 -0600 Bruno Wolff III bruno@wolff.to escribió:
On Tue, Jan 29, 2013 at 17:06:07 +0800, Christopher Meng cickumqt@gmail.com wrote:
I heard that someone has developed a multiple desktop installtion dvd? In alt.fp.o.
But it's 8.1GB at all. A live multi desktop version may be too large for a 4.7 GB DVD...
I believe that one has several complete live images that you pick from when booting. I was thinking of one live image that you pick which desktop to login to at the gdm page. (That does require using gdm, and some of the desktop spins normally use a different login manager.)
that one uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
Dennis
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events? Shouldn't what we give to people be something that is intended for general consumption?
Bill
On Tue, Jan 29, 2013 at 11:48 AM, Bill Nottingham notting@redhat.com wrote:
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events? Shouldn't what we give to people be something that is intended for general consumption?
It is clearly meant for general consumption via pressed media but wasn't intended for general consumption via download from the mirrors.
John
Am Dienstag, den 29.01.2013, 12:48 -0500 schrieb Bill Nottingham:
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events?
Because it hard to guess in advance what people want: GNOME, KDE, Xfce, LXDE, i386, x86_64. You always run out of something and we ended up shipping media back and forth. With the multi-images, live has become so much easier for the Ambassadors - not to mention that we cut costs by over 50% (or by 400% if you consider one DVD 8 CDs).
Shouldn't what we give to people be something that is intended for general consumption?
Sure, but what defines "intended for general consumption"?
Best regards, Christoph
Christoph Wickert (christoph.wickert@gmail.com) said:
Am Dienstag, den 29.01.2013, 12:48 -0500 schrieb Bill Nottingham:
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events?
Because it hard to guess in advance what people want: GNOME, KDE, Xfce, LXDE, i386, x86_64. You always run out of something and we ended up shipping media back and forth. With the multi-images, live has become so much easier for the Ambassadors - not to mention that we cut costs by over 50% (or by 400% if you consider one DVD 8 CDs).
Shouldn't what we give to people be something that is intended for general consumption?
Sure, but what defines "intended for general consumption"?
I don't know, I'm just going by how Dennis described it. I'm also concerned that part of the problem is having essentially 8 deliverables that people might want at the show that requires this level of hacking together but I realize that not everyone shares that opinion.
Bill
Am Mittwoch, den 30.01.2013, 10:55 -0500 schrieb Bill Nottingham:
Christoph Wickert (christoph.wickert@gmail.com) said:
Sure, but what defines "intended for general consumption"?
I don't know, I'm just going by how Dennis described it. I'm also concerned that part of the problem is having essentially 8 deliverables that people might want at the show that requires this level of hacking together but I realize that not everyone shares that opinion.
Could elaborate what exactly you consider the problem? The number of options or hacking them together?
Kind regards, Christoph
Christoph Wickert (christoph.wickert@gmail.com) said:
Am Mittwoch, den 30.01.2013, 10:55 -0500 schrieb Bill Nottingham:
Christoph Wickert (christoph.wickert@gmail.com) said:
Sure, but what defines "intended for general consumption"?
I don't know, I'm just going by how Dennis described it. I'm also concerned that part of the problem is having essentially 8 deliverables that people might want at the show that requires this level of hacking together but I realize that not everyone shares that opinion.
Could elaborate what exactly you consider the problem? The number of options or hacking them together?
Number of options, mostly. Giving users who are likely to be new to Fedora a bunch of options which they hae no criteria to select which is which. It's akin to giving someone an Android phone with four different launchers preinstalled and asking them on boot which one they want to run.
Bill
Am Mittwoch, den 30.01.2013, 12:58 -0500 schrieb Bill Nottingham:
Christoph Wickert (christoph.wickert@gmail.com) said:
Could elaborate what exactly you consider the problem? The number of options or hacking them together?
Number of options, mostly. Giving users who are likely to be new to Fedora a bunch of options which they hae no criteria to select which is which. It's akin to giving someone an Android phone with four different launchers preinstalled and asking them on boot which one they want to run.
I don't see a problem here. They would just fire up all 4, give then a try and pick the one they like most. That's what the multi-live DVD is for: You can just test everything without having to install it. When you are done, you install what you like. But if we give people 4 different live CDs, we will run out of media pretty soon.
Linux is all about having and making choices. If people really have a problem with choice, then Linux is not for them.
Kind regards, Christoph
On 01/30/2013 10:55 AM, Bill Nottingham wrote:
I don't know, I'm just going by how Dennis described it. I'm also concerned that part of the problem is having essentially 8 deliverables that people might want at the show that requires this level of hacking together but I realize that not everyone shares that opinion.
To be fair, the only reason it had a higher level of "hacking together" this time around was Secure Boot. Normally, it isn't much complexity at all.
(Says the guy who wrote the disgusting pile of python that makes the master ISO)
~tom
== Fedora Project
On Tue, 29 Jan 2013 12:48:32 -0500 Bill Nottingham notting@redhat.com wrote:
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events? Shouldn't what we give to people be something that is intended for general consumption?
its not intended to be downloaded and burnt to a dual layer disk by the general public, its intended to be used for pressed media only. I guess i choose my wording poorly.
Dennis
Am Mittwoch, den 30.01.2013, 11:18 -0600 schrieb Dennis Gilmore:
On Tue, 29 Jan 2013 12:48:32 -0500 Bill Nottingham notting@redhat.com wrote:
Redirecting from spins@.
Dennis Gilmore (dennis@ausil.us) said:
[the multi-desktop DVD] uses grub/syslinux to select which of the 5 desktop lives you want to run. its designed for use by ambassadors to give out at events. it has both 32 and 64 bit images on it its designed for use with dual layer media. Release Engineering produce it for final only to be used to create media to be given away at events, it is not designed or intended for general consumption.
If it's not intended for general consumption, why on earth is it what we give away at events? Shouldn't what we give to people be something that is intended for general consumption?
its not intended to be downloaded and burnt to a dual layer disk by the general public, its intended to be used for pressed media only. I guess i choose my wording poorly.
No problem. I totally agree this definition, but then I have to disagree with Bill. It's true that it's not meant for general consumption, but we should not restrict what we give out to "general consumption". The very purpose of this is to be given out, to offer advantages over what we officially offer for download, something special you only get on events.
I don't see this as a problem and even if somebody considers it to be one, I think the benefits (less shipping, less hassle, better value for money) are bigger than the concerns.
Kind regards, Christoph
On Fri, Jan 25, 2013 at 8:54 PM, Kevin Fenzi kevin@scrye.com wrote:
So, we had a fudcon session about spins, but it was merged with the talk on Fedora Formulas and we didn't really decide anything about spins.
Formulas aren't going to fully replace spins, and even if they do, they likely won't be ready for f19 anyhow, so we need to figure out what we do for f19 now.
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
What about using the Feature process to get them approved?
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
Agreed
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
I think discussion on this list.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Sounds reasonable. What about getting them into the QA process?
Peter
On Fri, 25 Jan 2013 23:29:34 +0000 Peter Robinson pbrobinson@gmail.com wrote:
What about using the Feature process to get them approved?
Well, they all followed the process in f18, so I would say just add them in... but sure. For new ones just making them do that might be fine.
...snip...
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Sounds reasonable. What about getting them into the QA process?
Well, QA only formally tests desktop and kde. Anything else is just a nice to do, there's no requirement or resources for it.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 25 Jan 2013 at 13:54:04 -0700, Kevin Fenzi wrote:
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
*chime*
While I'm glad our JVM developer spin (or whatever it will be called), didn't get added for F18 (the conversation came around far too late); I'll try to push a little harder for inclusion in F19. I don't think our current 'remix' is in a fit state to be committed as an official spin just yet (when we figured it wasn't going to be an official spin for a while, we got a little experimental). I'll try to get some time to clean it up and propose it soon, but it might be about a week before I even get to look at it.
On Fri, Jan 25, 2013 at 05:03:17PM -0700, Kevin Fenzi wrote:
On Fri, 25 Jan 2013 23:29:34 +0000 Peter Robinson pbrobinson@gmail.com wrote:
What about using the Feature process to get them approved?
Well, they all followed the process in f18, so I would say just add them in... but sure. For new ones just making them do that might be fine.
From experience with trying to get approval last year, the main problem seemed to be that the burden seemed to be falling solely on Christoph to do the brunt of the work of making sure each kickstart was in an acceptable shape, and organising meetings to get consensus for approval. I don't have much previous experience with the spins process, but I think if that same process was applied slightly differently, then it could work fine (it could also be severely flawed and doomed from the outset, I don't know). Here's what I'm thinking:
1. Someone has a new spin that they would like to get added, so they come here to find someone who already has gone through the process and maintains a spin, to review/'wrangle' their kickstart into acceptable shape.
2. When it is deemed acceptable, it's proposed here (I guess link to a wiki page in the current format, which additionally includes the name of the person who reviewed/wrangled it). It's discussed here for a predetermined time (week/fortnight) to give all relevant parties ample opportunity to air their concerns or give their approval -- eliminating the need for everyone to be available at the same time for a meeting.
3. Once the time period is up, the person who reviewed it helps the new spin maintainer to get it added. I'm not sure what exactly needs to be done here, as I haven't gotten that far myself.
^So basically something similar to getting sponsorship to be a packager I guess.
Whatever the process, I might repropose the JVM developer spin from scratch, since it changed a lot from the point it was proposed last time (proposed prematurely to be in for the deadline, July/August).
Gerard.
Am Freitag, den 25.01.2013, 13:54 -0700 schrieb Kevin Fenzi:
So, we had a fudcon session about spins, but it was merged with the talk on Fedora Formulas and we didn't really decide anything about spins.
Glad to hear that.
I saw the session on Youtube and I disagree to a lot that was said. I think it's good that things are not set in stone yet.
Formulas aren't going to fully replace spins, and even if they do, they likely won't be ready for f19 anyhow, so we need to figure out what we do for f19 now.
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
Fortunately I'm not *that* swamped any longer and I am currently working on our trac to move the spin reviews from the wiki to the track instance.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Makes sense, but IHMO dropping a spin will only make things worse.Without live media, there is no easy way to test things and the in the end, things that received little testing will be tested even less. It seems that even KDE didn't get proper testing this time and I think we all agree we cannot drop it.
I think we need to work on fixing the process. Dropping a spin is only the last resort.
Kind regards, Christoph
On 27 January 2013 06:53, Christoph Wickert christoph.wickert@gmail.com wrote:
Am Freitag, den 25.01.2013, 13:54 -0700 schrieb Kevin Fenzi:
Makes sense, but IHMO dropping a spin will only make things worse.Without live media, there is no easy way to test things and the in the end, things that received little testing will be tested even less. It seems that even KDE didn't get proper testing this time and I think we all agree we cannot drop it.
A spin only "tests" a certain configuration and set of choices not made by the user but by the Spin groups. The problems usually show up when people deviate from that safe path.
I think we need to work on fixing the process. Dropping a spin is only the last resort.
The most important fix to the process is making it not 1 deep. There needs to be more than you Bruno and Kevin working on it because your times are maxed out and saying they will get better rarely works. Second we need to get the owners of the spins take responsibility of them and keep them up to date. Sending stuff off 6 releases ago that no-one checks out just says that spins are where that data goes off to die.
Am Sonntag, den 27.01.2013, 12:01 -0700 schrieb Stephen John Smoogen:
On 27 January 2013 06:53, Christoph Wickert christoph.wickert@gmail.com wrote:
Am Freitag, den 25.01.2013, 13:54 -0700 schrieb Kevin Fenzi:
Makes sense, but IHMO dropping a spin will only make things worse.Without live media, there is no easy way to test things and the in the end, things that received little testing will be tested even less. It seems that even KDE didn't get proper testing this time and I think we all agree we cannot drop it.
A spin only "tests" a certain configuration and set of choices not made by the user but by the Spin groups. The problems usually show up when people deviate from that safe path.
We had serious problems even with the spins, that means even with this particular combination of packages and configuration that were (supposed to be) tested.
I think we need to work on fixing the process. Dropping a spin is only the last resort.
The most important fix to the process is making it not 1 deep.
+1. The idea is streamline it and make it more similar to the feature process.
There needs to be more than you Bruno and Kevin working on it because your times are maxed out and saying they will get better rarely works.
I had a tough time at work, but it has become better. I cannot speak for Kevin or Bruno though. Kevin seems pretty busy with infrastructure, too.
Second we need to get the owners of the spins take responsibility of them and keep them up to date. Sending stuff off 6 releases ago that no-one checks out just says that spins are where that data goes off to die.
Yes and no. The Design Suite for example shouldn't have been published as it was unmaintained. Luya took over maintainership after the release, so we cannot blame him. On the other hand I feel we apply double standards. Have a look at the Desktop live media. The desktop team only changes the package selection or some configuration here and there, but if something is really (about to be) broken, it's usually fixed by someone from rel-eng. The desktop team hardly does any testing by themselves, instead QA does a lot.
I feel this is kind of unfair. Given how little attention the spins get and the limited resources we have, it's not surprisingsome of them are not in good shape.
Kind regards, Christoph
On Sun, Jan 27, 2013 at 23:40:27 +0100, Christoph Wickert christoph.wickert@gmail.com wrote:
I had a tough time at work, but it has become better. I cannot speak for Kevin or Bruno though. Kevin seems pretty busy with infrastructure, too.
I can spend some time. Spins SIG needs cat herding or being more hard ass about not making deadlines. And I am don't like doing those things. I am fine with helping develop work practices and with reviews.
I try to keep up with stuff, but even I screwed up this time and didn't notice a late dropped package broke the games spin.
On 27 January 2013 15:40, Christoph Wickert christoph.wickert@gmail.com wrote:
Second we need to get the owners of the spins take responsibility of them and keep them up to date. Sending stuff off 6 releases ago that no-one checks out just says that spins are where that data goes off to die.
Yes and no. The Design Suite for example shouldn't have been published as it was unmaintained. Luya took over maintainership after the release, so we cannot blame him.
Oh I don't blame him. I just think that we spend too much of our time in Fedora doing a lot of Heroic saves where it might be better to kill it off. We have too many people seeing a package, spin, etc being abandoned and then stepping in and taking it without really looking at "Does this really need to be kept?" I think Spins especially can NOT rely on one person per release but each needs a team of people in charge of it. And if a SIG or group doesn't want to do that.. why do we keep it?
On the other hand I feel we apply double standards. Have a look at the Desktop live media. The desktop team only changes the package selection or some configuration here and there, but if something is really (about to be) broken, it's usually fixed by someone from rel-eng. The desktop team hardly does any testing by themselves, instead QA does a lot.
I feel this is kind of unfair. Given how little attention the spins get and the limited resources we have, it's not surprisingsome of them are not in good shape.
OH I am in perfect agreement here. I would put any and all Spins on the proverbial chopping block if they aren't being backed by a team of people who are actually fixing things versus leaving them to be fixed by others.
Kind regards, Christoph
spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On Sunday 27 of January 2013 14:53:54 Christoph Wickert wrote:
Am Freitag, den 25.01.2013, 13:54 -0700 schrieb Kevin Fenzi:
So, we had a fudcon session about spins, but it was merged with the talk on Fedora Formulas and we didn't really decide anything about spins.
Glad to hear that.
I saw the session on Youtube and I disagree to a lot that was said. I think it's good that things are not set in stone yet.
Formulas aren't going to fully replace spins, and even if they do, they likely won't be ready for f19 anyhow, so we need to figure out what we do for f19 now.
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
Fortunately I'm not *that* swamped any longer and I am currently working on our trac to move the spin reviews from the wiki to the track instance.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Makes sense, but IHMO dropping a spin will only make things worse.Without live media, there is no easy way to test things and the in the end, things that received little testing will be tested even less. It seems that even KDE didn't get proper testing this time and I think we all agree we cannot drop it.
No proper testing for KDE? Really?
I see quite a good coverage even for LXDE, Xfce and Sugar [1].
[1] https://fedoraproject.org/wiki/Test_Results:Fedora_18_Final_RC4_Desktop?rd=T...
I think we need to work on fixing the process. Dropping a spin is only the last resort.
Kind regards, Christoph
spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On 01/30/2013 05:01 PM, Jaroslav Reznik wrote:
On Sunday 27 of January 2013 14:53:54 Christoph Wickert wrote:
Am Freitag, den 25.01.2013, 13:54 -0700 schrieb Kevin Fenzi:
So, we had a fudcon session about spins, but it was merged with the talk on Fedora Formulas and we didn't really decide anything about spins.
Glad to hear that.
I saw the session on Youtube and I disagree to a lot that was said. I think it's good that things are not set in stone yet.
Formulas aren't going to fully replace spins, and even if they do, they likely won't be ready for f19 anyhow, so we need to figure out what we do for f19 now.
a) what about the new spins that didn't get added in f18? If their spin owners are actually active, they should chime in and commit their ks to git and update the f19 spins page with their size and so releng knows to produce them.
b) Any new spins need to SUBMIT THEIR KS FILES ASAP so we can avoid problems where things don't make it.
c) There's no meetings, Christoph is swamped, how do we want to handle the day to day business of the sig?
Fortunately I'm not *that* swamped any longer and I am currently working on our trac to move the spin reviews from the wiki to the track instance.
I was thinking we should require at each freeze point that any spins we promote on spins.fedoraproject.org have at least 2 people sign off that they tested them and they basically work. If 0 people do this sign off, we should still produce them, but they sit in alt and don't get promoted anywhere. If a spin doesn't get any testing for an entire cycle, we drop them completely.
Makes sense, but IHMO dropping a spin will only make things worse.Without live media, there is no easy way to test things and the in the end, things that received little testing will be tested even less. It seems that even KDE didn't get proper testing this time and I think we all agree we cannot drop it.
No proper testing for KDE? Really?
I see quite a good coverage even for LXDE, Xfce and Sugar [1].
Fedora Jam: we are pretty pedantic when it comes to testing. Using KDE as a base you could say that it is well covered also
-
Bill Nottingham -
Brendan Jones -
Bruno Wolff III -
Christoph Wickert -
Christopher Meng -
Dennis Gilmore -
Gerard Ryan -
inode0 -
Jaroslav Reznik -
Kevin Fenzi -
Peter Robinson -
Stephen John Smoogen -
Tom Callaway