The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
With help of several key people in the current Spins process, including Process-Guru and current Feature Wrangler John Poelstra, we've come up with a real Spins Process during this last FUDCon.
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Finalizing Spins Process[1], vote #* Writing up details on the Wiki, where necessary #* Writing our Spins_SIG_Review_Checklist, and what to do if something isn't covered #* Maintainer responsiveness and responsibilities for current releases #* Checklist of DOs and DONTs, SHOULDs and SHOULD NOTs[2] #* Defining permanent vs. non-permanent spins, the procedure to change status, and the consequences for the Spins Process. # Set our final meeting time and schedule, vote # Determine our workflow (using the spin-kickstarts Trac instance?) #* Branching and tagging (based on milestones to be determined) #* Creating daily spins for compose tests and reporting results #* Having maintainers (re-)create spins regularly for tests and collecting results # Determine our process for recurring releases and reviewing current spins for the upcoming release # Current Spins Requests: #* Games Spin #** Has been previously approved #** Failed during Fedora 10 #** Revamped for Fedora 11 by Bruno Wolff III #* A dozen or so localized spins #** http://sundaram.fedorapeople.org/spins/ # Review of all current spins #* Who's the maintainer of each spin, and where can we reach them? #* Fedora AOS #* Fedora BrOffice.org #* Fedora Developer #* Fedora Education Math #* Fedora Electronic Lab #* Fedora Games #* Fedora Sugar #* Fedora XFCE
This agenda is also available (in a more readable format) on:
https://fedoraproject.org/wiki/Spins_SIG_Meeting_2009-01-19
Additional Agenda items you may have can go to that Wiki page as well.
Again, if you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend also. In the new process, the Spins SIG meetings are where you can say "no" or "yes" to a spin, or raise concerns. I would like to know if you agree with that. Also, I'd like to know if you (or a delegate of your team) wants to attend our meetings, or settles with being notified by the Spins SIG every step of the way.
Now, in my Agenda, the time for our first meeting would already conflict with a very important appointment I have with Max next week -which I'm not going to reschedule, it includes dinner :P I'll make it work one way or the other, though, so there'll definitely be a meeting at January 19th, 18:00 UTC. Be there or forever hold your peace ;-)
Thank you,
Kind regards,
Jeroen van Meeuwen -kanarip
[1] http://fedoraproject.org/wiki/Spins_Process [2] http://fedoraproject.org/wiki/Spins_Guidelines
On Wed, Jan 14, 2009 at 13:26:14 +0100, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Current Spins Requests: #* Games Spin #** Has been previously approved #** Failed during Fedora 10 #** Revamped for Fedora 11 by Bruno Wolff III
I should be able to attend on Monday. For the games spin, there is still the issue of going over 4 GiB. There are two parts to this. One is whether the iso image being over 4 GiB is likely to have a significant impact on usability to the extent it shouldn't be done. The other is whether rel-eng is comfortable with a version of livecd-tools that can switch to udf when the squashfs file system image is over 4 GiB. Jeremy and I have been going back and forth a bit with patches. As of right now the git version doesn't work, but a previous version did. The iso image is currently about 160 MB over 4 GiB.
Bruno Wolff III wrote:
On Wed, Jan 14, 2009 at 13:26:14 +0100, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Current Spins Requests: #* Games Spin #** Has been previously approved #** Failed during Fedora 10 #** Revamped for Fedora 11 by Bruno Wolff III
I should be able to attend on Monday. For the games spin, there is still the issue of going over 4 GiB. There are two parts to this. One is whether the iso image being over 4 GiB is likely to have a significant impact on usability to the extent it shouldn't be done. The other is whether rel-eng is comfortable with a version of livecd-tools that can switch to udf when the squashfs file system image is over 4 GiB. Jeremy and I have been going back and forth a bit with patches. As of right now the git version doesn't work, but a previous version did. The iso image is currently about 160 MB over 4 GiB.
From my opinion, we shouldn't go past the 4GiB magic boundary as far as the official Fedora Project releases are concerned, even though we can (once the patch to livecd-tools works). Maybe we should take this up for a vote, and maybe if we vote positively we need to take it up with FESCo see what they think. Or we take it up with FESCo right-away, I don't know.
Having the patch in livecd-tools though, as far as I'm concerned, helps downstream consumers that choose to go oversized, so the effort should definitely continue ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, Jan 14, 2009 at 15:57:05 +0100, Jeroen van Meeuwen kanarip@kanarip.com wrote:
From my opinion, we shouldn't go past the 4GiB magic boundary as far as the official Fedora Project releases are concerned, even though we can (once the patch to livecd-tools works). Maybe we should take this up for a vote, and maybe if we vote positively we need to take it up with FESCo see what they think. Or we take it up with FESCo right-away, I don't know.
Unfortunately the ordering of meetings is wrong. The last FESCO meeting before the freeze is this Friday which is before your meeting. It might be worth running it by them to see if they will defer to the Spins SIG or if they have their own opinion. There is also the option to try it tentatively for the alpha and gather feedback. I was planning on being available for the FESCO meeting, if you want I can add this topic to the agenda?
Jeroen van Meeuwen (kanarip@kanarip.com) said:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
...
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
releng meetings are Mondays, 18:00 UTC already. See http://fedoraproject.org/wiki/ReleaseEngineering
Bill
Bill Nottingham wrote:
Jeroen van Meeuwen (kanarip@kanarip.com) said:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
...
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
releng meetings are Mondays, 18:00 UTC already. See http://fedoraproject.org/wiki/ReleaseEngineering
https://fedoraproject.org/wiki/Meeting_channel#Time_table has the Release Engineering meetings listed at 17:00 UTC.
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, 2009-01-14 at 23:29 +0100, Jeroen van Meeuwen wrote:
https://fedoraproject.org/wiki/Meeting_channel#Time_table has the Release Engineering meetings listed at 17:00 UTC.
Probably because one of us forgot to edit the table for the DST change recently. Can the spins trade us, or move an hour after us? We float back and forth between 1800 and 1700 depending on DST, keeping with 1pm Eastern US time.
On Wed, 2009-01-14 at 23:29 +0100, Jeroen van Meeuwen wrote:
Bill Nottingham wrote:
Jeroen van Meeuwen (kanarip@kanarip.com) said:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
...
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
releng meetings are Mondays, 18:00 UTC already. See http://fedoraproject.org/wiki/ReleaseEngineering
https://fedoraproject.org/wiki/Meeting_channel#Time_table has the Release Engineering meetings listed at 17:00 UTC.
Probably because one of us forgot to edit the table for the DST change recently. Can the spins trade us, or move an hour after us? We float back and forth between 1800 and 1700 depending on DST, keeping with 1pm Eastern US time.
Due to a conflict with the Release Engineering Meeting, we'll move the meetings to 17:00 UTC, instead of 18:00 UTC.
Sorry for the inconvenience.
Kind regards,
Jeroen van Meeuwen
Jesse Keating wrote:
On Wed, 2009-01-14 at 23:29 +0100, Jeroen van Meeuwen wrote:
Bill Nottingham wrote:
Jeroen van Meeuwen (kanarip@kanarip.com) said:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
...
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
releng meetings are Mondays, 18:00 UTC already. See http://fedoraproject.org/wiki/ReleaseEngineering
https://fedoraproject.org/wiki/Meeting_channel#Time_table has the Release Engineering meetings listed at 17:00 UTC.
Probably because one of us forgot to edit the table for the DST change recently. Can the spins trade us, or move an hour after us? We float back and forth between 1800 and 1700 depending on DST, keeping with 1pm Eastern US time.
On Thu, 2009-01-15 at 08:21 +0100, Jeroen van Meeuwen wrote:
Due to a conflict with the Release Engineering Meeting, we'll move the meetings to 17:00 UTC, instead of 18:00 UTC.
Thanks for being flexible Jeroen.
Sorry for the inconvenience.
I'm sorry we forgot to edit the schedule page in the first place causing this mess.
Jeroen van Meeuwen wrote:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
With help of several key people in the current Spins process, including Process-Guru and current Feature Wrangler John Poelstra, we've come up with a real Spins Process during this last FUDCon.
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Finalizing Spins Process[1], vote
May I suggest part of this discussion is spin versus feature. I ask becuase the process (for me) got hairy when combined with the feature process.
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
With help of several key people in the current Spins process, including Process-Guru and current Feature Wrangler John Poelstra, we've come up with a real Spins Process during this last FUDCon.
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Finalizing Spins Process[1], vote
May I suggest part of this discussion is spin versus feature. I ask becuase the process (for me) got hairy when combined with the feature process.
-- bk
Hopefully we cleared this part up at Friday's hackfest discussion. Now there are:
1) Spins for a particular release 2) Features for a particular release
o #1 and #2 are NOT the same thing. o #2 already has a formal process--parts of it have been borrowed to create a *separate* process for #1 o I am the wrangler for #2. I'm leaning in the direction of volunteering to be the wrangler for #1
We should have some wiki pages and diagrams explaining the proposed spins process soon.
Bryan--we looked at your design on the wiki as part of our discussions.
John
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
With help of several key people in the current Spins process, including Process-Guru and current Feature Wrangler John Poelstra, we've come up with a real Spins Process during this last FUDCon.
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Finalizing Spins Process[1], vote
May I suggest part of this discussion is spin versus feature. I ask becuase the process (for me) got hairy when combined with the feature process.
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Such decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well.
The problem with this whole process is not FESCo didn't want the spins to be considered features but how it has been not been delegated properly and who is responsible for the final decisions is still unclear. Ideally, FESCo would have still considered spins as features so that spin maintainers have a procedure to follow up until the time, alternative procedure and a owner/team responsible for the final decision is outlined somewhere.
I am not sure what to do for the Xfce spin or the local language spins now. Anyone want to clarify this?
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Such decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well.
I'm sorry if I hurt your feelings by abusing FUDCon like this (in your opinion), but let me tell you I'll do it again whenever I feel like it.
Everyone involved was there, everyone agreed. This process is set. Arguments go to the list. Voting happens next week during the SIG meeting.
If you have a problem with that, please state it. Please be precise in what you think we've done so tremendously wrong, that our ability to make a decision, gather input and then have a vote on the result deserves to be questioned, by you no less.
because although I do understand your argument against deciding stuff at FUDCon, I do not understand what is your problem with how things are moving forward right now.
The problem with this whole process is not FESCo didn't want the spins to be considered features but how it has been not been delegated properly and who is responsible for the final decisions is still unclear. Ideally, FESCo would have still considered spins as features so that spin maintainers have a procedure to follow up until the time, alternative procedure and a owner/team responsible for the final decision is outlined somewhere.
- Define "this" in "The problem with this whole process", because I don't understand which process you are referring to.
- Explain to me how "The Spin SIG for technical approval and the Board for a rubber trademark stamp" leaves you inconclusive about who has the final verdict on whether a Spin can be a Spin or not.
- Explain to me what you mean by "Ideally, FESCo would have still considered spins as features" because Spins being Features yet not being Features was one of the hurdles we needed to overcome by setting up a new process.
I am not sure what to do for the Xfce spin or the local language spins now. Anyone want to clarify this?
In case you haven't noticed, they are on the agenda. I can already say that a Spin Page will need to be created (but not for the Localized Spins), or a current page needs to be relocated or possibly re-categorized. In any way, this is why these items are on the agenda; to establish what needs to happen (to what spin), and to determine who's going to take care of that (spin maintainers? SIG?).
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Such decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well.
I'm sorry if I hurt your feelings by abusing FUDCon like this (in your opinion), but let me tell you I'll do it again whenever I feel like it.
Please don't put words in my mouth. I never said you were abusing FUDCon. It is a general principle to be inclusive of everyone in the community as much as possible. That means, not making decisions in a place where many people just cannot attend to state their arguments or present alternative view points.
Everyone involved was there, everyone agreed. This process is set.
Sorry. no. Not everyone involved was there and unlikely to ever be. There are many spin maintainers and spin SIG members not present at FUDCon.
Arguments go to the list. Voting happens next week during the SIG meeting.
If you have a problem with that, please state it. Please be precise in what you think we've done so tremendously wrong, that our ability to make a decision, gather input and then have a vote on the result deserves to be questioned, by you no less.
because although I do understand your argument against deciding stuff at FUDCon, I do not understand what is your problem with how things are moving forward right now.
A bunch of people went ahead and made some decisions in FUDCon and when others raises their concern over that decision and decision making process, you are being unnecessarily abrasive and dismissive about it.
I don't want decisions being made without being communicated at all in some random location in the world. If you make a decision, do it over mailing lists or on less preferably on irc ( after announcing ahead of time) where people involved or concerned can present their opinions. FUDCon should be just for discussions.
The problem with this whole process is not FESCo didn't want the spins to be considered features but how it has been not been delegated properly and who is responsible for the final decisions is still unclear. Ideally, FESCo would have still considered spins as features so that spin maintainers have a procedure to follow up until the time, alternative procedure and a owner/team responsible for the final decision is outlined somewhere.
- Define "this" in "The problem with this whole process", because I
don't understand which process you are referring to.
The spins process or lack of clarity in one.
- Explain to me how "The Spin SIG for technical approval and the Board
for a rubber trademark stamp" leaves you inconclusive about who has the final verdict on whether a Spin can be a Spin or not.
I am sure, you are aware of the prior discussions on this topic. How many spin SIG meetings have there been and which spins have been approved there? In the last release, Xfce and Games spin was approved in a rel-eng meeting, fyi. I have explained another problem I ran into at
https://www.redhat.com/archives/fedora-advisory-board/2008-December/msg00054...
- Explain to me what you mean by "Ideally, FESCo would have still
considered spins as features" because Spins being Features yet not being Features was one of the hurdles we needed to overcome by setting up a new process.
You are forgetting a bit of history here. Spins were considered as features before FESCo voted against it.
http://fedoraproject.org/wiki/Releases/8/FeatureList
See the electronics lab as a feature in there?
Rahul
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
I'm done arguing with you. Either comment on the process before the vote on Monday or forever hold your peace.
Which process are you referring to now? I have commented on the spins process extensively in here (I originally outlined a proposal on board's request as the person having creating the first official spins) and elsewhere as well before but it appears you have already made up your mind in FUDCon and don't want any input.
As far as I am concerned, spin = feature worked just fine before FESCo decided to vote against that, leaving it in limbo. For Fedora 9 and Fedora 10, there has been a lot of confusion over what should be done.
For Fedora 10, I went to rel-eng just so that some decisions can be made. For Fedora 11, the process outlined doesn't have enough details (just as an example: what should a report contain? how often would there be a spin sig meeting. Can I vote for my own spins as a spin sig member? Is everyone who signs up as a spin sig member by merely editing the wiki get to vote?). The process has now been made more cumbersome by mandating by weekly composes and reports (who decided on that?). Instead of helping spin maintainers, this process seems to be making it more difficult. It is too soon to be voting on this and time isn't suitable for me to attend. Let's discuss it first on mailing list.
Rahul
On Thu, Jan 15, 2009 at 06:53:48PM +0530, Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
I'm done arguing with you. Either comment on the process before the vote on Monday or forever hold your peace.
Which process are you referring to now? I have commented on the spins process extensively in here (I originally outlined a proposal on board's request as the person having creating the first official spins) and elsewhere as well before but it appears you have already made up your mind in FUDCon and don't want any input.
As far as I am concerned, spin = feature worked just fine before FESCo decided to vote against that, leaving it in limbo. For Fedora 9 and Fedora 10, there has been a lot of confusion over what should be done.
Here's the deal. Spins have a process that are treated exactly like Features. Just because it's not under the purview of FESCo doesn't mean that it's not still viable.
For Fedora 10, I went to rel-eng just so that some decisions can be made.
So you are allowed to make arbitrary decisions in a closed group, but those that did the exact same thing at FUDCon are somehow evil? Wtf.
For Fedora 11, the process outlined doesn't have enough details
OK, now this is the part where you are actually being helpful.
(just as an example: what should a report contain?
I'm not entirely clear myself here.
how often would there be a spin sig meeting.
Every other week, in the same time-slot as the EPEL meeting.
Can I vote for my own spins as a spin sig member?
Yes.
Is everyone who signs up as a spin sig member by merely editing the wiki get to vote?).
Dunno. And sort of inconsiquential, given that "gaming the system" isn't exactly wrong or right either way.
The process has now been made more cumbersome by mandating by weekly composes and reports (who decided on that?).
That one came from me. Having spins fail to compose during the week that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the door is simply an easy way to drop the Spin entirely.
It's not more cumbersome. It's putting the responsibility for the spin into the hands of the person that cares about it the most, which is the spin owner. So the week before a milestone release is going to be busy for the SIG and the owners, but that is part of being a Spin owner.
of helping spin maintainers, this process seems to be making it more difficult. It is too soon to be voting on this and time isn't suitable for me to attend. Let's discuss it first on mailing list.
More difficult in areas, yes. It does help the owners with the process itself though, since they don't have to play "who do I ask next for approval" on getting the spin itself actually accepted.
Look, creating an official Spin is not as simple as "here is my kickstart file, go build this please." If the owners really want the Spin to succeed and be released with the rest of the releases that are done, it needs to at least have some of the same criteria as those. If that is too cumbersome or time consuming for someone to do, then they can use a Remix and do it on their own schedule.
The bar has been raised, and this is not a bad thing.
josh
Josh Boyer wrote:
Here's the deal. Spins have a process that are treated exactly like Features. Just because it's not under the purview of FESCo doesn't mean that it's not still viable.
It would be still viable if the process is outlined. The process has to be in discussed and in place before FESCo delegates it to somebody else. After Fedora 8, FESCo essentially said, we don't want to deal with this and it has been a mass confusion ever since.
For Fedora 10, I went to rel-eng just so that some decisions can be made.
So you are allowed to make arbitrary decisions in a closed group, but those that did the exact same thing at FUDCon are somehow evil? Wtf.
A clearly outlined process and someone or a team needs to be accountable for decisions. In the absence of it and confusion over the process, I had to deal with somehow getting the spins I owned published (there weren't enough spin sig meetings and I can't be sitting on much if any because of different timezones) and asked for help in #fedora-devel and was told that rel-eng would approve spins and I participate in the meeting and got it approved. None of this was arbitrary or closed. I don't see how it compares at all to making decisions in FUDCon and claiming everyone was there.
That one came from me. Having spins fail to compose during the week that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the door is simply an easy way to drop the Spin entirely.
It's not more cumbersome. It's putting the responsibility for the spin into the hands of the person that cares about it the most, which is the spin owner. So the week before a milestone release is going to be busy for the SIG and the owners, but that is part of being a Spin owner.
I don't know what you want from a report and full fledged testing and reporting every two weeks is just not feasible for multiple spins for me as a spin owner. If you want just to know if it composes or not or if it is the right size and things like that, automated composes already give that information. Don't ask me to vote on this incomplete proposal. Please hash out the details in this list first and then get to the voting part. Premature voting would leave us with just as much confusion as before.
Look, creating an official Spin is not as simple as "here is my kickstart file, go build this please."
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins? You can't be serious. This feels more like a punishment that I have to suffer because other spins broke.
The bar has been raised, and this is not a bad thing.
Yes, as long as you dont arbitrarily the raise the amount of work someone has to do without any justification and not helping them in the process. I was once getting blamed for a Xfce spin compose that failed because Fedora infrastructure was running a updated (slightly broken) version of livecd-tools than the GA version. How about giving me access, so that I can do composes in the same environment that you do? Help me with this instead of just adding more overhead.
Rahul
On Thu, Jan 15, 2009 at 07:58:59PM +0530, Rahul Sundaram wrote:
That one came from me. Having spins fail to compose during the week that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the door is simply an easy way to drop the Spin entirely.
It's not more cumbersome. It's putting the responsibility for the spin into the hands of the person that cares about it the most, which is the spin owner. So the week before a milestone release is going to be busy for the SIG and the owners, but that is part of being a Spin owner.
I don't know what you want from a report and full fledged testing and reporting every two weeks is just not feasible for multiple spins for me as a spin owner. If you want just to know if it composes or not or if it is the right size and things like that, automated composes already give that information. Don't ask me to vote on this incomplete proposal. Please hash out the details in this list first and then get to the voting part. Premature voting would leave us with just as much confusion as before.
Look, creating an official Spin is not as simple as "here is my kickstart file, go build this please."
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins? You can't be serious. This feels more like a punishment that I have to suffer because other spins broke.
I'm asking that the spins owners don't show up on release day with broken spins for rel-eng to compose. I'm asking them to make sure their spin boots and isn't DOA when users download it. I'm asking them to make sure the items (or *gasp* features) that make their spin unique actually work when you boot the spin.
Rawhide is a moving target. Everyone knows this. Everyone also knows that stuff gets shoved into it at the last minute before a freeze date (which is a separate problem that needs solving, but is the truth). So, if you can accomplish the above requirements without doing composes and testing every two weeks, then we can discuss that. The track record thus far has not been wonderful (and no, that is not a statement about your specific spins).
The bar has been raised, and this is not a bad thing.
Yes, as long as you dont arbitrarily the raise the amount of work someone has to do without any justification and not helping them in the process. I was once getting blamed for a Xfce spin compose that failed because Fedora infrastructure was running a updated (slightly broken) version of livecd-tools than the GA version. How about giving me access, so that I can do composes in the same environment that you do? Help me with this instead of just adding more overhead.
We did talk about having compose boxes available for the Spins SIG to use. That really has nothing to do with the process itself though, and is really not a requirement.
There are certainly things that could be done to make this at least more efficient from a technical standpoint for the spins owners. But those things are going to have to show up over time. And if it's too much work in the meantime, do a Remix.
josh
Josh Boyer wrote:
I'm asking that the spins owners don't show up on release day with broken spins for rel-eng to compose. I'm asking them to make sure their spin boots and isn't DOA when users download it. I'm asking them to make sure the items (or *gasp* features) that make their spin unique actually work when you boot the spin.
I am already doing all this and I don't see the benefit in mandating biweekly composes and reporting when you don't even know what you want from the report.
Rahul
On Thu, Jan 15, 2009 at 08:57:18PM +0530, Rahul Sundaram wrote:
Josh Boyer wrote:
I'm asking that the spins owners don't show up on release day with broken spins for rel-eng to compose. I'm asking them to make sure their spin boots and isn't DOA when users download it. I'm asking them to make sure the items (or *gasp* features) that make their spin unique actually work when you boot the spin.
I am already doing all this and I don't see the benefit in mandating biweekly composes and reporting when you don't even know what you want from the report.
Hey, here's a hint. The Spins SIG, Spins process, and the world in general is not about you.
Glad you're doing it already. Once we figure out what to report, it should be easy for you to fill in the template.
I'm pretty much done with this conversation now.
josh
Josh Boyer wrote:
Hey, here's a hint. The Spins SIG, Spins process, and the world in general is not about you.
No but I am involved and present in all of it. So please consider my input instead of side stepping my concerns.
Glad you're doing it already. Once we figure out what to report, it should be easy for you to fill in the template.
I will wait for that. Please discuss that in this list instead of on IRC.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins?
In many respects, yes. Because otherwise it falls to the 'base' rel-eng and QA to constantly do that work, and that doesn't scale. If people want their own custom spins, they do have to put some skin in the game.
It's not really adding anything to the amount of work that needs to be done, in total. It's just shifting around who it gets done by and when.
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins?
In many respects, yes. Because otherwise it falls to the 'base' rel-eng and QA to constantly do that work, and that doesn't scale. If people want their own custom spins, they do have to put some skin in the game.
It's not really adding anything to the amount of work that needs to be done, in total. It's just shifting around who it gets done by and when.
QA hasn't been involved in custom spins ever to my knowledge. I haven't received any input from them ever. So let's leave QA out. In rel-eng, the only person involved on a regular interval is Jesse Keating (and Josh Boyer has helped as well) has sometimes run into issues and there hasn't been any major problem that I haven't responded to on time but doing composes and full fledged testing and reports every two weeks for all the different spins throughout rawhide development just isn't feasible. Automate more of this process via daily composes and automated tests and I can fill in the gaps that require manual supervision. I am already doing composes on my own and testing to the extend I can. There really isn't any room for me to do more.
Rahul
On Thu, Jan 15, 2009 at 19:58:59 +0530, Rahul Sundaram sundaram@fedoraproject.org wrote:
Yes, as long as you dont arbitrarily the raise the amount of work someone has to do without any justification and not helping them in the process. I was once getting blamed for a Xfce spin compose that failed because Fedora infrastructure was running a updated (slightly broken) version of livecd-tools than the GA version. How about giving me access, so that I can do composes in the same environment that you do? Help me with this instead of just adding more overhead.
The code for the git archive of livecd-tools is public. I have already been testing the git version of livecd-tools without special access.
Bruno Wolff III wrote:
On Thu, Jan 15, 2009 at 19:58:59 +0530, Rahul Sundaram sundaram@fedoraproject.org wrote:
Yes, as long as you dont arbitrarily the raise the amount of work someone has to do without any justification and not helping them in the process. I was once getting blamed for a Xfce spin compose that failed because Fedora infrastructure was running a updated (slightly broken) version of livecd-tools than the GA version. How about giving me access, so that I can do composes in the same environment that you do? Help me with this instead of just adding more overhead.
The code for the git archive of livecd-tools is public. I have already been testing the git version of livecd-tools without special access.
Err, I do own livecd-tools in EPEL so I am fully aware of that. That wasn't what I was talking about however. I think Josh Boyer understands the issue better. Essentially, the environment that spin maintainers do composes on should be exactly the same as the one the final composes are being made. Any minor change can cause issues which we cant easily reproduce.
Rahul
Rahul Sundaram wrote:
Josh Boyer wrote:
Look, creating an official Spin is not as simple as "here is my kickstart file, go build this please."
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins? You can't be serious. This feels more like a punishment that I have to suffer because other spins broke.
You can't be serious if you're expecting the limited number of Spins SIG members or Release Engineering members to do that work for you, and numerous other spins as well.
FWIW though, we have not defined what a spins report should look like yet. Maybe, just maybe, you have some vague idea of what should be in there?
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
You can't be serious if you're expecting the limited number of Spins SIG members or Release Engineering members to do that work for you, and numerous other spins as well.
Spin SIG members are already doing it since many of them are spin owners as well but leaving that side, to the extend, there is a need for a bi-weekly compose, the first thing to be considered, is what parts can be automated so that we can make more efficient use of our limited time, collectively.
FWIW though, we have not defined what a spins report should look like yet. Maybe, just maybe, you have some vague idea of what should be in there?
I wasn't the one who came up with the report idea and I am still not clear, why one is needed in the first place. Tell me what was discussed in FUDCon by posting a meeting summary of who attended and what was discussed and I will tell you what the report can contain. Currently, I don't have enough information provided to give any further input.
Rahul
Rahul Sundaram wrote:
Josh Boyer wrote:
Look, creating an official Spin is not as simple as "here is my kickstart file, go build this please."
No, it is not. I have to spend a lot of time, getting that kickstart file in place first. It isn't a simple matter of running some composes and calling it a day. There is a heck lot of finicky details to take care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. You know the amount of work it takes to get alpha,beta and general releases out. Are you really asking me to do that work every two weeks for multiple spins? You can't be serious. This feels more like a punishment that I have to suffer because other spins broke.
You can't be serious if you're expecting the limited number of Spins SIG members or Release Engineering members to do that work for you, and numerous other spins as well.
FWIW though, we have not defined what a spins report should look like yet. Maybe, just maybe, you have some vague idea of what should be in there?
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, Jan 15, 2009 at 16:38:20 +0100, Jeroen van Meeuwen kanarip@kanarip.com wrote:
FWIW though, we have not defined what a spins report should look like yet. Maybe, just maybe, you have some vague idea of what should be in there?
I have found that looking at the install (done as part of the spin build) process shows up missing requires for pre and post (un)install scripts that are easy to miss when testing on a system where the base stuff is already installed. Some of these errors are really just noise, others cause breakage. It would be nice if the installs were totally clean of error or warning messages.
I have also found that it is possible for a dependency problem to block the build entirely.
On Thu, Jan 15, 2009 at 08:56:58 -0500, Josh Boyer jwboyer@gmail.com wrote:
That one came from me. Having spins fail to compose during the week that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the door is simply an easy way to drop the Spin entirely.
Note that the spin maintainer can't directly fix this in some cases. I still have open bugzillas and several packages that don't install cleanly because of missing requires. I can't fix them myself. I can't prevent someone from introducing dependency issues (as happened briefly for the poker2d update) at the wrong time. All I can do is file bugs and in extreme cases as for help on the devel list for another maintainer to help out.
Bruno Wolff III wrote:
On Thu, Jan 15, 2009 at 08:56:58 -0500, Josh Boyer jwboyer@gmail.com wrote:
That one came from me. Having spins fail to compose during the week that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the door is simply an easy way to drop the Spin entirely.
Note that the spin maintainer can't directly fix this in some cases. I still have open bugzillas and several packages that don't install cleanly because of missing requires. I can't fix them myself. I can't prevent someone from introducing dependency issues (as happened briefly for the poker2d update) at the wrong time. All I can do is file bugs and in extreme cases as for help on the devel list for another maintainer to help out.
In the new spins process, we take those "dependencies" as we call them into account -somewhat;
you can list whatever dependencies you have in a separate sort-of topic on a Spins page similar to a Feature page, which is then used similar to how a Feature page is then used;
whether it be packages that still need to be reviewed, general bugs, features that need to be completed, you name it. Anything that stops the spin from being all fine can go there so that everyone knows.
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, Jan 15, 2009 at 16:46:07 +0100, Jeroen van Meeuwen kanarip@kanarip.com wrote:
you can list whatever dependencies you have in a separate sort-of topic on a Spins page similar to a Feature page, which is then used similar to how a Feature page is then used;
I have been linking to bugs on my revamped games spin feature page. I don't know that it helps get them taken care of though.
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote: I'm done arguing with you. Either comment on the process before the vote on Monday or forever hold your peace.
Which process are you referring to now?
I think this is a good time for you to start reading the agenda.
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote: I'm done arguing with you. Either comment on the process before the vote on Monday or forever hold your peace.
Which process are you referring to now?
I think this is a good time for you to start reading the agenda.
Please stop being dismissive and read the rest of mails where I gave you more input.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote: I'm done arguing with you. Either comment on the process before the vote on Monday or forever hold your peace.
Which process are you referring to now?
I think this is a good time for you to start reading the agenda.
Please stop being dismissive and read the rest of mails where I gave you more input.
Reviewing what you've written so far;
- not at FUDCon
I've told you I'm sorry, give it a rest already.
- "It's general principle to be inclusive of everyone in the community as much as possible"
Wasting my time typing this email is a little more inclusive then I'd like to see.
- "I've commented on the spins process extensively"
And how do you think your comments are not in the new process we've come up with during FUDCon?
- "what should a report contain?"
I'm not sure yet, have any ideas? This has settled down just under 3 days, and it hasn't even been voted upon yet. Do you want all the details now? You sure? Because that would make it more permanent and less flexible then the state it's in now (still open for suggestions).
- you're confused on what process it is we're talking about
Suggested solution: read the Spins_Process page on the Wiki
- you're looking for what the process was and how we streamlined it
Suggested solution: read the Spins_Process page on the Wiki
- you're eager to know what needs to be done for XFCE and other spins you submitted
Suggested solution: Await what the Spins SIG comes up with after the meeting, since this item is on the agenda
- you have an opinion about Spins being Spins vs. Features
Suggested solution: weight that argument in your vote for the new process
- """It would be still viable if the process is outlined. The process has to be in discussed and in place before FESCo delegates it to somebody else."""
1) The process is outlined 2) the process has been discussed, with representatives of Rel-eng, our dear Feature Wrangler, the Spins SIG leader, a few spin-submitting/maintaining users, a FESCo delegate, and reviewed afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the first place is the party to whom FESCo delegated responsibility.
I could continue but I don't feel like it. I sure hope this email sounds dismissive enough for you to finally stop arguing over nothing and continue the part of the thread where I think you may have actually said something useful.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
- not at FUDCon
I've told you I'm sorry, give it a rest already.
The problem is not me or others being in FUDCon or not but decisions being made there which will always exclude people. Ours a global community and the ability to attend conferences in a particular place anywhere in the world is limited. You said you will do it again which seemed to be that you didn't understand the issue. It is nothing personal.
And how do you think your comments are not in the new process we've come up with during FUDCon?
It is not since I wasn't in FUDCon.
- "what should a report contain?"
I'm not sure yet, have any ideas? This has settled down just under 3 days, and it hasn't even been voted upon yet. Do you want all the details now? You sure? Because that would make it more permanent and less flexible then the state it's in now (still open for suggestions).
Here is what I suggest:
* Postpone the IRC meeting and voting now. It is too early and there has not been enough details to warrant a vote yet.
* Post a summary of what was discussed in FUDCon and the new proposal discussed in the FUDCon. Communicate as much details as possible so that spin owners can understand why the changes were made and ask for input in this list and not on a IRC meeting. Wait for a week or two so that we can discuss it further and then maybe arrange a IRC meeting.
- you're confused on what process it is we're talking about
Suggested solution: read the Spins_Process page on the Wiki
- you're looking for what the process was and how we streamlined it
Suggested solution: read the Spins_Process page on the Wiki
I already did. You would know that if you had read my mails since I was specific and pointed out a few examples where there aren't enough details.
- you're eager to know what needs to be done for XFCE and other spins
you submitted
Suggested solution: Await what the Spins SIG comes up with after the meeting, since this item is on the agenda
Since I am part of Spin SIG, I am giving my feedback to try and steer the decision in the right direction.
- you have an opinion about Spins being Spins vs. Features
Suggested solution: weight that argument in your vote for the new process
I can't be in the IRC meeting and I don't think voting without details in the right way to do it. I am explaining it in the list so you can consider it while making the decision.
- """It would be still viable if the process is outlined. The process
has to be in discussed and in place before FESCo delegates it to somebody else."""
- The process is outlined
- the process has been discussed, with representatives of Rel-eng, our
dear Feature Wrangler, the Spins SIG leader, a few spin-submitting/maintaining users, a FESCo delegate, and reviewed afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the first place is the party to whom FESCo delegated responsibility.
I don't know what was discussed since a summary wasn't posted in this list. Filling in the details would be helpful.
I could continue but I don't feel like it. I sure hope this email sounds dismissive enough for you to finally stop arguing over nothing and continue the part of the thread where I think you may have actually said something useful.
If you don't feel I have said anything useful so far, I am sorry to hear that but then, we have nothing more to discuss. Carry on with your meeting and I will deal with the result when it comes to that point. Thanks.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
And how do you think your comments are not in the new process we've come up with during FUDCon?
It is not since I wasn't in FUDCon.
You make it sound so logic, I can only agree with you. You're right. I hadn't read anything, I can't remember anything, let alone keep in mind what everyone's ideas, comments and recommendations were and shape them into the skeleton (read: *THE SKELETON*) of a new process. I'm definitely a fail.
- "what should a report contain?"
I'm not sure yet, have any ideas? This has settled down just under 3 days, and it hasn't even been voted upon yet. Do you want all the details now? You sure? Because that would make it more permanent and less flexible then the state it's in now (still open for suggestions).
Here is what I suggest:
- Postpone the IRC meeting and voting now. It is too early and there has
not been enough details to warrant a vote yet.
NO! Period. Exclamation-mark. Fullstop. Why not? Because our next meeting would be only ~2 weeks prior to Beta freeze. Don't recall the timeline exactly, don't care enough to look it up for you.
- Post a summary of what was discussed in FUDCon and the new proposal
discussed in the FUDCon. Communicate as much details as possible so that spin owners can understand why the changes were made and ask for input in this list and not on a IRC meeting. Wait for a week or two so that we can discuss it further and then maybe arrange a IRC meeting.
I did ask for feedback on the list, so that the IRC meeting would only have the vote. So, here's a couple of suggestions for you:
- stop - step away from the keyboard - think of a couple of questions to which the answers may be valuable in moving us forward. - post those questions on the list
- you're confused on what process it is we're talking about
Suggested solution: read the Spins_Process page on the Wiki
- you're looking for what the process was and how we streamlined it
Suggested solution: read the Spins_Process page on the Wiki
I already did. You would know that if you had read my mails since I was specific and pointed out a few examples where there aren't enough details.
Obviously, I haven't read the rest of your email, doh! I'm obviously responding to things I don't read?
- you're eager to know what needs to be done for XFCE and other spins
you submitted
Suggested solution: Await what the Spins SIG comes up with after the meeting, since this item is on the agenda
Since I am part of Spin SIG, I am giving my feedback to try and steer the decision in the right direction.
I think you're confusing blunt criticism with constructive commentary.
- you have an opinion about Spins being Spins vs. Features
Suggested solution: weight that argument in your vote for the new process
I can't be in the IRC meeting and I don't think voting without details in the right way to do it. I am explaining it in the list so you can consider it while making the decision.
You're not explaining anything, you're dismissing everything we did for reasons of your absence and <insert-the-other-favorite-here>, almost entirely similar to how I'm dismissive towards you.
- """It would be still viable if the process is outlined. The process
has to be in discussed and in place before FESCo delegates it to somebody else."""
- The process is outlined
- the process has been discussed, with representatives of Rel-eng,
our dear Feature Wrangler, the Spins SIG leader, a few spin-submitting/maintaining users, a FESCo delegate, and reviewed afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the first place is the party to whom FESCo delegated responsibility.
I don't know what was discussed since a summary wasn't posted in this list. Filling in the details would be helpful.
There were no meeting minutes being kept track of during the meeting, regrettably. But, in case you want my 5-minute after best-recollection of what happened, that has been on the Wiki:
http://fedoraproject.org/wiki/SIGs/Spins_NewProcess
Note that this is a very quick and dirty list of things as I recalled them happening in the meeting, not the meeting minutes.
Other pages needed to complete the details on these pages you have so far should be in the making but somehow the person tasked to create those pages does not seem to be able to find the time to actually do what he's intended to do.
I could continue but I don't feel like it. I sure hope this email sounds dismissive enough for you to finally stop arguing over nothing and continue the part of the thread where I think you may have actually said something useful.
If you don't feel I have said anything useful so far, I am sorry to hear that but then, we have nothing more to discuss. Carry on with your meeting and I will deal with the result when it comes to that point. Thanks.
No, thank you!
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
You make it sound so logic, I can only agree with you. You're right. I hadn't read anything, I can't remember anything, let alone keep in mind what everyone's ideas, comments and recommendations were and shape them into the skeleton (read: *THE SKELETON*) of a new process. I'm definitely a fail.
The process is defined and decisions being made where majority of the people affected by the process cannot participate. Nobody posts a meeting summary.
The spin process wiki page doesn't say draft or skeleton or anything like that. It appears on it's own and a vote is being rushed based on that in a IRC meeting (which I cannot attend) where a lot of details haven't been discussed yet.
A new procedure for reports every week has been added to the process where nobody has even a vague idea (according to you) on what it should contain. This all doesn't look like the right thing to do.
- Postpone the IRC meeting and voting now. It is too early and there has
not been enough details to warrant a vote yet.
NO! Period. Exclamation-mark. Fullstop. Why not? Because our next meeting would be only ~2 weeks prior to Beta freeze. Don't recall the timeline exactly, don't care enough to look it up for you.
Regardless of the time period, rushing through a vote with a skeleton proposal isn't going to benefit anybody. It would just lead to more confusion as has been evident over 3 releases in the past. So give it time and work through the details carefully.
Obviously, I haven't read the rest of your email, doh! I'm obviously responding to things I don't read?
Then I don't see the point of asking me to read a process wiki which has very few details. I have already read and commented on it.
I think you're confusing blunt criticism with constructive commentary.
Perhaps but I am tired of running around and want it to stop. I have wasted enough time unnecessarily. I am very frustrated with this repeatedly. Let's get it right, this time.
You're not explaining anything, you're dismissing everything we did for reasons of your absence and <insert-the-other-favorite-here>, almost entirely similar to how I'm dismissive towards you
Since I am not present, I can't know why without you and others who did attend post some details. Any of those attended post a summary please?
Other pages needed to complete the details on these pages you have so far should be in the making but somehow the person tasked to create those pages does not seem to be able to find the time to actually do what he's intended to do.
Who is that? Can he do it before the voting?
Rahul
On Thu, 2009-01-15 at 20:48 +0530, Rahul Sundaram wrote:
The problem is not me or others being in FUDCon or not but decisions being made there which will always exclude people. Ours a global community and the ability to attend conferences in a particular place anywhere in the world is limited. You said you will do it again which seemed to be that you didn't understand the issue. It is nothing personal.
Sounds like you'd rather FUDCons never happened at all. It also seems you've confused "created a proposal" with "made a set in stone final decision". These are two different things. The fact that many key players in the game happened to be in the same place, at the same time, and were able to dedicate some high bandwidth discussion to the matter led to a pretty good proposal. It's no different than somebody thinking up a proposal by themselves, or while talking with somebody on the phone, or IRC, or even email. It's a proposal. It can be modified, it can be adjusted, it can be rejected, etc.. It's a proposal.
I get the fact that you resent being in a timezone and location that makes it difficult for you to participate in higher bandwidth forms of communication (irc, phone, face to face). I can't help that. However I'm not about to force the entire Fedora project slow to a crawl just so that every thought, comment, discussion, fart, whatever happens via a public email. That's just ridiculous. People will continue to talk on IRC, will continue to chat via IM, will continue to talk on phones, and will even *shock* talk in person! Ideas, proposals, and even a decision or two, depending on the group, will be made in these ways. Deal with it.
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
Obviously, we can pre-discuss most of the items on the agenda on our mailing list fedora-spins -at- lists.fedoraproject.org.
With help of several key people in the current Spins process, including Process-Guru and current Feature Wrangler John Poelstra, we've come up with a real Spins Process during this last FUDCon.
If you are a member of Release Engineering, Quality Assurance, FESCo or Infrastructure, I would like you to attend.
Our first meeting (in the series of regular meetings) would be January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
== Agenda ==
# Finalizing Spins Process[1], vote
May I suggest part of this discussion is spin versus feature. I ask becuase the process (for me) got hairy when combined with the feature process.
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Sorry..I was not at FUDCon and did not see the doco. I am fine with the outcome, just wanted to see it written down.
Thanks!
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
== Agenda ==
# Finalizing Spins Process[1], vote
May I suggest part of this discussion is spin versus feature. I ask becuase the process (for me) got hairy when combined with the feature process.
We've beaten that horse during FUDCon and the Spins Process is now separate from the Feature Process, although with the primary features of the Feature Process such as Freezes and Wrangling.
Sorry..I was not at FUDCon and did not see the doco. I am fine with the outcome, just wanted to see it written down.
Cool, fair enough. fwiw, I did not intend to sound harsh by any means.
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, Jan 14, 2009 at 7:26 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
The Spins SIG is going to have regular, bi-weekly meetings. I've chosen Mondays at 18:00 UTC, on even weeks, and it will not take more then one hour.
This time will be bad for me over the next several weeks since I have physical therapy for my busted shoulder. However, as that ends towards the middle of February, then I should be good for this time.