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