========================================================================
#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-...
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