Hi there,
Fedora 10 has entered it's Beta Freeze stage which in your case is the time to start making absolutely sure your Spins are in perfect shape for being composed by Release Engineering.
Things you will need to make sure are, amongst others:
- it is not oversized - it composes without troubles - it ends up like you want it - it boots, and runs - it shows no unexpected behavior in applications you include
Right now, the following kickstarts are approved by the Spin SIG:
= fedora-aos.ks (Fedora AOS) =
- SELinux was added back to address the Board's concern with it being removed originally. This should resolve the only issue the Board raised but we've not yet seen explicit approval.
- The tool this spin is supposed to be composed with, appliance-tools, is currently at Release Engineering's discretion. As said before, this spin also composes with livecd-tools and spits out a nice minimal live ISO which then again of course also includes the raw ext3 .img file.
- Approved by Spin SIG, - Approved by Board - Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/appliance-tools
= fedora-livecd-broffice.org.ks (Fedora BrOffice.org) =
- Approved by Spin SIG, - Approved by Board, - Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/BrOffice.orgSpin
= fedora-livecd-desktop-default.ks (Fedora Desktop) =
- One of our permanent spins
= fedora-livecd-education-math.ks (Fedora Education Math) =
- Approved by Spin SIG, - Approved by Board, - Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/EducationMathSpin
= fedora-livecd-kde.ks (Fedora KDE) =
- One of our permanent spins
= fedora-livecd-xfce.ks (Fedora XFCE) =
- Approved by Spin SIG, - Approved by Board after a little shuffling with the Feature Page, - Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/XfceSpin
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG, - Approved by Board, - Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
- One of the spins that has been approved previously (Fedora 8) - Approved by Spin SIG, - Approved by Board, - Pending approval from Rel. Eng. (but does not have the right category on it's Feature page to show up on Rel. Eng.'s radar, maybe since the feature page existed for Fedora 8 already).
Feature Page: https://fedoraproject.org/wiki/Features/FedoraElectronicLab
= fedora-livedvd-games.ks (Fedora Games) =
- One of the Spins that have been previously accepted (Fedora 8) and is now re-entering the process. - Approved by Spin SIG, - No Approval from Board requested, but previously approved, - Not yet approved for Fedora 10 by Rel. Eng. (but in the FeatureReadyForFesco category).
Feature Page: https://fedoraproject.org/wiki/Features/GamesSpin
For the Fedora 10 Beta, a new branch has been created in the spin-kickstarts repository, called F-10-Beta. This branch only contains the files necessary for composing the spins. Note that like the rawhide tree, this branch is supposed to be frozen and as such you should only be applying fixes, no huge changes.
To checkout the F-10-Beta branch and start working with it, do:
git pull git checkout --track -b F-10-Beta origin/F-10-Beta
You should not commit any changes to this branch as this is what Rel. Eng. is going to use to compose the spins from, and we do not know when that is exactly. Fixes go into the master branch and are pulled into the F-10-Beta branch only if necessary.
If you have any questions or remarks, please don't hesitate and drop the list a line.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Hi there,
Fedora 10 has entered it's Beta Freeze stage which in your case is the time to start making absolutely sure your Spins are in perfect shape for being composed by Release Engineering.
Replying to myself; these two commits have been copied onto the F-10-Beta branch:
fedora-livecd-broffice.org.ks | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
New commits: commit 6f5d0e5e7ac00f045c7f65aa42b5f08d6586d02c Author: Igor Pires Soares <igor@amd5600.(none)> Date: Sun Sep 14 12:44:23 2008 -0300
More Asian fonts out
and
fedora-live-base.ks | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
New commits: commit d440660c09ef3c1c6657a0ea7f2ba39798a4e09f Author: Jeremy Katz katzj@redhat.com Date: Sun Sep 14 16:06:42 2008 -0400
Use GConf keys only for disabling packagekit update notification The GConf keys for PackageKit now do the right thing for disabling checking for updates and notifying the user about them. So use them rather than the autostart hacked used in F9
Kind regards,
Jeroen van Meeuwen -kanarip
Em Dom, 2008-09-14 às 23:14 +0200, Jeroen van Meeuwen escreveu:
Jeroen van Meeuwen wrote:
Hi there,
Fedora 10 has entered it's Beta Freeze stage which in your case is the time to start making absolutely sure your Spins are in perfect shape for being composed by Release Engineering.
Replying to myself; these two commits have been copied onto the F-10-Beta branch:
fedora-livecd-broffice.org.ks | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
New commits: commit 6f5d0e5e7ac00f045c7f65aa42b5f08d6586d02c Author: Igor Pires Soares <igor@amd5600.(none)> Date: Sun Sep 14 12:44:23 2008 -0300
More Asian fonts out
Thanks Jeroen, I saw your first e-mail right after this commit. Good to know it was updated to the F-10-Beta branch.
Jeroen van Meeuwen wrote:
Hi there,
If you have any questions or remarks, please don't hesitate and drop the list a line.
We noticed today on the aos-spin that if you build on a 64 bit machine you run out of space. We can either (1) force folks to build i386 or (2) up the size to be 500M which is above the current size of the 64 bit rpms.
I would tend to prefer the latter... thoughts?
-- bk
On Mon, 2008-09-15 at 16:40 -0400, Bryan Kearney wrote:
I would tend to prefer the latter... thoughts?
Please the latter. In order to compose i386 we use setarch on an x86_64 system.
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Hi there,
If you have any questions or remarks, please don't hesitate and drop the list a line.
We noticed today on the aos-spin that if you build on a 64 bit machine you run out of space. We can either (1) force folks to build i386 or (2) up the size to be 500M which is above the current size of the 64 bit rpms.
I would tend to prefer the latter... thoughts?
Does the x86_64 version of the AOS spin include i386 packages by any chance, or is the spin just bigger even with just x86_64 packages?
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Hi there,
If you have any questions or remarks, please don't hesitate and drop the list a line.
We noticed today on the aos-spin that if you build on a 64 bit machine you run out of space. We can either (1) force folks to build i386 or (2) up the size to be 500M which is above the current size of the 64 bit rpms.
I would tend to prefer the latter... thoughts?
Does the x86_64 version of the AOS spin include i386 packages by any chance, or is the spin just bigger even with just x86_64 packages?
Just the increased package size. Should I commit the change to the mainline, and send you the commit to merge into the branch?
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Hi there,
If you have any questions or remarks, please don't hesitate and drop the list a line.
We noticed today on the aos-spin that if you build on a 64 bit machine you run out of space. We can either (1) force folks to build i386 or (2) up the size to be 500M which is above the current size of the 64 bit rpms.
I would tend to prefer the latter... thoughts?
Does the x86_64 version of the AOS spin include i386 packages by any chance, or is the spin just bigger even with just x86_64 packages?
Just the increased package size. Should I commit the change to the mainline, and send you the commit to merge into the branch?
You can send it to mainline and I'll pick it up from there (spin-kickstarts-commits@lists.fedorahosted.org will get the commit).
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
You can send it to mainline and I'll pick it up from there (spin-kickstarts-commits@lists.fedorahosted.org will get the commit).
We have tested 44f221c2a4b67cf6b07649254b69d6689c6d20b2. Please pull that to the branch. Thanks!
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
You can send it to mainline and I'll pick it up from there (spin-kickstarts-commits@lists.fedorahosted.org will get the commit).
We have tested 44f221c2a4b67cf6b07649254b69d6689c6d20b2. Please pull that to the branch. Thanks!
It had been pulled into the F-10-Beta branch already, thanks.
Kind regards,
Jeroen van Meeuwen -kanarip
Em Qua, 2008-09-17 às 17:42 +0200, Jeroen van Meeuwen escreveu:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
You can send it to mainline and I'll pick it up from there (spin-kickstarts-commits@lists.fedorahosted.org will get the commit).
We have tested 44f221c2a4b67cf6b07649254b69d6689c6d20b2. Please pull that to the branch. Thanks!
It had been pulled into the F-10-Beta branch already, thanks.
Due to the inclusion of echo icon theme as a default in lasted Rawhide updates, the BrOffice.org Spin became a little oversized. I updated the master branch some moments ago. It would be nice to have the updated .ks in F-10-Beta branch, if possible.
Regards, Igor
Igor Pires Soares wrote:
Due to the inclusion of echo icon theme as a default in lasted Rawhide updates, the BrOffice.org Spin became a little oversized. I updated the master branch some moments ago. It would be nice to have the updated .ks in F-10-Beta branch, if possible.
Done.
Another compose if running for all spins, look at http://spinner.fedoraunity.org/revisor for more details (check the date stamp to see if it is anything recent).
Note the above is an indicator, using Revisor, not livecd-tools, and may therefore differ from the actual results. The idea is you get a log file, and can compose with livecd-tools yourself if anything is wrong or odd.
Kind regards,
Jeroen van Meeuwen -kanarip
Em Qui, 2008-09-18 às 10:43 +0200, Jeroen van Meeuwen escreveu:
Igor Pires Soares wrote:
Due to the inclusion of echo icon theme as a default in lasted Rawhide updates, the BrOffice.org Spin became a little oversized. I updated the master branch some moments ago. It would be nice to have the updated .ks in F-10-Beta branch, if possible.
Done.
Another compose if running for all spins, look at http://spinner.fedoraunity.org/revisor for more details (check the date stamp to see if it is anything recent).
Note the above is an indicator, using Revisor, not livecd-tools, and may therefore differ from the actual results. The idea is you get a log file, and can compose with livecd-tools yourself if anything is wrong or odd.
I don't see a folder for BrOffice.org Spin there...
Regards, Igor
Igor Pires Soares wrote:
Em Qui, 2008-09-18 Ã s 10:43 +0200, Jeroen van Meeuwen escreveu:
Igor Pires Soares wrote:
Due to the inclusion of echo icon theme as a default in lasted Rawhide updates, the BrOffice.org Spin became a little oversized. I updated the master branch some moments ago. It would be nice to have the updated .ks in F-10-Beta branch, if possible.
Done.
Another compose if running for all spins, look at http://spinner.fedoraunity.org/revisor for more details (check the date stamp to see if it is anything recent).
Note the above is an indicator, using Revisor, not livecd-tools, and may therefore differ from the actual results. The idea is you get a log file, and can compose with livecd-tools yourself if anything is wrong or odd.
I don't see a folder for BrOffice.org Spin there...
True, I had an error in the script that makes these composes run. The next run should have the broffice.org spin as well.
Kind regards,
Jeroen van Meeuwen -kanarip
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livecd-broffice.org.ks (Fedora BrOffice.org) =
- Approved by Spin SIG,
- Approved by Board,
- Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/BrOffice.orgSpin
Hrm, I don't recall this one coming through releng. Not that I'm opposed to it, I just don't see record of it on our list.
= fedora-livecd-education-math.ks (Fedora Education Math) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/EducationMathSpin
I thought this was approved: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-aug-11#Spins
= fedora-livecd-xfce.ks (Fedora XFCE) =
- Approved by Spin SIG,
- Approved by Board after a little shuffling with the Feature Page,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/XfceSpin
ditto
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
Don't recall this one ever coming up for approval
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
- One of the spins that has been approved previously (Fedora 8)
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng. (but does not have the right category
on it's Feature page to show up on Rel. Eng.'s radar, maybe since the feature page existed for Fedora 8 already).
Feature Page: https://fedoraproject.org/wiki/Features/FedoraElectronicLab
Yeah, I remember some oddness happening with this one and wiki locations.
= fedora-livedvd-games.ks (Fedora Games) =
- One of the Spins that have been previously accepted (Fedora 8) and is
now re-entering the process.
- Approved by Spin SIG,
- No Approval from Board requested, but previously approved,
- Not yet approved for Fedora 10 by Rel. Eng. (but in the
FeatureReadyForFesco category).
Feature Page: https://fedoraproject.org/wiki/Features/GamesSpin
Was approved by releng already http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-aug-11#Spins
Sounds like we need to get our ducks in a row.
Em Seg, 2008-09-15 às 17:57 -0700, Jesse Keating escreveu:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livecd-broffice.org.ks (Fedora BrOffice.org) =
- Approved by Spin SIG,
- Approved by Board,
- Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/BrOffice.orgSpin
Hrm, I don't recall this one coming through releng. Not that I'm opposed to it, I just don't see record of it on our list.
This one was submitted to releng in early September:
http://lists.fedoraproject.org/pipermail/rel-eng/2008-September/001665.html
On September the 9th the Feature Page category was changed to "FeatureAcceptedF10" by John Poelstra.
Regards, Igor Pires Soares
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livecd-broffice.org.ks (Fedora BrOffice.org) =
- Approved by Spin SIG,
- Approved by Board,
- Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/BrOffice.orgSpin
Hrm, I don't recall this one coming through releng. Not that I'm opposed to it, I just don't see record of it on our list.
I took the Feature Page category FeatureAcceptedF10 as the indicator (same for the rest). Was I wrong to do so?
= fedora-livecd-education-math.ks (Fedora Education Math) =
I thought this was approved: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-aug-11#Spins
Awesome ;-)
= fedora-livecd-xfce.ks (Fedora XFCE) =
ditto
;-)
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
Don't recall this one ever coming up for approval
OK, maybe I'm misinterpreting ProposedFeatureF10...
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Yeah, I remember some oddness happening with this one and wiki locations.
I can only assume it's resolved and accepted, since this spin lacking in Fedora 9 was one of the big motivators to even start building a process around it like we have now...
= fedora-livedvd-games.ks (Fedora Games) =
Was approved by releng already http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-aug-11#Spins
Sounds like we need to get our ducks in a row.
Yes it sounds like we need to. I'm taking the categories as an indicator now, but maybe that's not what you use and flip when a spin is accepted or not.
Kind regards,
Jeroen van Meeuwen -kanarip
On Tue, 2008-09-16 at 09:45 +0200, Jeroen van Meeuwen wrote:
Yes it sounds like we need to. I'm taking the categories as an indicator now, but maybe that's not what you use and flip when a spin is accepted or not.
Well, this process is still a bit... new, so I'm not surprised there is some rough road. I think we (rel-eng) has been expecting John Poelstra to bring these spins for approval to our attention, just as he brings features to FESCo's attention. I'm not sure /he/ was expecting that though, so it would not be surprising that some things haven't bee communicated.
Can we take your list that I quoted as what the spins sig expects or hopes to see produced for Fedora 10? If so, releng can do some last minute voting on the things we haven't talked about yet, although this is a very large amount of spins to produce :/
Jesse Keating wrote:
On Tue, 2008-09-16 at 09:45 +0200, Jeroen van Meeuwen wrote:
Yes it sounds like we need to. I'm taking the categories as an indicator now, but maybe that's not what you use and flip when a spin is accepted or not.
Well, this process is still a bit... new, so I'm not surprised there is some rough road. I think we (rel-eng) has been expecting John Poelstra to bring these spins for approval to our attention, just as he brings features to FESCo's attention. I'm not sure /he/ was expecting that though, so it would not be surprising that some things haven't bee communicated.
Right, this is what I expect is one of the aspects of it being a new process... Mixed with the Feature process no less.
Can we take your list that I quoted as what the spins sig expects or hopes to see produced for Fedora 10?
The list that I quoted is from what the Spin SIG had approved and was intended to go through the entire process up and until the point of being released by the Fedora Project proper.
If so, releng can do some last
minute voting on the things we haven't talked about yet, although this is a very large amount of spins to produce :/
Yeah, that's what we're here for ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
Jesse Keating said the following on 09/16/2008 08:32 AM Pacific Time:
On Tue, 2008-09-16 at 09:45 +0200, Jeroen van Meeuwen wrote:
Yes it sounds like we need to. I'm taking the categories as an indicator now, but maybe that's not what you use and flip when a spin is accepted or not.
Well, this process is still a bit... new, so I'm not surprised there is some rough road. I think we (rel-eng) has been expecting John Poelstra to bring these spins for approval to our attention, just as he brings features to FESCo's attention. I'm not sure /he/ was expecting that though, so it would not be surprising that some things haven't bee communicated.
Yes I was not clear on exactly what the process is and still am not.
I apologize for the confusion I created by changing the category to FeatureAcceptedF10.
I changed a couple of them and then stopped when I realized that it didn't make complete sense as the "feature process" I help manage relates specifically to features approved by FESCo. Those features are listed here: https://fedoraproject.org/wiki/Releases/10/FeatureList.
I asked a few people what the process around spins was supposed to be, but couldn't get any clear answers. I should have posted to fedora-devel list and sought clarification. It seemed odd to me that all our documentation describes how FESCo "accepts" features that are listed here https://fedoraproject.org/wiki/Releases/10/FeatureList and then to start adding Spins to the same page which go through a similar, but more different process that aren't exactly "accepted" by FESCo, as I understand it. Forgive me if I've made this too complicated :)
I see two processes going on here which I perceive as follows:
1) "FESCo feature" process --clearly documented here what happens when and by who: https://fedoraproject.org/wiki/Features/Policy/Process
2) Spins process --No process flow that I have found defined that I can figure out exactly which part I am supposed to be helping with nor is it clearly defined how the approval/acceptance process is tracked and where they end up or are listed once said approval/acceptance/rejection has taken place.
At present I can't commit the time to manage or define the process around spins approval/acceptance, but could help with drawing a flowchart if that helps clarify things.
John
John Poelstra wrote:
Jesse Keating said the following on 09/16/2008 08:32 AM Pacific Time:
On Tue, 2008-09-16 at 09:45 +0200, Jeroen van Meeuwen wrote:
Yes it sounds like we need to. I'm taking the categories as an indicator now, but maybe that's not what you use and flip when a spin is accepted or not.
Well, this process is still a bit... new, so I'm not surprised there is some rough road. I think we (rel-eng) has been expecting John Poelstra to bring these spins for approval to our attention, just as he brings features to FESCo's attention. I'm not sure /he/ was expecting that though, so it would not be surprising that some things haven't bee communicated.
Yes I was not clear on exactly what the process is and still am not.
I apologize for the confusion I created by changing the category to FeatureAcceptedF10.
I changed a couple of them and then stopped when I realized that it didn't make complete sense as the "feature process" I help manage relates specifically to features approved by FESCo. Those features are listed here: https://fedoraproject.org/wiki/Releases/10/FeatureList.
I asked a few people what the process around spins was supposed to be, but couldn't get any clear answers. I should have posted to fedora-devel list and sought clarification. It seemed odd to me that all our documentation describes how FESCo "accepts" features that are listed here https://fedoraproject.org/wiki/Releases/10/FeatureList and then to start adding Spins to the same page which go through a similar, but more different process that aren't exactly "accepted" by FESCo, as I understand it. Forgive me if I've made this too complicated :)
I see two processes going on here which I perceive as follows:
- "FESCo feature" process
--clearly documented here what happens when and by who: https://fedoraproject.org/wiki/Features/Policy/Process
- Spins process
--No process flow that I have found defined that I can figure out exactly which part I am supposed to be helping with nor is it clearly defined how the approval/acceptance process is tracked and where they end up or are listed once said approval/acceptance/rejection has taken place.
At present I can't commit the time to manage or define the process around spins approval/acceptance, but could help with drawing a flowchart if that helps clarify things.
Does this help?
https://fedoraproject.org/wiki/User:Bkearney/ProposedSpinProcess
-- bk
Bryan Kearney said the following on 09/17/2008 05:50 AM Pacific Time:
Does this help?
https://fedoraproject.org/wiki/User:Bkearney/ProposedSpinProcess
Now you're talking my language :)
For each step along the way how are you proposing to track the approval or completion? IOW if I were to help with (4), how would I tell if (2) and (3) had adequately been completed?
John
John Poelstra wrote:
Bryan Kearney said the following on 09/17/2008 05:50 AM Pacific Time:
Does this help?
https://fedoraproject.org/wiki/User:Bkearney/ProposedSpinProcess
Now you're talking my language :)
For each step along the way how are you proposing to track the approval or completion? IOW if I were to help with (4), how would I tell if (2) and (3) had adequately been completed?
Well.. if you want the spin to be in Fedora, then this assumes you do a feature. So.. let the feature tracking process cover it. No need to create a new process. It may break the definition of a feature a bit, since some of them are "repeats" year to year.. but it would create a single funnel for the board and release engineering to look at.
-- bk
Bryan Kearney said the following on 09/22/2008 05:53 AM Pacific Time:
John Poelstra wrote:
Bryan Kearney said the following on 09/17/2008 05:50 AM Pacific Time:
Does this help?
https://fedoraproject.org/wiki/User:Bkearney/ProposedSpinProcess
Now you're talking my language :)
For each step along the way how are you proposing to track the approval or completion? IOW if I were to help with (4), how would I tell if (2) and (3) had adequately been completed?
Well.. if you want the spin to be in Fedora, then this assumes you do a feature. So.. let the feature tracking process cover it. No need to create a new process. It may break the definition of a feature a bit, since some of them are "repeats" year to year.. but it would create a single funnel for the board and release engineering to look at.
-- bk
Fair enough. You still haven't answered my question about tracking approvals.
Stated another way... history has shown with the feature process that people don't always do the right thing. Not in a malicious way, but usually because they didn't understand what they were supposed to or simply took a guess and moved on.
For the feature process I use the very manual, rudimentary process of Category classifications and page watches.
What process are you proposing so that I know: 1) When a spin is officially being proposed as a feature? 2) All of the required previous required steps or approvals were completed correctly?
John
John Poelstra wrote:
What process are you proposing so that I know:
- When a spin is officially being proposed as a feature?
- All of the required previous required steps or approvals were
completed correctly?
There's more to be tracked on a spin even before it even becomes a feature;
- technical review => kickstart pool inclusion
- board trademark approval (which doesn't require a feature page as of yet because it can be the last stage a spin wants to go through; just being able to remove the rebranding stuff from the kickstart in the pool) => fedora spin
- Feature approval => officially composed, released and supported fedora spin
Take into account with any design of any process that the former two stages need to be tracked, too.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen said the following on 09/22/2008 02:29 PM Pacific Time:
John Poelstra wrote:
What process are you proposing so that I know:
- When a spin is officially being proposed as a feature?
- All of the required previous required steps or approvals were
completed correctly?
There's more to be tracked on a spin even before it even becomes a feature;
technical review => kickstart pool inclusion
board trademark approval (which doesn't require a feature page as of
yet because it can be the last stage a spin wants to go through; just being able to remove the rebranding stuff from the kickstart in the pool) => fedora spin
- Feature approval => officially composed, released and supported fedora
spin
Take into account with any design of any process that the former two stages need to be tracked, too.
This is exactly what I have been asking for.
John
John Poelstra wrote:
Jeroen van Meeuwen said the following on 09/22/2008 02:29 PM Pacific Time:
John Poelstra wrote:
What process are you proposing so that I know:
- When a spin is officially being proposed as a feature?
- All of the required previous required steps or approvals were
completed correctly?
There's more to be tracked on a spin even before it even becomes a feature;
technical review => kickstart pool inclusion
board trademark approval (which doesn't require a feature page as of
yet because it can be the last stage a spin wants to go through; just being able to remove the rebranding stuff from the kickstart in the pool) => fedora spin
- Feature approval => officially composed, released and supported
fedora spin
Take into account with any design of any process that the former two stages need to be tracked, too.
This is exactly what I have been asking for.
John
Fair comments...
Can I assume that the technical review and the trademark approval only occur a single time if the SPIN will not be distributed by fedora? If so, then I would suggest that all spins start with a Feature Page _or_ a Spin Page (where the former can replace the latter). This would allow for a signoff to be made and recorded by the wiki. The only other alternative I see would be to move it through bugzilla.. and I would tend to prefer the wiki route since all the content could be added to the feature page.
Thoughts?
-- bk
Bryan Kearney said the following on 09/23/2008 05:48 AM Pacific Time:
John Poelstra wrote:
Jeroen van Meeuwen said the following on 09/22/2008 02:29 PM Pacific Time:
John Poelstra wrote:
What process are you proposing so that I know:
- When a spin is officially being proposed as a feature?
- All of the required previous required steps or approvals were
completed correctly?
There's more to be tracked on a spin even before it even becomes a feature;
technical review => kickstart pool inclusion
board trademark approval (which doesn't require a feature page as
of yet because it can be the last stage a spin wants to go through; just being able to remove the rebranding stuff from the kickstart in the pool) => fedora spin
- Feature approval => officially composed, released and supported
fedora spin
Take into account with any design of any process that the former two stages need to be tracked, too.
This is exactly what I have been asking for.
John
Fair comments...
Can I assume that the technical review and the trademark approval only occur a single time if the SPIN will not be distributed by fedora? If so, then I would suggest that all spins start with a Feature Page _or_ a Spin Page (where the former can replace the latter). This would allow for a signoff to be made and recorded by the wiki. The only other alternative I see would be to move it through bugzilla.. and I would tend to prefer the wiki route since all the content could be added to the feature page.
Thoughts?
-- bk
"please NOT bugzilla" to the thought of tracking in bugzilla :)
I like the wikipage idea a lot and making it dual purpose as you suggest! So to push the idea a little further... you could start with unique page Category names that fall in *before* the Categories we use for the feature process now: https://fedoraproject.org/wiki/Features/Policy/Process
Then a quick look at that the history and page change comments and user making said change could make it clear who has approved.
This would assume that the approval process is serial AND that each approver is relying on the previous approver to have "done the right thing". IOW when a page lands in "FeatureReadyForWrangler" all I would have to do (representing the regular feature process) is make sure there was approval from the {person, entity, group, SIG} directly preceding me. I would NOT go farther back, beyond that, as that defeats the whole chain of trust and efficiency we would seek to gain from it.
John
John Poelstra wrote:
Bryan Kearney said the following on 09/23/2008 05:48 AM Pacific Time:
John Poelstra wrote:
"please NOT bugzilla" to the thought of tracking in bugzilla :)
yaah.. I dont like that one either.
I like the wikipage idea a lot and making it dual purpose as you suggest! So to push the idea a little further... you could start with unique page Category names that fall in *before* the Categories we use for the feature process now: https://fedoraproject.org/wiki/Features/Policy/Process
Cool.. I had not seen that. So yes, we would add 2 items
SIGApproval TrademarkApproval
As Kanarip pointed out, the Trademark and Feature process can be in parallel.
Then a quick look at that the history and page change comments and user making said change could make it clear who has approved.
This would assume that the approval process is serial AND that each approver is relying on the previous approver to have "done the right thing". IOW when a page lands in "FeatureReadyForWrangler" all I would have to do (representing the regular feature process) is make sure there was approval from the {person, entity, group, SIG} directly preceding me. I would NOT go farther back, beyond that, as that defeats the whole chain of trust and efficiency we would seek to gain from it.
Assuming the above names, you would block on SIGApproval, but not on TrademarkAppoval. RelEng would block on both.
-- bk
On Wed, 2008-09-17 at 05:45 -0700, John Poelstra wrote:
It seemed odd to me that all our documentation describes how FESCo "accepts" features that are listed here https://fedoraproject.org/wiki/Releases/10/FeatureList and then to start adding Spins to the same page which go through a similar, but more different process that aren't exactly "accepted" by FESCo, as I understand it. Forgive me if I've made this too complicated :)
Since it's really a delegation from FESCo to rel-eng to handle the spins, they could still be treated as accepted by FESCo, implicit due to the delegation. That should make things easier as far as "where they go" in the wiki.
Jesse Keating said the following on 09/17/2008 08:24 AM Pacific Time:
On Wed, 2008-09-17 at 05:45 -0700, John Poelstra wrote:
It seemed odd to me that all our documentation describes how FESCo "accepts" features that are listed here https://fedoraproject.org/wiki/Releases/10/FeatureList and then to start adding Spins to the same page which go through a similar, but more different process that aren't exactly "accepted" by FESCo, as I understand it. Forgive me if I've made this too complicated :)
Since it's really a delegation from FESCo to rel-eng to handle the spins, they could still be treated as accepted by FESCo, implicit due to the delegation. That should make things easier as far as "where they go" in the wiki.
Fair enough. I think a separate section on that page for spins would be good vs. mixing them in in alpha order with the rest of the features.
So now:
1) Who is keeping track of all the needed approvals? 2) Where and how is the process being tracked? 3) Who will update https://fedoraproject.org/wiki/Releases/10/FeatureList when all approvals have been granted?
John
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
[...]
= fedora-livecd-education-math.ks (Fedora Education Math) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/EducationMathSpin
I thought this was approved: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-aug-11#Spins
Sorry for being that late on this thread... I should have responded earlier - thanks Jesse for pointing to this!
The Education Math Spin seems to build fine in my latest tries on i386 using livecd-creator. The image was around approx. 650 MB, so the i386 build on spinner.fedoraunity.org is okay with me (I'll need to have a look at the log, though). Unfortunately, the x86_64 spin kind of oversized there with its size of 786 MB. I didn't build a x86_64 locally, so I'm not sure how this would be using livecd-tools. Not sure, if we really need i386 *and* x64_64 for the Education Math Spin, though...
--Sebastian
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
This one I have a couple comments on.
First, for the RPM/Fedora specific stuff, the @fedora-packager group should be brought in. It'll bring in most the SCM stuff and koji and all that jazz.
Second, I really don't like the modifying of the debuginfo repo. There are tools like debuginfo-install that will enable debuginfo repos on the fly to get packages, rather than keeping the repo open all the time and dealing with extra repodata churn. Not to mention that it immediately taints the fedora.repo file so that we can't deliver any updates to it. Please reconsider this modification.
I'll still vote to approve this from releng side, as I think that can be discussed/fixed after the beta.
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
This one I have a couple comments on.
First, for the RPM/Fedora specific stuff, the @fedora-packager group should be brought in. It'll bring in most the SCM stuff and koji and all that jazz.
I'm not sure whether it is a conscious choice of the creator/maintainer to not include that group, or whether they just didn't know about it in the first place.
Second, I really don't like the modifying of the debuginfo repo. There are tools like debuginfo-install that will enable debuginfo repos on the fly to get packages, rather than keeping the repo open all the time and dealing with extra repodata churn. Not to mention that it immediately taints the fedora.repo file so that we can't deliver any updates to it. Please reconsider this modification.
Can't seem to find the tool you're referring to. What is it's name exactly?
Jeroen van Meeuwen -kanarip
On Thu, 2008-09-18 at 16:02 +0200, Jeroen van Meeuwen wrote:
I'm not sure whether it is a conscious choice of the creator/maintainer to not include that group, or whether they just didn't know about it in the first place.
That's what reviews and feedback is for, so that the maintainer can either learn about it, or report back rational as to not using it.
Second, I really don't like the modifying of the debuginfo repo. There are tools like debuginfo-install that will enable debuginfo repos on the fly to get packages, rather than keeping the repo open all the time and dealing with extra repodata churn. Not to mention that it immediately taints the fedora.repo file so that we can't deliver any updates to it. Please reconsider this modification.
Can't seem to find the tool you're referring to. What is it's name exactly?
$ rpm -qf /usr/bin/debuginfo-install yum-utils-1.1.16-2.fc10.noarch
Usage: debuginfo-install: Install debuginfo packages and their dependencies based on the name of the non-debug package debuginfo-install [options] package1 [package2] [package..]
Jesse Keating wrote:
Can't seem to find the tool you're referring to. What is it's name exactly?
$ rpm -qf /usr/bin/debuginfo-install yum-utils-1.1.16-2.fc10.noarch
Usage: debuginfo-install: Install debuginfo packages and their dependencies based on the name of the non-debug package debuginfo-install [options] package1 [package2] [package..]
Here I am looking for a yum plugin of some kind that does debuginfo foo when you execute a yum install foo.
-Jeroen
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
- One of the spins that has been approved previously (Fedora 8)
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng. (but does not have the right category
on it's Feature page to show up on Rel. Eng.'s radar, maybe since the feature page existed for Fedora 8 already).
Feature Page: https://fedoraproject.org/wiki/Features/FedoraElectronicLab
There are some ... interesting changes in the %post here too, and comments regarding ignoring comps, to include rhgb, which doesn't exist anymore. This is one of the reasons I question --ignoremissing as it hides things like this leading to bitrot.
I'm going to +1 this, however I'm concerned at the fact that with this, we'd have 3 DVD based spins, which is going to be a rather large amount of data. Definitely need to get a read from Infrastructure as to what our spins budget is this release.
Jesse Keating wrote:
I'm going to +1 this, however I'm concerned at the fact that with this, we'd have 3 DVD based spins, which is going to be a rather large amount of data. Definitely need to get a read from Infrastructure as to what our spins budget is this release.
One of our options includes getting other seeds seeded with our compose and dropping the Fedora Project seed. Is this more feasible?
How about not starting to seed it at all, but just do the tracking -and have others seed it initially, instead? A requirement which can be awesomely difficult to manage is who gets it first and who's responsible afterwards :/
I think we all agree though the tracker should be run by Fedora Project no matter what, and the official compose should happen on Fedora Infra... I mean, that's set and a fact, right?
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, 2008-09-17 at 13:04 +0200, Jeroen van Meeuwen wrote:
One of our options includes getting other seeds seeded with our compose and dropping the Fedora Project seed. Is this more feasible?
It doesn't really help with the initial compose and the bandwidth cost of putting the bits /somewhere/ to be made public.
How about not starting to seed it at all, but just do the tracking -and have others seed it initially, instead? A requirement which can be awesomely difficult to manage is who gets it first and who's responsible afterwards :/
It would still have to sit on our torrent server, and chew up disk space/bandwidth to move it around.
I think we all agree though the tracker should be run by Fedora Project no matter what, and the official compose should happen on Fedora Infra... I mean, that's set and a fact, right?
In my mind, with the way things currently are, yes.
The more I think about it, the more I think we should ask Infrastructure to give us a resource budget, bandwidth/hardware/etc... and we should design the releases' spins accordingly to fit into that budget. rel-eng budget it just man power, and I'm sure I could get some volunteers to make composes happen, so it really comes down to infrastructure to compose/host it all.
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livecd-desktop-default.ks (Fedora Desktop) =
- One of our permanent spins
I just tried to compose this one, and it fails due to trying to include the wrong base config. Please fix in the branch.
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livecd-desktop-default.ks (Fedora Desktop) =
- One of our permanent spins
I just tried to compose this one, and it fails due to trying to include the wrong base config. Please fix in the branch.
My bad, I had removed it from the F-10-Beta branch not taking into account it was included by fedora-livecd-desktop-default.ks. Added it back and pushed.
Kind regards,
Jeroen van Meeuwen -kanarip
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-games.ks (Fedora Games) =
Just tried to do this one, it fails on finding starfighter. Please to be fixing.
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-games.ks (Fedora Games) =
Just tried to do this one, it fails on finding starfighter. Please to be fixing.
This package has been dropped recently. I have dropped this from ks file and increased the partition size as well. Note that, while I am still listed as a maintainer, others have volunteered to take over maintenance of this spin for a while and i have send a mail to fedora-games list asking them to apply for commit access to the git repo.
Rahul
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Just tried this one, and it failed to get very far. From some short investigation, it would seem that the livedvd-el file includes the livecd-kde, which includes livecd-base, which only sets up a very small partition to work with, too small for all the content in EL. EL needs to set a larger partition, like what Developer does.
Was I under the mistaken impression that these were tested before they were tagged?
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Just tried this one, and it failed to get very far. From some short investigation, it would seem that the livedvd-el file includes the livecd-kde, which includes livecd-base, which only sets up a very small partition to work with, too small for all the content in EL. EL needs to set a larger partition, like what Developer does.
Was I under the mistaken impression that these were tested before they were tagged?
I do what I can do at http://spinner.fedoraunity.org/revisor/
I've warned the creators/maintainers about the Beta freeze but apparently they either can't test/fix or they won't test/fix.
This is the second time Release Engineering is handed off garbage and I'm not sure what we as a Spin SIG can do about it other then trying to make the testing an automagic process as far as the composing is concerned.
Otherwise, I assume this is the only other option, we need to tell the creators/maintainers that as soon as you fail to compose a spin, it's dropped.
Kind regards,
Jeroen van Meeuwen -kanarip
On Fri, Sep 19, 2008 at 01:46:31PM +0200, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Just tried this one, and it failed to get very far. From some short investigation, it would seem that the livedvd-el file includes the livecd-kde, which includes livecd-base, which only sets up a very small partition to work with, too small for all the content in EL. EL needs to set a larger partition, like what Developer does.
Was I under the mistaken impression that these were tested before they were tagged?
I do what I can do at http://spinner.fedoraunity.org/revisor/
I've warned the creators/maintainers about the Beta freeze but apparently they either can't test/fix or they won't test/fix.
This is the second time Release Engineering is handed off garbage and I'm not sure what we as a Spin SIG can do about it other then trying to make the testing an automagic process as far as the composing is concerned.
Otherwise, I assume this is the only other option, we need to tell the creators/maintainers that as soon as you fail to compose a spin, it's dropped.
I think for Beta, that is a valid option. Most certainly for RC. For Alpha (in the future at least), we might be a bit more lenient.
josh
Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Just tried this one, and it failed to get very far. From some short investigation, it would seem that the livedvd-el file includes the livecd-kde, which includes livecd-base, which only sets up a very small partition to work with, too small for all the content in EL. EL needs to set a larger partition, like what Developer does.
Was I under the mistaken impression that these were tested before they were tagged?
I do what I can do at http://spinner.fedoraunity.org/revisor/
Do you have a batch revisor to do that?
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Sun, 2008-09-14 at 16:53 +0200, Jeroen van Meeuwen wrote:
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
Just tried this one, and it failed to get very far. From some short investigation, it would seem that the livedvd-el file includes the livecd-kde, which includes livecd-base, which only sets up a very small partition to work with, too small for all the content in EL. EL needs to set a larger partition, like what Developer does.
Was I under the mistaken impression that these were tested before they were tagged?
I do what I can do at http://spinner.fedoraunity.org/revisor/
Do you have a batch revisor to do that?
Actually it's a wrapper bash script that for each branch (f8, f9, rawhide) executes revisor commands for installation and/or live media from the kickstarts available (in the appropriate spin-kickstarts branches), and sends me a mail with the report.
It's on it's way to also report to the kickstart maintainers, and in the end also do jigdofying for installation media, and torrenting for live media.
Kind regards,
Jeroen van Meeuwen -kanarip