21:01:54 <kanarip> #startmeeting Spins SIG
21:01:54 <zodbot> Meeting started Mon Nov 30 21:01:54 2009 UTC.  The chair is kanarip. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:02:12 <kanarip> cwickert, vous avez le donner de la parolle (or something)
21:02:18 <kanarip> #topic LXDE Spin
21:02:35 <nirik> I don't know that there is anything for the spins sig to do here.
21:02:39 * cwickert does not speak french
21:02:54 <kanarip> that's one of the things i wanted to address and establish and agree upon
21:03:02 <kanarip> 1) is there anything we can do, and
21:03:12 <cwickert> not sure if this is an urgent question, but we need to make sure that things like this don't happen again
21:03:15 <kanarip> 2) if so, are we in a position right now to even do anything about it
21:03:15 <brunowolff> Were the nightly builds different than the builds Jesse made?
21:03:47 <nirik> kanarip: I think no, and no. ;)
21:03:52 <kanarip> iirc, cwickert found the nightly builds to work, yet the released product didn't?
21:04:11 <nirik> I think the change might have crept in right before release...
21:04:26 <brunowolff> Through an rpm or another mechanism?
21:04:27 <nirik> so the nightlys might also have been broken, but it was hard to tell in the time we had
21:04:32 * nirik isn't sure.
21:04:32 <kanarip> how can that happen or how can we prevent that from happening?
21:04:34 <cwickert> what are we talking about first? the current situation or the background?
21:04:41 <nirik> cwickert: do you know when the breakage happened?
21:04:54 <kanarip> cwickert, we're trying to determine whether there is anything we can do about it in the future
21:05:13 <kanarip> cwickert, so, it's still a little background, with the eye on the future sorta speak
21:05:14 <cwickert> I think it was triggered by a change to the ks I made
21:05:22 <brunowolff> I want to make sure our nightly builds provide a reliable way to test builds.
21:05:38 <brunowolff> If what jesse is doing is different, then that is something that should change.
21:05:51 * nirik thinks we need more testing of the nightlys. ;(
21:06:02 <cwickert> ok, background: lxde-settings-daemon crashes and gets respawned by lxsession. this makes abrt run wild and crash the livesystem
21:06:14 <cwickert> the last nightlies I tested were fine
21:06:39 <cwickert> and I didn't even know about jesse's images
21:06:52 <kanarip> cwickert, what kind of time window is there between your latest test of a nightly compared to the final release compose? a day or just a few days or a week?
21:07:05 <kanarip> or more?
21:07:18 <cwickert> I think a week or something
21:07:29 <cwickert> I tested on nov 7th iirc
21:07:35 * nirik notes jesse's images are not composed until release is ready. There's no time to test those before release.
21:07:48 <brunowolff> It's possible that Jesse was using a version of livecd creator from the repo rather than an rpm.
21:08:11 <nirik> cwickert: so, it's possibly/likely that the nightly was broken after that but before release too, we just don't know
21:08:12 <nirik> ?
21:08:17 <cwickert> jesse composed images on nov 10th, so if we had been asked to test them, we could have avoided this disaster
21:08:25 * biertie is here too!
21:08:27 <cwickert> nirik: right
21:08:34 * biertie slaps kanarip for not letting me know!
21:08:37 <brunowolff> That's the kind of thing we need to know, so that the nightlies correspond to what is going to be distributed as best we can.
21:09:08 <cwickert> I think we also need images done by rel-eng
21:09:10 <kanarip> what we also need to make sure of we pay attention to
21:09:20 <kanarip> is whether anything is tagged f12-final, sorta speak
21:09:26 <nirik> so did the change happen between the 7th and 10th? or is this a difference between the two types?
21:09:26 <cwickert> because there is still a slight chance that something goes wrong in the composal
21:09:28 <kanarip> does that make sense?
21:10:03 <cwickert> nirik: what change? the commit or the breakage?
21:10:15 * nirik is still trying to see if there really is a difference between the nightlys and the final or if it was a change that landed in that time
21:10:38 <nirik> the breakage. It was ok on the 7th, but bad on the 10th. What changed?
21:10:41 <cwickert> sorry, my dates were incorrect
21:10:56 <nirik> was it a new package update? a change in the ks? or a difference in compose tools?
21:10:57 <cwickert> nirik: there is, as I said in the very beginning. I committed a change
21:11:00 <cwickert> no
21:11:06 <cwickert> I'm the one to blame
21:11:15 <nirik> ah. ;( ok.
21:11:18 <cwickert> I committed something and did not test it afterwars
21:11:19 <kanarip> aha
21:11:28 <nirik> so it would have been the same on the nightlys, but just after that commit was used.
21:11:30 <brunowolff> In a way that's good.
21:11:41 <cwickert> but the crash "should" not happen because it makes no sense
21:12:28 <cwickert> nirik: right. a guy in #fedora-de said he noticed the bug, but he didn't tell me
21:12:33 <nirik> yeah, so really we need more testing of composes at the end of the cycle especially.
21:12:50 <kanarip> and/or be more careful making changes
21:13:02 <nirik> because it's hard for spin owners to test each day... perhaps we could do some cross testing too...
21:13:04 <brunowolff> It still might be worth checking with Jesse to see whether he typically uses the latest livecd-tools rpm or if he uses something
21:13:07 <kanarip> similar to how changes to packages themselves are being handled more carefully
21:13:12 <nirik> (ie, have xfce folks test games and games test xfce... )
21:13:12 <brunowolff> from a source repo.
21:13:15 <cwickert> I'm not sure when I stopped testing, but I think I tested after the last commit. I cannot guarantee this though
21:13:34 <cwickert> at least one person noticed the problem, but didn't tell me
21:13:46 <nirik> cwickert: yeah, there is also a lag, as the composes take many hours and run once a day, so if it landed after it started it doesn't show up until next days compose.
21:13:48 <cwickert> and obviously no one eles tested
21:14:05 <cwickert> nirik: I tested the cimmit locally and for me it worked
21:14:36 <kanarip> cwickert, you composed using a rawhide host against rawhide?
21:14:50 <kanarip> i believe that is what Jesse does
21:14:51 <cwickert> no, beta host
21:15:11 <cwickert> but beta should not be different from rawhide at that point
21:15:11 <kanarip> that should be about as good as rawhide
21:15:16 <cwickert> right
21:15:21 <cwickert> I take the blame, no doubt about it
21:15:27 <cwickert> but we need better testing for sure
21:15:29 <kanarip> since changes to rawhide are being submitted in a controlled fashion by the time beta hits
21:15:43 <kanarip> so, let's summarize the options;
21:15:51 <kanarip> - better testing,
21:15:56 <cwickert> the problem I see is that I as the spin owner was not informed about the RC4 images
21:16:05 <kanarip> - careful with changes,
21:16:20 <kanarip> - better communication about rc's (i'll give you that),
21:16:43 <brunowolff> And nightlies. I don't think all of the spin people knew about them.
21:16:53 <nirik> cwickert: those are the final images that are made after the main fedora is a go for release... but yeah, there are a few days before release, but release is already 'go' then, so not sure what could have happened... pull the lxde?
21:17:07 <kanarip> brunowolff,  the "better testing" would be based on nightlies
21:17:28 <kanarip> brunowolff, if just because there's nothing else to perform "better testing" on to begin with
21:17:31 <maxamillion> crap, I'm late
21:17:32 <maxamillion> sorry
21:17:38 * maxamillion is here
21:17:51 <kanarip> cwickert, let's continue to the future; how is this being resolved right now?
21:18:02 <cwickert> it isn't
21:18:11 <cwickert> we need to agree on something with rel-eng
21:18:40 <cwickert> they say they don't have time to test each and every spin
21:18:48 <cwickert> while doing 4 or 5 composes
21:19:02 <nirik> (or compose them)
21:19:04 <cwickert> so this is where the sig and the spin owners need to setp in
21:19:12 <kanarip> nirik, ^ here see the point why i'm bringing up again and again whether the scope of the spin sig is just right
21:19:49 <nirik> well, the issue here is that we have nightlys... if we don't think they are good enough for testing we need to ask rel-eng to make all the spins for rc's, but they don't want to do that.
21:19:50 <cwickert> nirik: interesting thought. let the sig compose the spins
21:19:57 <cwickert> even better IMO
21:20:05 <maxamillion> as far as the future, what about the auto-qa efforts? are there test suites that could be run against the nightlies to generate reports so that we at least have a base line?
21:20:07 <cwickert> not sure what rel-eng thinks though
21:20:08 <Oxf13> I'm not sure how that's even better.
21:20:14 <kanarip> nirik, how about someone other then the current rel-eng "team" does that part for them?
21:20:21 <brunowolff> It seems like the nightlies should have been good enough, at least in this case.
21:20:22 <huff> what is a test, just weather it boots or is there more too i that that, the first part could be automated
21:20:22 <huff> in somekinda smoke test
21:20:23 * nirik doesn't know how that helps...
21:20:31 <Oxf13> given the number of spins to compose, are you going to be online 24/7 during the release crunch to spin every time we make an update?
21:20:47 <cwickert> maxamillion, Oxf13: according to the spin process page rel-eng runs "basic spin testing", e.g. install them
21:20:53 <huff> we do this with the ovirt node
21:20:59 <kanarip> Oxf13, is the bunch of us or is any one individual?
21:21:01 * nirik notes it takes about 6-7 hours to compose all the spins on the spin1 machine.
21:21:12 <maxamillion> nirik: ah
21:21:13 <pjones> cwickert: you know anybody can already do their own compose, right?
21:21:21 <brunowolff> Spins are supposed to have test cases for QA. (Note I am guilty of not doing that yet.)
21:21:32 <nirik> I think it's important that ANYONE doing a compose gets the same thing.
21:21:47 <Oxf13> cwickert: that may be old info, and would be viable when there was only 3 or 4 spins, not the giant amount we have now with DVD sized isos
21:21:50 <cwickert> pjones: but there still is a slight chance that my composes are different from the official ones
21:21:57 <Oxf13> there just isn't /time/ to compose them all, download them all and boot them all
21:22:03 <Oxf13> that's a day's operation at best
21:22:04 <cwickert> Oxf13: agreed
21:22:16 <maxamillion> agreed
21:22:17 <cwickert> I fully understand your pov
21:22:19 <Oxf13> that "slight chance" is one we have to live with
21:22:22 <pjones> cwickert: sounds like a strawman, honestly
21:22:38 <Oxf13> if we don't trust the spin tools to produce the same results using the same environment, then we've got a really big problem
21:22:46 <cwickert> pjones: I tested the spin and for me it worked, that's a fact
21:23:15 <brunowolff> Jesse, do you usually use the rawhide version of livecd-creator or one from the source repository?
21:23:32 <Oxf13> brunowolff: the rawhide version
21:23:33 * nirik further notes on spin1... "yum update to latest rawhide" "compose spins". So everydays should be current rawhide versions of anything.
21:23:45 <Oxf13> cwickert: this is somethign I never actually got info on.  What was the change that caused this problem?
21:23:54 <huff> Oxf13: sounds like a problem with the compose process
21:24:02 <cwickert> Oxf13: http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=commit;h=c4caad0bc94856b12a7eb042ac3ca85427d62584
21:24:17 <kanarip> huff, +1, the first problem i'm seeing is a capacity problem
21:24:18 <brunowolff> So it sounds like the nightlies should be pretty close. And we probably don't need a change there.
21:24:32 <Oxf13> cwickert: and you tested after this change?
21:24:40 <huff> ahhhh LAGGGGG
21:24:54 <nirik> that should be: 'yum update' 'git pull' 'compose spins'. :)
21:24:57 <cwickert> Oxf13: yes
21:25:21 <maxamillion> huff: same here unfortunately ... making it hard to follow the convo :/
21:25:33 <huff> yep
21:25:36 <Oxf13> cwickert: so are you claiming that a nightly after this change, /doesn't/ have the problem, and only the isos I produced does?
21:25:44 <cwickert> no
21:25:57 <Oxf13> so then what are you claiming?
21:26:13 <maxamillion> nirik: is there a separate server the images could be copied to in order to run auto-qa stuff?
21:26:23 <cwickert> Oxf13: that my *personal* compose did not have the problem
21:26:25 <huff> yea, it would be nice to add a somketest to the compose process
21:26:37 <Oxf13> huff: that's what autoQA is there to solve
21:26:46 <huff> ahhh
21:26:54 <cwickert> Oxf13: I already mentioned that one user *did* see the bug in the latest nightlys, but he didn't tell me
21:26:55 <kanarip> is there any AutoQA?
21:27:14 <nirik> maxamillion: I don't know. You would need to talk to autoqa folks about that.
21:27:18 <Oxf13> kanarip: yes, there has been lots of work on the autoQA front.
21:27:19 * huff not fam with autoQA
21:27:25 <maxamillion> kanarip: not that I know of, I honestly don't even know if the AutoQA stuff is "production ready" ... it was just something that got brought up for the future
21:27:40 <maxamillion> kanarip: but it does exist --> http://fedoraproject.org/wiki/AutoQA
21:27:42 <kanarip> Oxf13, i know about the work, but is that doesn't answer whether it's in place or not
21:27:43 <Oxf13> kanarip: the first target is "israwhidebroken.com" which responds to a new rawhide repo and runs tests on it, which is nearing completion
21:27:56 <brunowolff> I don't think that is spin specific stuff at this point. So while spins will benefit as everything else does, some hand
21:28:05 <maxamillion> Oxf13: and we are all *very* thankful for those efforts :)
21:28:05 <brunowolff> testing is going to be desired.
21:28:15 <Oxf13> kanarip: automatic testing of produced live images is not in place, however instead of working on $SomethingElse to provide this, I mention AutoQA so that it can be worked on under that project
21:28:29 <kanarip> because as long as it isn't actually in place, it's not something that -within our current scope- we can depend upon
21:28:56 <Oxf13> kanarip: right, we can't, just like we also can't depend on anything else that also isn't there.
21:28:57 <kanarip> "our current scope" being "the technical review of kickstarts for spins"
21:29:17 <nirik> low tech might just be to ask people to test one or more nightlys and report to the spins list.
21:29:39 <brunowolff> Spin owners should be responsible for that.
21:29:41 <kanarip> well rather then to "ask" which we've seen fail before, it would be to "require"
21:29:44 <Oxf13> cwickert: so it really sounds like we need a report on what's different in your test environment from the one that nirik and I use
21:29:54 <pjones> kanarip: or better yet, "do".
21:30:05 <maxamillion> I'd really like to see spins be a part of AutoQA, I will make a point to talk with them asap and maybe see if we can throw together some time or a hackfest during FUDCon to hash out some stuff ... all others are welcome :)
21:30:09 <kanarip> pjones, i'd like a pony with that please ;-)
21:30:13 <brunowolff> Some of us have been short cutting and using spins we compose instead of the nightlies under the assumption that that is good enough.
21:30:15 <cwickert> Oxf13: it was a fully updated beta, now it's f12
21:30:39 <Oxf13> brunowolff: if the compose environment is a clean production, it had better be.
21:30:50 <huff> we have a autotest script for ovirt node which is a livecd image
21:30:54 <brunowolff> I think when it gets close to alpha, beta and especially final, spin owners should specifically download and test the nightly images.
21:30:54 <huff> http://git.fedoraproject.org/git/?p=ovirt/node-image.git;a=blob;f=autotest.sh;h=c67931a75698698c026cf2b6455c3430ec9dd0cb;hb=51bf21fe0413ccc0f3b32219fc37305d34d23a4a
21:31:00 <pjones> brunowolff: that really does have to be good enough.
21:31:05 <Oxf13> and with the changes that have gone in for selinux, it is probably time to start doing the livecd creation in a mock chroot
21:31:11 <pjones> brunowolff: if it isn't, we've got much bigger problems
21:31:51 <brunowolff> I tend to have some packages not in the release installed. Typcially future updates not tagged for final.
21:31:58 <maxamillion> huff: oh ... nice
21:32:17 <cwickert> Oxf13: I had made the change in my personal spin checkout already some days before and tested it for a couple of days before I committed it. not sure what/if something changed between november 6th and november 11th
21:32:20 <brunowolff> Normally that's OK, but right before a release, it's not such a good idea.
21:33:32 <huff> Oxf13: I agree
21:33:48 <huff> Oxf13: There are also some patches to upstream koji that allow for livecd iamges to be built inside koji.
21:33:52 <kanarip> would it be reasonable to freeze the entire spin-kickstarts repo just like we freeze rawhide itself?
21:33:59 <Oxf13> huff: right, that'll come later.
21:34:01 <pjones> brunowolff: and that's why you should do them in mock ;)
21:34:20 <Oxf13> kanarip: yes, it would.
21:34:25 <kanarip> in which case, imo, it starts getting outside of the scope of the spins sig and comes closer to rel-eng
21:34:48 <kanarip> the one stop shop for getting stuff tagged and pushed into fX-final, sorta speak
21:35:00 <maxamillion> kanarip: I think that would be a solid idea, if we freeze the kickstarts then we can (hopefully) easily eliminate them as a point of failure
21:35:03 <cwickert> I asked that question a while back and I was told that I can commit changes as long as I don't include any new packages
21:35:19 <cwickert> I was told so by rel-eng
21:35:19 <Oxf13> kanarip: well, that depends.
21:35:31 <kanarip> cwickert, the change you made included a new package, and removed a group ;-)
21:35:38 <brunowolff> For the games spin I was more or less assuming the freeze applied to us. My late changes had to do with packages in
21:35:41 <Oxf13> kanarip: if rel-eng uses the spin-kickstarts package content to get at the .ks files, then it doesn't matter when upstream freezes, as you'd have to go through rel-eng to get the package updated
21:35:52 <brunowolff> the games spin being dropped right before the release.
21:36:03 <cwickert> kanarip: new packge = new in the repo package
21:36:13 <kanarip> Oxf13, right, but that's not the case right now is it?
21:36:34 <kanarip> cwickert, ah, ok
21:36:34 <Oxf13> kanarip: no, but that's a minor detail.  It could certainly become the case easily
21:37:33 <kanarip> so how about that?
21:37:52 <Oxf13> I'm happy with either methodology
21:38:01 <maxamillion> kanarip: wanna file a rel-eng ticket since its your idea? :D
21:38:11 <Oxf13> I can either A) communicate when we freeze and ask the upstream repo to branch+freeze at the same time, and just build form git pulls
21:38:18 <kanarip> we freeze with our own little soft freeze policy, and when you need changes after the freeze, a new package needs to be built and tagged by rel-eng, or
21:38:25 <Oxf13> or B) I can just work from the latest spin-kickstarts package
21:38:53 <kanarip> rel-eng can (request a) freeze and all kickstart changes go through rel-eng who can then use the git repo directly (a branch, that being)?
21:38:54 <huff> can you specify a tag
21:39:01 <huff> build for a tag in get
21:39:03 <kanarip> huff, really?
21:39:04 <huff> git
21:39:08 <kanarip> come on...
21:39:11 <huff> idk can you?
21:39:32 <brunowolff> Yes, you can commit to specific branches.
21:39:41 <Oxf13> you can create a tarball from a tag in git, yes
21:39:42 <cwickert> git push origin <branch>
21:39:44 <Oxf13> and stuff that into a package
21:39:49 <kanarip> ...
21:39:59 <maxamillion> Oxf13: I vote B, that way the spin-kickstarts packager(s) can control the freeze and spins can continue on (if need be)
21:40:00 <kanarip> are we talking about git now all of a sudden? ;-)
21:40:14 <cwickert> seems so ;)
21:40:22 <brunowolff> I think option A (branch and freeze) is a bit better as it makes things more clear.
21:40:28 <maxamillion> oh nice
21:40:33 <maxamillion> kanarip owns spin-kickstarts
21:40:47 * nirik doesn't care as long as it's clearly communicated.
21:40:54 <maxamillion> I suppose its up to kanarip then
21:40:59 <Oxf13> I'm a neutral party in this, I can happily work with either A or B
21:41:36 <kanarip> Oxf13 and myself essentially had different A's and different B's
21:41:44 <maxamillion> lol
21:41:47 <cwickert> I besides of all technical issues and solutions, IMO the most important thing is communitcation. I can understand Oxf13's POV that rel-eng cannot test everything, but I on the other hand can only test an image that I'm aware of
21:41:47 <brunowolff> maxamillion: I think option A allows changes to go in after freeze if need be.
21:41:51 <kanarip> maxamillion, what A) or what B) are you referring to? brunowolff?
21:41:51 <maxamillion> ok, well then I vote for Oxf13's B
21:42:03 <Oxf13> oh dear (:
21:42:16 <maxamillion> Oxf13: look what you had to go and do ;)
21:42:19 <kanarip> OK we take Oxf13's A and B, please case your +1's and +0's
21:42:39 <kanarip> if you don't care, +1 both or +0 both
21:42:49 <maxamillion> +1 B
21:42:54 <brunowolff> +1 A (but can easily live with B)
21:43:02 <kanarip> +1 B
21:43:16 <cwickert> +1 B (but could live with A)
21:43:23 * maxamillion nudges nirik
21:43:33 * kanarip nudges biertie
21:43:41 * kanarip nudges huff ;-)
21:43:45 <huff> +1 A (I like pulling from git)
21:43:51 <nirik> +0 don't care
21:43:52 * maxamillion kinda say that coming
21:44:01 <maxamillion> s/say/saw
21:44:08 <biertie> que?
21:44:15 <maxamillion> huff: you're git happy ;P
21:44:20 <nirik> B if it helps us just decide and move on. ;)
21:44:20 <kanarip> nirik, it might have impact on the nightlies though, are you sure you don't care?
21:44:38 <nirik> I can re-work the script I think...
21:44:50 <nirik> once we freeze just have it run from the package.
21:44:57 <kanarip> ok, that's what i consider a wrap
21:45:19 <kanarip> 2x A, 3x B and a small preference for B from nirik, and a "could live with B" from an A voter
21:45:33 * maxamillion has something for open forum/floor or whatever you call it once we get there
21:46:03 <kanarip> #agreed spin-kickstarts package to be built at milestones, updates after milestones to be built and tag-requested through rel-eng, rel-eng then to compose through spin-kickstarts package
21:46:29 <brunowolff> Where should that be documented?
21:46:37 <nirik> so that happens after beta? or ?
21:46:54 <kanarip> alpha == new package, beta == new package, etc
21:46:54 <maxamillion> http://fedoraproject.org/wiki/Infrastructure/CustomSpins <--- document here maybe?
21:46:59 <brunowolff> I'll volunteer to edit the wiki if I get a suggestion as to where.
21:47:11 <kanarip> anything else during a freeze requires a tag request to rel-eng, correct?
21:47:28 <Oxf13> well basically as soon as we branch
21:47:36 <Oxf13> which in a no frozen rawhide world, happens at feature freeze
21:47:36 <maxamillion> kanarip: that's how I understood it
21:47:43 <kanarip> brunowolff, on the Spins_SIG process page, with a reference to rel-eng, and vice-versa
21:47:49 * nirik just wants to know when the nightly script should stop using git and should move to the package?
21:47:54 <kanarip> Oxf13, +1
21:48:02 <nirik> ok, fair enough
21:48:06 <kanarip> nirik, for this release cycle
21:48:18 <kanarip> euh...
21:48:19 <Oxf13> nirik: I have a feeling the nightly script is going to need to create 2x once we branch.  One for rawhide, one for the pending release
21:48:25 <kanarip> nirik, for this *development* cycle
21:48:43 <nirik> Oxf13: ah yeah... 14 hours of building...wheee! :)
21:48:51 <kanarip> is rawhide really relevant when we branch for the pending release?
21:48:59 <Oxf13> nirik: yeah, or just ignore rawhide after we branched.
21:49:05 <brunowolff> #action brunowolff will document spins sig releng handoff method
21:49:10 <maxamillion> nirik: as long as we keep it under 24, we'll be fine ;) .... at least that's how we feel about backups at $dayjob
21:49:12 <Oxf13> kanarip: its relevant for people who want to get started on F14 features that missed the F13 cutoff
21:49:12 <nirik> either way. I can see what I can do.
21:49:14 <cwickert> sorry, but I think feature freeze is much to early, I didn't think of feature freeze when I voded, I thought we were talking about beta freeze
21:49:18 <kanarip> #action brunowolff will document spins sig releng handoff method
21:49:28 <kanarip> Oxf13, fair enough
21:49:43 <Oxf13> cwickert: feature freeze is when the pending release as a whole gets frozen, and remains frozen until we release
21:49:46 <kanarip> Oxf13, nirik, rawhide composes at that point have waaaaaaay lower prio though
21:49:55 <Oxf13> cwickert: updates to the freeze will be managed by bodhi
21:50:12 <nirik> kanarip: right.
21:50:23 <cwickert> Oxf13: I thought feature freeze was even way before alpha?
21:50:36 <maxamillion> cwickert: I think feature deadline is way before that
21:50:42 <Oxf13> feature freeze is a week before Alpha freeze
21:50:43 <cwickert> right
21:50:52 <maxamillion> oh, nvm ... don't listen to me
21:51:11 * kanarip would love our calendaring solution to just magically work
21:51:28 <cwickert> IMP this is too early, let's freeze on beta. I think nobody thought about no frozen rawhide when we voted
21:51:28 * kanarip makes a note to step in on implementing that Zarafa thing he himself suggested we use
21:51:29 <biertie> it's a shame magic doesn't work!
21:51:35 <cwickert> s/IMP/IMO
21:52:02 <biertie> cwickert: +1
21:52:03 <nirik> cwickert: yeah, but everything else is frozen, why not spins ks?
21:52:23 <maxamillion> nirik: +1
21:52:27 <cwickert> because one week before alpha rawhide is not really frozen
21:52:33 * nirik notes if we do this, it might be nice to have co-maintainers for the spins-kickstart package too, so we don't always have to bug kanarip if he's busy.
21:52:42 <kanarip> cwickert, it's not "freeze no changes anymore" per so
21:52:52 <brunowolff> Are you going by the old process or the new one?
21:53:07 <kanarip> cwickert, it's "if you want your change" "make sure a new package is built" and "have it tagged properly"
21:53:26 <kanarip> brunowolff, either way, freeze requires tag to override what is in the frozen tree
21:53:44 <cwickert> kanarip: but the spins are only composed from tagged packages already before alpha, IMO in the end the composes are tested less than now
21:54:09 <kanarip> cwickert, but they are composed using (maybe) newer versions of packages
21:54:16 <kanarip> and so there you go
21:54:24 <cwickert> s/tagged packages/tagged packages + tagged spin kickstarts package
21:54:24 <brunowolff> They would be composed with what is currently scheduled to be in the release.
21:54:34 <kanarip> the kickstarts don't have to change to make a spin be different...
21:54:56 <brunowolff> If something gets updated and tagged for the release, the update is going to be reflected in the next compose.
21:55:13 <kanarip> it makes perfect sense to me
21:55:15 <cwickert> kanarip: but what when the newer packages require a change to the ks?
21:55:29 <kanarip> cwickert, if it "requires", the change better be done in parallel
21:55:39 <kanarip> or you lose one or two nightly composes
21:55:46 <brunowolff> Then you need to ask kanarip to make a new spins-kickstart package.
21:55:50 <kanarip> depending on the exact amount of lag, that is
21:55:53 <cwickert> and when is this effectively tested?
21:56:09 <Oxf13> whenever somebody downloads the spin
21:56:11 <kanarip> when you download the spin or compose yourself against rawhide using the changed .ks
21:56:27 <kanarip> the essence of attacking the problem is to freeze
21:56:36 <cwickert> right, then I'm the only one to test again
21:56:40 <kanarip> be careful with your changes
21:56:52 <cwickert> kanarip: agreed, but please not before alpha
21:56:55 <kanarip> cwickert, this does in no way address the "need more testing" issue, that's correct
21:56:57 <Oxf13> cwickert: who else are you expecting to test your changes?
21:57:15 <cwickert> all users of the nightly spins
21:57:19 <kanarip> i would anticipate your users may want to be willing to test some things as well
21:57:59 <kanarip> in the end, they're either going to be happy and satisfied participants, or just consumers whether happy or unhappy
21:58:05 <cwickert> Oxf13: and if you create the nightly only from a tagged spin-kickstarts package that early in the release cycle, there is less testing
21:58:29 <kanarip> cwickert, there is more testing
21:58:36 <Oxf13> cwickert: maybe that'll finally drive the point home that the time to make changes and experiment is /before/ the feature freeze, and no tafter
21:58:48 <Oxf13> after the feature freeze you should be in bugfix only mode
21:58:49 <kanarip> there is more testing if you are more careful with changes
21:59:29 <cwickert> but what if upstream changes after feature freeze. with this policy, we could not even have tested the desktop spin because gnome 2.28 wasn't even released
22:00:07 <Oxf13> cwickert: then those upstream changes go to F14
22:00:18 <Oxf13> unless we were building pre-releases of them into rawhide prior to the feature freeze
22:00:24 <kanarip> cwickert, we could have tested since 2.28 is a freeze exempting tag
22:00:39 <kanarip> and what Oxf13 said
22:00:57 <kanarip> there was 2.27 (being 2.28) for a while in rawhide before the freeze
22:01:04 <maxamillion> grrr ... brb
22:01:12 <cwickert> kanarip: ok, then think of Xfce
22:01:26 <cwickert> I'm sure we will not have 4.8 in F13 then
22:01:33 <kanarip> cwickert, i don't understand this
22:01:43 <Oxf13> cwickert: one of the big changes with NFR is driving it into people's head that after feature freeze, changes are supposed to stop, anything that isn't a bugfix
22:01:44 <kanarip> on the one end it was the rapid change that bit the LXDE spin
22:01:55 <kanarip> for which we're trying to find a solution...
22:02:17 <kanarip> and on the other end you're advocating what seems to be a free-for-all right up to a few weeks before the actual release
22:02:19 <Oxf13> that's why we're making two repos available.  1) the pending release which should get bugfixes only as it polishes up for the release, and 2) rawhide which just keeps going and consuming latest upstream hotness.
22:02:36 <cwickert> Oxf13: but are new upstream versions bugfixes or are they new features?
22:02:51 <Oxf13> cwickert: depends on the upstream
22:02:53 <nirik> cwickert: well, it's very close.
22:03:13 <Oxf13> cwickert: and depends on the state of your package set at feature freeze vs the upstream release
22:03:23 <nirik> cwickert: feature freeze is 02-09, and xfce is claiming to have a pre1 on 02-01
22:03:43 <Oxf13> if you've got scm snapshots of the upstream release RCs and what not, likely the only change in the upstream new release from your build is bug fixes
22:04:07 <Oxf13> but if you don't take any upstream changes or snapshots and expect to go from 1.0 to 2.0 after feature freeze, that's not just a bugfix update, and shouldn't be allowed.
22:04:07 <cwickert> nirik: come on, you know how good Xfce is in keeping their schedule ;)
22:04:32 <nirik> cwickert: perhaps it will be different this time. ;) They are much more organized.
22:05:15 <cwickert> Oxf13: stricktly speaking you are right, but then we would have needed to drop thunderbird 3.0 and a lot of other packages.
22:05:27 <maxamillion> they really are, the guy (I forget who) is kinda spear heading the whole "lets be organized for this cycle" thing and he seems to be doing well
22:05:50 <cwickert> maxamillion: jannis, I know him
22:05:50 <Oxf13> cwickert: in many of those cases, dropping them would have been the right decision
22:05:51 <Oxf13> cwickert: as upstreams did more than just fix bugs between the snapshots, which was unexpected
22:05:52 <kanarip> cwickert, again, not really, since the pre-release had been in rawhide some time before the feature freeze
22:05:57 <maxamillion> cwickert: ah, cool :)
22:05:57 <cwickert> and last time it was nick who tried to do it
22:06:34 <cwickert> maxamillion: I met nick at fosdem and that was in february and asked him about xfce 4.6. "don't ask me, my shit is done"
22:06:49 <maxamillion> cwickert: heh
22:06:54 <nirik> anyhow, we are drifting here and out of time...
22:07:00 <kanarip> ok, so, although we're past the hour already...
22:07:03 <kanarip> biertie, ping
22:07:10 <kanarip> #topic Spins pages
22:07:30 <biertie> aha!
22:07:31 <maxamillion> Spins pages rock!
22:07:37 <maxamillion> done, moving on :P
22:07:46 <biertie> you let them rock maxamillion
22:07:52 <kanarip> 1) linking the current revisions on the list of prior releases
22:07:53 <biertie> I just kick your ass if they don't rock! ;-)
22:08:01 <biertie> yes yes
22:08:04 <biertie> add actions for me ;-)
22:08:09 <kanarip> 2) setting them back to Category Spins_in_Development as per the process
22:08:35 <kanarip> #action biertie: linking the current revisions of Spins Pages on each page's list of prior releases
22:08:41 <maxamillion> biertie: hey now, why am I getting ass kickings? I was just trying to pay compliments
22:08:44 <maxamillion> :D
22:08:58 <kanarip> #action biertie to add Spins pages back to Category Spins_in_Development as per the process
22:09:25 <kanarip> #agreed biertie to rule the Spins pages and kick their ass ;-)
22:09:46 <biertie> maxamillion: I won't kick your ass *just yet*
22:09:50 * kanarip moves to open floor if no-one objects in the next 1.3 seconds
22:09:55 <kanarip> #topic Open Floor
22:10:06 <maxamillion> foomatic
22:10:17 <maxamillion> curious why foomatic isn't there by default?
22:10:27 <maxamillion> I've had a couple users ask this of me and I lack an answer
22:11:05 <nirik> maxamillion: it might have been space related... not sure.
22:11:22 <Oxf13> there was a thread recently on this
22:11:23 <maxamillion> yeah, that was my first thought since the package is 34M ... but just wanted to verify
22:11:41 <Oxf13> the printing maintainer didn't think it was still needed in a large number of cases.
22:11:41 <maxamillion> Oxf13: oh? .... that's like the second thread I've some how missed in the last couple weeks, I suck at this
22:11:46 <Oxf13> and yeah, huge.
22:11:51 <maxamillion> ah
22:12:09 <maxamillion> ok, was just curious .... thanks :)
22:12:10 <kanarip> ohw well
22:12:20 <kanarip> i recently noticed somehow cups wasn't default anymore
22:12:27 <nirik> yeah, perhaps ping twaugh about it.
22:12:33 <kanarip> installing cups didn't get me any drivers, so everything was generic/raw
22:12:37 <kanarip> it was freaking awesome
22:12:48 <maxamillion> kanarip: for many values of $awesome?
22:12:53 <kanarip> took me 5 seconds in all
22:12:57 <kanarip> but users...
22:13:11 <Oxf13> maxamillion: see "As of F12 RC3 my printer model is still not shown" on fedora-test-list
22:13:22 <kanarip> omg they are going to run to the next computer shop and buy a lifelong subscription to windows magazine
22:13:41 <maxamillion> Oxf13: I'll go read the thread, thanks for finding the subject line for me
22:13:47 <maxamillion> Oxf13: on f-d-l?
22:13:51 <Oxf13> fedora-test-list
22:13:55 <maxamillion> ah
22:14:17 <kanarip> so, are we done here?
22:14:27 <brunowolff> What about the branch?
22:14:32 * kanarip closes the meeting in 5... 4... 2.5...
22:14:47 <brunowolff> I want to update my old spin page to point to the f12 branch before making the new one.
22:15:13 <kanarip> brunowolff, please feel free to do so before biertie touches your spins page ;-)
22:15:14 <brunowolff> I also need to make a change for F13 as one of the games got dropped right after the release for license issues.
22:15:25 <brunowolff> I can'
22:15:30 <kanarip> can't?
22:15:53 <biertie> I think that will happen in toronto
22:15:57 <brunowolff> I didn't want to point to a branch the doesn't exist.
22:16:01 <biertie> so, saturday or sunday! :-)
22:16:14 <kanarip> brunowolff, hmmm maybe i've not pushed it just yet...
22:16:31 <brunowolff> Unless I am reading the spin-kickstarts page there isn't an F12 branch yet.
22:16:45 <brunowolff> reading it wrong.
22:17:05 <kanarip> brunowolff, done, pushed, should be there
22:17:09 <brunowolff> I see F12-alpha and master
22:17:22 <kanarip> sorry!
22:17:23 <brunowolff> I see F12 now. Thanks!
22:17:29 <kanarip> no problem ;-)
22:17:34 <brunowolff> I'll be updating my spin page tonight.
22:18:43 <maxamillion> oh, on the topic of co-maintainers for the spin-kickstarts ... should there be one from each spin sig or just a few or ... other solution?
22:20:40 <kanarip> maxamillion, opt-in, contributions appreciated
22:20:45 * kanarip closes the meeting, gotta run
22:20:50 <kanarip> #endmeeting