21:01:54 #startmeeting Spins SIG 21:01:54 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:02:12 cwickert, vous avez le donner de la parolle (or something) 21:02:18 #topic LXDE Spin 21:02:35 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 that's one of the things i wanted to address and establish and agree upon 21:03:02 1) is there anything we can do, and 21:03:12 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 2) if so, are we in a position right now to even do anything about it 21:03:15 Were the nightly builds different than the builds Jesse made? 21:03:47 kanarip: I think no, and no. ;) 21:03:52 iirc, cwickert found the nightly builds to work, yet the released product didn't? 21:04:11 I think the change might have crept in right before release... 21:04:26 Through an rpm or another mechanism? 21:04:27 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 how can that happen or how can we prevent that from happening? 21:04:34 what are we talking about first? the current situation or the background? 21:04:41 cwickert: do you know when the breakage happened? 21:04:54 cwickert, we're trying to determine whether there is anything we can do about it in the future 21:05:13 cwickert, so, it's still a little background, with the eye on the future sorta speak 21:05:14 I think it was triggered by a change to the ks I made 21:05:22 I want to make sure our nightly builds provide a reliable way to test builds. 21:05:38 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 ok, background: lxde-settings-daemon crashes and gets respawned by lxsession. this makes abrt run wild and crash the livesystem 21:06:14 the last nightlies I tested were fine 21:06:39 and I didn't even know about jesse's images 21:06:52 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 or more? 21:07:18 I think a week or something 21:07:29 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 It's possible that Jesse was using a version of livecd creator from the repo rather than an rpm. 21:08:11 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 ? 21:08:17 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 nirik: right 21:08:34 * biertie slaps kanarip for not letting me know! 21:08:37 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 I think we also need images done by rel-eng 21:09:10 what we also need to make sure of we pay attention to 21:09:20 is whether anything is tagged f12-final, sorta speak 21:09:26 so did the change happen between the 7th and 10th? or is this a difference between the two types? 21:09:26 because there is still a slight chance that something goes wrong in the composal 21:09:28 does that make sense? 21:10:03 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 the breakage. It was ok on the 7th, but bad on the 10th. What changed? 21:10:41 sorry, my dates were incorrect 21:10:56 was it a new package update? a change in the ks? or a difference in compose tools? 21:10:57 nirik: there is, as I said in the very beginning. I committed a change 21:11:00 no 21:11:06 I'm the one to blame 21:11:15 ah. ;( ok. 21:11:18 I committed something and did not test it afterwars 21:11:19 aha 21:11:28 so it would have been the same on the nightlys, but just after that commit was used. 21:11:30 In a way that's good. 21:11:41 but the crash "should" not happen because it makes no sense 21:12:28 nirik: right. a guy in #fedora-de said he noticed the bug, but he didn't tell me 21:12:33 yeah, so really we need more testing of composes at the end of the cycle especially. 21:12:50 and/or be more careful making changes 21:13:02 because it's hard for spin owners to test each day... perhaps we could do some cross testing too... 21:13:04 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 similar to how changes to packages themselves are being handled more carefully 21:13:12 (ie, have xfce folks test games and games test xfce... ) 21:13:12 from a source repo. 21:13:15 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 at least one person noticed the problem, but didn't tell me 21:13:46 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 and obviously no one eles tested 21:14:05 nirik: I tested the cimmit locally and for me it worked 21:14:36 cwickert, you composed using a rawhide host against rawhide? 21:14:50 i believe that is what Jesse does 21:14:51 no, beta host 21:15:11 but beta should not be different from rawhide at that point 21:15:11 that should be about as good as rawhide 21:15:16 right 21:15:21 I take the blame, no doubt about it 21:15:27 but we need better testing for sure 21:15:29 since changes to rawhide are being submitted in a controlled fashion by the time beta hits 21:15:43 so, let's summarize the options; 21:15:51 - better testing, 21:15:56 the problem I see is that I as the spin owner was not informed about the RC4 images 21:16:05 - careful with changes, 21:16:20 - better communication about rc's (i'll give you that), 21:16:43 And nightlies. I don't think all of the spin people knew about them. 21:16:53 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 brunowolff, the "better testing" would be based on nightlies 21:17:28 brunowolff, if just because there's nothing else to perform "better testing" on to begin with 21:17:31 crap, I'm late 21:17:32 sorry 21:17:38 * maxamillion is here 21:17:51 cwickert, let's continue to the future; how is this being resolved right now? 21:18:02 it isn't 21:18:11 we need to agree on something with rel-eng 21:18:40 they say they don't have time to test each and every spin 21:18:48 while doing 4 or 5 composes 21:19:02 (or compose them) 21:19:04 so this is where the sig and the spin owners need to setp in 21:19:12 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 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 nirik: interesting thought. let the sig compose the spins 21:19:57 even better IMO 21:20:05 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 not sure what rel-eng thinks though 21:20:08 I'm not sure how that's even better. 21:20:14 nirik, how about someone other then the current rel-eng "team" does that part for them? 21:20:21 It seems like the nightlies should have been good enough, at least in this case. 21:20:22 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 in somekinda smoke test 21:20:23 * nirik doesn't know how that helps... 21:20:31 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 maxamillion, Oxf13: according to the spin process page rel-eng runs "basic spin testing", e.g. install them 21:20:53 we do this with the ovirt node 21:20:59 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 nirik: ah 21:21:13 cwickert: you know anybody can already do their own compose, right? 21:21:21 Spins are supposed to have test cases for QA. (Note I am guilty of not doing that yet.) 21:21:32 I think it's important that ANYONE doing a compose gets the same thing. 21:21:47 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 pjones: but there still is a slight chance that my composes are different from the official ones 21:21:57 there just isn't /time/ to compose them all, download them all and boot them all 21:22:03 that's a day's operation at best 21:22:04 Oxf13: agreed 21:22:16 agreed 21:22:17 I fully understand your pov 21:22:19 that "slight chance" is one we have to live with 21:22:22 cwickert: sounds like a strawman, honestly 21:22:38 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 pjones: I tested the spin and for me it worked, that's a fact 21:23:15 Jesse, do you usually use the rawhide version of livecd-creator or one from the source repository? 21:23:32 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 cwickert: this is somethign I never actually got info on. What was the change that caused this problem? 21:23:54 Oxf13: sounds like a problem with the compose process 21:24:02 Oxf13: http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=commit;h=c4caad0bc94856b12a7eb042ac3ca85427d62584 21:24:17 huff, +1, the first problem i'm seeing is a capacity problem 21:24:18 So it sounds like the nightlies should be pretty close. And we probably don't need a change there. 21:24:32 cwickert: and you tested after this change? 21:24:40 ahhhh LAGGGGG 21:24:54 that should be: 'yum update' 'git pull' 'compose spins'. :) 21:24:57 Oxf13: yes 21:25:21 huff: same here unfortunately ... making it hard to follow the convo :/ 21:25:33 yep 21:25:36 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 no 21:25:57 so then what are you claiming? 21:26:13 nirik: is there a separate server the images could be copied to in order to run auto-qa stuff? 21:26:23 Oxf13: that my *personal* compose did not have the problem 21:26:25 yea, it would be nice to add a somketest to the compose process 21:26:37 huff: that's what autoQA is there to solve 21:26:46 ahhh 21:26:54 Oxf13: I already mentioned that one user *did* see the bug in the latest nightlys, but he didn't tell me 21:26:55 is there any AutoQA? 21:27:14 maxamillion: I don't know. You would need to talk to autoqa folks about that. 21:27:18 kanarip: yes, there has been lots of work on the autoQA front. 21:27:19 * huff not fam with autoQA 21:27:25 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 kanarip: but it does exist --> http://fedoraproject.org/wiki/AutoQA 21:27:42 Oxf13, i know about the work, but is that doesn't answer whether it's in place or not 21:27:43 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 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 Oxf13: and we are all *very* thankful for those efforts :) 21:28:05 testing is going to be desired. 21:28:15 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 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 kanarip: right, we can't, just like we also can't depend on anything else that also isn't there. 21:28:57 "our current scope" being "the technical review of kickstarts for spins" 21:29:17 low tech might just be to ask people to test one or more nightlys and report to the spins list. 21:29:39 Spin owners should be responsible for that. 21:29:41 well rather then to "ask" which we've seen fail before, it would be to "require" 21:29:44 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 kanarip: or better yet, "do". 21:30:05 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 pjones, i'd like a pony with that please ;-) 21:30:13 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 Oxf13: it was a fully updated beta, now it's f12 21:30:39 brunowolff: if the compose environment is a clean production, it had better be. 21:30:50 we have a autotest script for ovirt node which is a livecd image 21:30:54 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 http://git.fedoraproject.org/git/?p=ovirt/node-image.git;a=blob;f=autotest.sh;h=c67931a75698698c026cf2b6455c3430ec9dd0cb;hb=51bf21fe0413ccc0f3b32219fc37305d34d23a4a 21:31:00 brunowolff: that really does have to be good enough. 21:31:05 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 brunowolff: if it isn't, we've got much bigger problems 21:31:51 I tend to have some packages not in the release installed. Typcially future updates not tagged for final. 21:31:58 huff: oh ... nice 21:32:17 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 Normally that's OK, but right before a release, it's not such a good idea. 21:33:32 Oxf13: I agree 21:33:48 Oxf13: There are also some patches to upstream koji that allow for livecd iamges to be built inside koji. 21:33:52 would it be reasonable to freeze the entire spin-kickstarts repo just like we freeze rawhide itself? 21:33:59 huff: right, that'll come later. 21:34:01 brunowolff: and that's why you should do them in mock ;) 21:34:20 kanarip: yes, it would. 21:34:25 in which case, imo, it starts getting outside of the scope of the spins sig and comes closer to rel-eng 21:34:48 the one stop shop for getting stuff tagged and pushed into fX-final, sorta speak 21:35:00 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 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 I was told so by rel-eng 21:35:19 kanarip: well, that depends. 21:35:31 cwickert, the change you made included a new package, and removed a group ;-) 21:35:38 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 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 the games spin being dropped right before the release. 21:36:03 kanarip: new packge = new in the repo package 21:36:13 Oxf13, right, but that's not the case right now is it? 21:36:34 cwickert, ah, ok 21:36:34 kanarip: no, but that's a minor detail. It could certainly become the case easily 21:37:33 so how about that? 21:37:52 I'm happy with either methodology 21:38:01 kanarip: wanna file a rel-eng ticket since its your idea? :D 21:38:11 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 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 or B) I can just work from the latest spin-kickstarts package 21:38:53 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 can you specify a tag 21:39:01 build for a tag in get 21:39:03 huff, really? 21:39:04 git 21:39:08 come on... 21:39:11 idk can you? 21:39:32 Yes, you can commit to specific branches. 21:39:41 you can create a tarball from a tag in git, yes 21:39:42 git push origin 21:39:44 and stuff that into a package 21:39:49 ... 21:39:59 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 are we talking about git now all of a sudden? ;-) 21:40:14 seems so ;) 21:40:22 I think option A (branch and freeze) is a bit better as it makes things more clear. 21:40:28 oh nice 21:40:33 kanarip owns spin-kickstarts 21:40:47 * nirik doesn't care as long as it's clearly communicated. 21:40:54 I suppose its up to kanarip then 21:40:59 I'm a neutral party in this, I can happily work with either A or B 21:41:36 Oxf13 and myself essentially had different A's and different B's 21:41:44 lol 21:41:47 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 maxamillion: I think option A allows changes to go in after freeze if need be. 21:41:51 maxamillion, what A) or what B) are you referring to? brunowolff? 21:41:51 ok, well then I vote for Oxf13's B 21:42:03 oh dear (: 21:42:16 Oxf13: look what you had to go and do ;) 21:42:19 OK we take Oxf13's A and B, please case your +1's and +0's 21:42:39 if you don't care, +1 both or +0 both 21:42:49 +1 B 21:42:54 +1 A (but can easily live with B) 21:43:02 +1 B 21:43:16 +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 +1 A (I like pulling from git) 21:43:51 +0 don't care 21:43:52 * maxamillion kinda say that coming 21:44:01 s/say/saw 21:44:08 que? 21:44:15 huff: you're git happy ;P 21:44:20 B if it helps us just decide and move on. ;) 21:44:20 nirik, it might have impact on the nightlies though, are you sure you don't care? 21:44:38 I can re-work the script I think... 21:44:50 once we freeze just have it run from the package. 21:44:57 ok, that's what i consider a wrap 21:45:19 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 #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 Where should that be documented? 21:46:37 so that happens after beta? or ? 21:46:54 alpha == new package, beta == new package, etc 21:46:54 http://fedoraproject.org/wiki/Infrastructure/CustomSpins <--- document here maybe? 21:46:59 I'll volunteer to edit the wiki if I get a suggestion as to where. 21:47:11 anything else during a freeze requires a tag request to rel-eng, correct? 21:47:28 well basically as soon as we branch 21:47:36 which in a no frozen rawhide world, happens at feature freeze 21:47:36 kanarip: that's how I understood it 21:47:43 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 Oxf13, +1 21:48:02 ok, fair enough 21:48:06 nirik, for this release cycle 21:48:18 euh... 21:48:19 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 nirik, for this *development* cycle 21:48:43 Oxf13: ah yeah... 14 hours of building...wheee! :) 21:48:51 is rawhide really relevant when we branch for the pending release? 21:48:59 nirik: yeah, or just ignore rawhide after we branched. 21:49:05 #action brunowolff will document spins sig releng handoff method 21:49:10 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 kanarip: its relevant for people who want to get started on F14 features that missed the F13 cutoff 21:49:12 either way. I can see what I can do. 21:49:14 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 #action brunowolff will document spins sig releng handoff method 21:49:28 Oxf13, fair enough 21:49:43 cwickert: feature freeze is when the pending release as a whole gets frozen, and remains frozen until we release 21:49:46 Oxf13, nirik, rawhide composes at that point have waaaaaaay lower prio though 21:49:55 cwickert: updates to the freeze will be managed by bodhi 21:50:12 kanarip: right. 21:50:23 Oxf13: I thought feature freeze was even way before alpha? 21:50:36 cwickert: I think feature deadline is way before that 21:50:42 feature freeze is a week before Alpha freeze 21:50:43 right 21:50:52 oh, nvm ... don't listen to me 21:51:11 * kanarip would love our calendaring solution to just magically work 21:51:28 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 it's a shame magic doesn't work! 21:51:35 s/IMP/IMO 21:52:02 cwickert: +1 21:52:03 cwickert: yeah, but everything else is frozen, why not spins ks? 21:52:23 nirik: +1 21:52:27 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 cwickert, it's not "freeze no changes anymore" per so 21:52:52 Are you going by the old process or the new one? 21:53:07 cwickert, it's "if you want your change" "make sure a new package is built" and "have it tagged properly" 21:53:26 brunowolff, either way, freeze requires tag to override what is in the frozen tree 21:53:44 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 cwickert, but they are composed using (maybe) newer versions of packages 21:54:16 and so there you go 21:54:24 s/tagged packages/tagged packages + tagged spin kickstarts package 21:54:24 They would be composed with what is currently scheduled to be in the release. 21:54:34 the kickstarts don't have to change to make a spin be different... 21:54:56 If something gets updated and tagged for the release, the update is going to be reflected in the next compose. 21:55:13 it makes perfect sense to me 21:55:15 kanarip: but what when the newer packages require a change to the ks? 21:55:29 cwickert, if it "requires", the change better be done in parallel 21:55:39 or you lose one or two nightly composes 21:55:46 Then you need to ask kanarip to make a new spins-kickstart package. 21:55:50 depending on the exact amount of lag, that is 21:55:53 and when is this effectively tested? 21:56:09 whenever somebody downloads the spin 21:56:11 when you download the spin or compose yourself against rawhide using the changed .ks 21:56:27 the essence of attacking the problem is to freeze 21:56:36 right, then I'm the only one to test again 21:56:40 be careful with your changes 21:56:52 kanarip: agreed, but please not before alpha 21:56:55 cwickert, this does in no way address the "need more testing" issue, that's correct 21:56:57 cwickert: who else are you expecting to test your changes? 21:57:15 all users of the nightly spins 21:57:19 i would anticipate your users may want to be willing to test some things as well 21:57:59 in the end, they're either going to be happy and satisfied participants, or just consumers whether happy or unhappy 21:58:05 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 cwickert, there is more testing 21:58:36 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 after the feature freeze you should be in bugfix only mode 21:58:49 there is more testing if you are more careful with changes 21:59:29 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 cwickert: then those upstream changes go to F14 22:00:18 unless we were building pre-releases of them into rawhide prior to the feature freeze 22:00:24 cwickert, we could have tested since 2.28 is a freeze exempting tag 22:00:39 and what Oxf13 said 22:00:57 there was 2.27 (being 2.28) for a while in rawhide before the freeze 22:01:04 grrr ... brb 22:01:12 kanarip: ok, then think of Xfce 22:01:26 I'm sure we will not have 4.8 in F13 then 22:01:33 cwickert, i don't understand this 22:01:43 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 on the one end it was the rapid change that bit the LXDE spin 22:01:55 for which we're trying to find a solution... 22:02:17 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 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 Oxf13: but are new upstream versions bugfixes or are they new features? 22:02:51 cwickert: depends on the upstream 22:02:53 cwickert: well, it's very close. 22:03:13 cwickert: and depends on the state of your package set at feature freeze vs the upstream release 22:03:23 cwickert: feature freeze is 02-09, and xfce is claiming to have a pre1 on 02-01 22:03:43 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 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 nirik: come on, you know how good Xfce is in keeping their schedule ;) 22:04:32 cwickert: perhaps it will be different this time. ;) They are much more organized. 22:05:15 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 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 maxamillion: jannis, I know him 22:05:50 cwickert: in many of those cases, dropping them would have been the right decision 22:05:51 cwickert: as upstreams did more than just fix bugs between the snapshots, which was unexpected 22:05:52 cwickert, again, not really, since the pre-release had been in rawhide some time before the feature freeze 22:05:57 cwickert: ah, cool :) 22:05:57 and last time it was nick who tried to do it 22:06:34 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 cwickert: heh 22:06:54 anyhow, we are drifting here and out of time... 22:07:00 ok, so, although we're past the hour already... 22:07:03 biertie, ping 22:07:10 #topic Spins pages 22:07:30 aha! 22:07:31 Spins pages rock! 22:07:37 done, moving on :P 22:07:46 you let them rock maxamillion 22:07:52 1) linking the current revisions on the list of prior releases 22:07:53 I just kick your ass if they don't rock! ;-) 22:08:01 yes yes 22:08:04 add actions for me ;-) 22:08:09 2) setting them back to Category Spins_in_Development as per the process 22:08:35 #action biertie: linking the current revisions of Spins Pages on each page's list of prior releases 22:08:41 biertie: hey now, why am I getting ass kickings? I was just trying to pay compliments 22:08:44 :D 22:08:58 #action biertie to add Spins pages back to Category Spins_in_Development as per the process 22:09:25 #agreed biertie to rule the Spins pages and kick their ass ;-) 22:09:46 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 #topic Open Floor 22:10:06 foomatic 22:10:17 curious why foomatic isn't there by default? 22:10:27 I've had a couple users ask this of me and I lack an answer 22:11:05 maxamillion: it might have been space related... not sure. 22:11:22 there was a thread recently on this 22:11:23 yeah, that was my first thought since the package is 34M ... but just wanted to verify 22:11:41 the printing maintainer didn't think it was still needed in a large number of cases. 22:11:41 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 and yeah, huge. 22:11:51 ah 22:12:09 ok, was just curious .... thanks :) 22:12:10 ohw well 22:12:20 i recently noticed somehow cups wasn't default anymore 22:12:27 yeah, perhaps ping twaugh about it. 22:12:33 installing cups didn't get me any drivers, so everything was generic/raw 22:12:37