======================================================================== #fedora-meeting: FESCo Meeting - https://fedorahosted.org/fesco/report/9 ======================================================================== Meeting started by notting at 19:03:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-05-18/fesco.2010-05-18-19.03.log.html Meeting summary --------------- * init process (notting, 19:04:02) * #351 Create a policy for updates - status report on implementation (notting, 19:07:43) * #380 Approve Fedora 14 Schedule (notting, 19:11:35) * LINK: http://poelstra.fedorapeople.org/schedules/f-14/f-14-draft-schedule.html for more detail (notting, 19:21:17) * AGREED: The Fedora 14 schedule is approved. (notting, 19:26:48) * Fedora Engineering Services tickets (notting, 19:27:09) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (notting, 19:27:18) * mmcgrath having some issues with fixing upgrade paths, due to cvs content not reflecting currently built packages (notting, 19:34:58) * Open Floor (notting, 19:41:06) Meeting ended at 19:44:00 UTC. People Present (lines said) --------------------------- * notting (47) * Kevin_Kofler (41) * mmcgrath (21) * pjones (17) * dgilmore (17) * Oxf13 (15) * ajax (13) * mjg59 (8) * zodbot (7) * wwoods (6) * skvidal (4) * gholms (2) * nirik (0) * cwickert (0) Full meeting log ---------------- 19:03:18 <notting> #startmeeting 19:03:18 <zodbot> Meeting started Tue May 18 19:03:18 2010 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:03:25 <notting> #meetingtopic FESCo Meeting - https://fedorahosted.org/fesco/report/9 19:03:49 <notting> #meetingname fesco 19:03:49 <zodbot> The meeting name has been set to 'fesco' 19:03:56 <notting> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mj 19:03:56 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mj nirik notting pjones skvidal 19:03:56 <notting> g59 19:04:02 <notting> #topic init process 19:04:04 <pjones> hola, fesco. 19:04:14 * skvidal is here 19:04:17 <Kevin_Kofler> Present. 19:04:24 <dgilmore> hola 19:04:39 <mjg59> Hi 19:05:44 <notting> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 19:05:44 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mj mjg59 nirik notting pjones skvidal 19:05:54 <mjg59> Close enough 19:05:58 * skvidal is still here 19:06:34 <notting> ajax: around? 19:06:55 <ajax> notting: yeah 19:07:07 <ajax> slow, but around 19:07:19 <notting> ok. i don't see cwickert on irc, and nirik was known out. so we might as well start 19:07:43 <notting> #topic #351 Create a policy for updates - status report on implementation 19:07:46 <notting> .fesco 351 19:07:48 <zodbot> notting: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:08:13 <notting> so, on my end, we have the ticket open in rel-eng to push the new critical path stuff to bodhi, with information on how to code it 19:08:16 <notting> but the work isn't done yet 19:08:30 <Kevin_Kofler> Hopefully never will. 19:08:40 <notting> hopefully i'll get a chance to look at it once F13 is out the door and a couple other things calm down 19:09:19 <mjg59> Kevin_Kofler: Your opinion has been noted in your votes. 19:09:21 <notting> Kevin_Kofler: the policy passed. are you intending to be actively obstructionist, or just passively loud? 19:10:12 <notting> nirik was going to enter some bodhi tickets for changes... we can check on those at the next meeting he's at 19:10:13 <Kevin_Kofler> Let's call it actively loud. :-) 19:10:17 <wwoods> how about "unprofessional" 19:10:18 <notting> anyone else have further updates? 19:10:43 <dgilmore> wwoods: ill go with that 19:10:50 <dgilmore> notting: not today 19:11:24 <notting> ok then, next topic 19:11:35 <notting> #topic #380 Approve Fedora 14 Schedule 19:11:38 <notting> .fesco 380 19:11:39 <zodbot> notting: #380 (Approve Fedora 14 Schedule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/380 19:12:06 <dgilmore> +1 looks ok 19:12:16 <skvidal> +1 yay for schedules 19:12:21 <ajax> other than "planning and development begins" not accounting for NFR... 19:12:29 <notting> hm 19:12:52 <dgilmore> ajax: true that started months ago now 19:12:55 <notting> poelcat: can we move the general 'planning and development begins' part of our scheduling to the branch date of the prior release? 19:12:58 <dgilmore> well 6 weeks or more 19:12:59 <Kevin_Kofler> Alpha should be called Beta and Beta should be called Preview or RC. 19:13:13 <pjones> why is the translation deadline 3 weeks before beta? 19:13:14 <Kevin_Kofler> That renaming was what's deteriorating the quality of our releases, not updates! 19:13:24 <mjg59> [citation needed] 19:13:37 <dgilmore> on 2010-07-27 planning and development for F-15 starts 19:13:38 <Kevin_Kofler> It leads to developers delivering late. 19:14:13 <Kevin_Kofler> We should match the established terminology of projects like KDE. 19:14:23 <wwoods> we changed it to match industry standards 19:14:24 <pjones> of course it should. 19:14:33 <Kevin_Kofler> They use Beta for what we now call Alpha and RC for what we now call Beta. 19:14:43 <wwoods> everyone else in the industry uses Alpha for what we now call Alpha 19:14:47 <wwoods> and Beta for what we now call Beta 19:14:52 <wwoods> except, apparently, KDE 19:15:13 <wwoods> Your opinion is noted, has been previously considered, and thoughtfully discarded 19:15:22 <ajax> i echo pjones' concern about the translation and beta dates being so far apart 19:15:41 <Kevin_Kofler> They feature freeze for Beta, not Alpha. They don't even have an Alpha anymore (for similar reasons as why we dropped our old Alpha, I guess). 19:15:41 <ajax> but it looks broadly okay to me 19:15:58 <mjg59> Kevin_Kofler: What we have at beta is clearly not of RC status 19:16:00 <pjones> it seems like those could be... I dunno, 2 or 3 days apart. 21 seems excessive. 19:16:04 <mjg59> And wouldn't be even if we changed the name 19:16:05 <notting> pjones: it's one week before the beta freeze 19:16:11 <notting> pjones: gives a week for builds 19:16:34 <Kevin_Kofler> mjg59: It is in KDE's definition of "RC". 19:16:47 <ajax> notting: i don't see "beta freeze" on there, only "beta release 19:16:50 <dgilmore> notting: perhaps we need to add the beta freeze date in there 19:16:59 <pjones> notting: I guess that just makes me wonder why beta freeze isn't on there. 19:17:05 <Kevin_Kofler> (Their schedule has 2 planned RCs and final a month after RC2.) 19:17:07 <notting> not sure. poelcat? 19:17:42 <dgilmore> Kevin_Kofler: please be quiet unless you are adding usefully to the conversation. right now your noise is not useful 19:17:53 <mjg59> Kevin_Kofler: How much code change is there between RC1 and final? 19:18:09 <dgilmore> Kevin_Kofler: if you think its so broken please feel free to put forward a fully written out proposal with a new way to do it 19:18:39 <Kevin_Kofler> mjg59: All bugfixes which don't change strings are allowed. 19:18:48 <mjg59> Kevin_Kofler: Yeah, see, that's not an RC 19:18:54 <notting> pjones: ajax: oh. with no frozen rawhide, there's not a freeze, per se 19:19:06 <notting> which is probably why it's not on the schedule 19:19:09 <dgilmore> notting: so im +1 but lets make clear the actual development start date and get beta freeze added 19:19:15 <ajax> notting: for a release? mmm. 19:19:19 <pjones> notting: in which case... why is string deadline 3 weeks before beta? ;) 19:19:31 <dgilmore> notting: the freezes are really a bodhi management step 19:19:35 <Kevin_Kofler> There's still a Beta freeze on the release branch AIUI. 19:19:50 <notting> Oxf13: do you have poelcat's detailed milestone page? 19:19:54 <pjones> yeah, I think there's really still a beta freeze, and it ought to be on the schedule. 19:19:54 <Kevin_Kofler> And yes, it makes sense to have some time to build translations, so we need to request them from translators before the freeze. 19:19:59 <dgilmore> pjones: 1 week before the beta freeze that does exist 19:20:17 <ajax> i suppose it depends when F15 branches 19:20:30 <ajax> or when devel becomes F-14/, or whatever 19:20:34 <pjones> ajax: 2010-07-27 19:20:40 <dgilmore> it gives us a week to stabalise the tree make an installable product and get it staged and out to the mirrors 19:20:44 <pjones> 4.5th album on the list. 19:20:47 <pjones> er 19:20:49 <pjones> item 19:20:50 <pjones> not album. 19:20:57 <ajax> Fedora's Greatest Hits 19:20:58 <pjones> (hey, those words sound kindof alike...) 19:21:06 <Oxf13> ti's a freeze sortof 19:21:08 <ajax> track 2: Kudzu 19:21:09 <notting> n, found it 19:21:17 <notting> http://poelstra.fedorapeople.org/schedules/f-14/f-14-draft-schedule.html for more detail 19:21:18 <Oxf13> we freeze things that hit the stable tree, but we don't freeze things that hit updates-testing 19:21:40 <dgilmore> Oxf13: right hence my bodhi management comment above 19:21:52 <dgilmore> the freezes are really a bodhi management step 19:22:04 <ajax> anyway. i'm asking only for details i suppose. the schedule looks fine. +1/ 19:22:05 <notting> i've added 'compose alpha candidate' and 'compose beta candidate' to the F14/Schedule page. those correspond most closely to the prior definition of 'freeze' 19:22:53 <pjones> well, if there's really a beta freeze, and we want string deadline a week before it, that's fine. If there's really not, I'd rather string freeze and string translation deadline be moved up to be more proximate to beta release. 19:23:18 <notting> Oxf13: or, perhaps we should word it as 'beta change deadline'? 19:23:20 <pjones> notting: okay, that'll do 19:24:07 * notting is +1 on the schedule in general, fwiw 19:24:08 <Oxf13> notting: that works for me I suppose. 19:24:32 * pjones wishes the schedule were longer, but thinks that's probably not the purpose of this discussion, so is vaguely +1 to this schedule. 19:24:33 <Oxf13> basically we'll take things into stable until we're ready to compose the candidate 19:24:55 <Oxf13> once we've composed the candidate, then we won't take anything until the candidate is either found acceptable for release, or found lacking and in need of some change 19:25:10 <Oxf13> if it needs change, we would only be taking things necessary to make it acceptable 19:25:28 <Oxf13> it is longer, if you consider that rawhide has been open and published for 3 months already 19:25:50 <Oxf13> which is significantly better than previous release cycles. 19:25:57 <Kevin_Kofler> I vote +1 to this schedule, I don't see any reason not to (other than the wording which isn't really the point of this discussion). 19:26:12 <Kevin_Kofler> (And I had already proposed changing it and it was shot down.) 19:26:28 <notting> that's 6 +1, so the schedule has passed. 19:26:48 <notting> #agreed The Fedora 14 schedule is approved. 19:27:09 <notting> #topic Fedora Engineering Services tickets 19:27:18 <notting> https://fedorahosted.org/fedora-engineering-services/report/6 19:27:48 <notting> mmcgrath: any updates? (as nirik isn't here) 19:27:54 <mmcgrath> hey 19:28:05 <mmcgrath> We got a new volunteer I've been trying to find work for 19:28:16 <mmcgrath> we'v ejust about got all of the FTBFS tickets assigned. 19:28:27 <mmcgrath> I'm going to continue working on the upgrade path breakage. 19:28:38 <mmcgrath> Interesting note, the upgrade path breakage has been far more difficult to fix then the broken deps stuff. 19:28:47 <mmcgrath> it seems a lot of our contributors work in cvs in real time 19:28:56 <mmcgrath> but only actually make packages when they feel like it. 19:29:11 <mmcgrath> so it's hard for me (non maintainer) to figure out what the maintainers are actually up to. 19:29:24 <mmcgrath> This is likely going to be me doing more nagging then fixing unfortunately. 19:29:27 <mmcgrath> at least for now. 19:29:41 <Kevin_Kofler> In my experience, nagging is highly ineffective. 19:29:54 <mmcgrath> that's why it's unfortunate. 19:29:59 <Kevin_Kofler> Most maintainers don't give a darn about upgrade paths and will outright refuse to push an update to bump an EVR for upgrade paths. 19:30:10 <Kevin_Kofler> Or just not respond to a bug asking so. 19:30:31 <mmcgrath> but we're talking about stuff like version 1.2 is in F12, 1.3 is in F13, and 2.0 is currently committed in cvs to F12 and F13 but not built or anything 19:30:34 <Kevin_Kofler> I had filed bugs for such issues, IIRC F8→F9, some never got fixed until the F9 EOL. 19:30:35 <mmcgrath> so I have no idea what to make of that. 19:30:44 <notting> odd. i usually only change something in CVS as a part of doing a build. guess i'm not the normal case. 19:31:01 <Kevin_Kofler> notting: Same here. 19:31:07 <gholms> ^ That's what I usually do. 19:31:11 <mmcgrath> notting: same here, that's why I went in all gung ho thinking "hey! I can get through this and get it all working in F13 updates at least" boy oh boy was I wrong :) 19:31:16 <Kevin_Kofler> It's quite lame to update CVS and then not use what you committed. 19:31:28 <Oxf13> that depends 19:31:34 <mmcgrath> I'm not sure if maybe that's how they're collaborating for a release or what. 19:31:44 <Oxf13> if it's a minor fix, or a typo or whatever, one can commit them to cvs and wait for a real reason to spin an update 19:31:56 <Oxf13> then your update will be a build up of minor changes + the one important change 19:31:59 <notting> Oxf13: sure. but if it's that minor, i'm only committing it in devel/ 19:31:59 <mmcgrath> notting: anywho, that's all I've got. I haven't gone through all of those packages yet so I'm just going to keep going down the list trying to fix ones I can 19:32:01 <skvidal> notting: that's what I do, too 19:32:11 <Oxf13> notting: yeah 19:32:51 <mmcgrath> but it could be one of those deals where they've been trying to get a build going of the new version but have run into blockers. 19:33:07 <mmcgrath> and if the maintainers haven't fixed it, I'm probably not going to be able to either. 19:33:16 <Kevin_Kofler> Re committing only to devel, I do that too, and the next time I want to update, I just copy all of devel to the branches. 19:33:17 <mmcgrath> but we'll see. I guess it's just a case by case thing. 19:33:29 <Kevin_Kofler> That way all the branches will pick up the fixes from devel in the next update. 19:33:46 <Kevin_Kofler> (Unless there's a reason to keep the branch on an older version. My policy is to upgrade unless there's a good reason not to.) 19:34:32 <Oxf13> maybe dist-git will help and people will make use of staging branches 19:34:55 <Kevin_Kofler> Oxf13: I still think build branches are more useful. 19:34:57 <Oxf13> commit stuff into a staging branch, merge it with the live branch for said release when they're ready to do an official build 19:34:58 <notting> #info mmcgrath having some issues with fixing upgrade paths, due to cvs content not reflecting currently built packages 19:35:01 <pjones> Kevin_Kofler: we know that's your policy, even though all of the rest of us disagree with it. We haven't forgotten. 19:35:19 <Kevin_Kofler> I.e. develop on trunk, but branch a known good release to make builds of. 19:35:37 <Kevin_Kofler> And this is actually possible in CVS (using arcane CVS hackery), I've done it at times, the kernel folks as well. 19:36:08 <Kevin_Kofler> (And I don't mean the F-* branch directories, but actual CVS branches within them.) 19:36:42 <Kevin_Kofler> BTW, this approach might be useful for some of the upgrade path fixes. 19:36:46 <notting> other comments on the current FES tickets? 19:37:10 <Kevin_Kofler> mmcgrath: If you need any help with branching build branches in CVS, just ask. 19:37:23 <mmcgrath> Kevin_Kofler: danke 19:37:27 * mmcgrath has no other comments 19:37:58 <gholms> Kevin_Kofler: I'd be interested in hearing about how those work, too. 19:38:56 <Kevin_Kofler> Basically, you need to do something like: 19:38:58 <Kevin_Kofler> cvs tag -b -r kdenetwork-4_4_2-2_fc13 kdenetwork-4_4_2-x_fc13 19:39:14 <Kevin_Kofler> (the branch name is chosen to fool our serverside tag validator into thinking it's a valid tag :-) ) 19:39:27 <Kevin_Kofler> But this will only branch files which are active in trunk. 19:39:41 <Kevin_Kofler> For files deleted in trunk, you need to branch those explicitly, e.g.: 19:39:46 <Kevin_Kofler> cvs tag -b -B -F -r kdenetwork-4_4_2-2_fc13 kdenetwork-4_4_2-x_fc13 kdenetwork-4 19:39:46 <Kevin_Kofler> .4.2-qt47.patch kdenetwork-4.4.2-kopete_yahoo_kdebug226699.patch 19:40:09 <Kevin_Kofler> -B -F is the magic to change branch tags. 19:40:22 <Kevin_Kofler> So you can tag stuff into the branch after the fact. 19:40:47 <Oxf13> another channel please 19:40:52 <dgilmore> Kevin_Kofler: take it elsewhere this is not teh right place or time 19:40:55 <ajax> anything else on the fesco agenda? 19:41:01 <notting> nope 19:41:01 <Kevin_Kofler> dgilmore: I'm done anyway. :-) 19:41:06 <notting> #topic Open Floor 19:42:43 <notting> if there's nothing, i'll close the meeting in 1 minute 19:43:58 <notting> ok then. thanks everyone. 19:44:00 <notting> #endmeeting -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
