Minutes/Summary from today's FESCo meeting (2010-09-28)
kevin at scrye.com
Tue Sep 28 21:37:36 UTC 2010
#fedora-meeting: FESCO (2010-09-28)
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
* init process (nirik, 19:30:01)
* Kylem unable to attend meetings in this timeslot (nirik, 19:34:28)
* LINK: http://whenisgood.net/ee8prq/results/z5binx (nirik,
* AGREED: try and find a new time, revisit next week. (nirik,
* Updates policy / Vision implementation status (nirik, 19:43:23)
approved (nirik, 19:58:14)
* ACTION: nirik will announce new policy (nirik, 20:00:58)
* http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik,
* LINK: http://fedoraproject.org/wiki/Releases/15/Schedule (nirik,
* LINK: https://fedoraproject.org/wiki/Releases/15 (drago01,
* #469 App install related issues (nirik, 20:12:46)
* AGREED: ship the package and agree to switch to the repodata version
if/when. (nirik, 20:54:57)
* #467 Make Feature Freeze happen sooner. (nirik, 20:59:32)
* revist next week, ask submitter for a concrete thing to vote on
* #471 FPC Draft for Ratification (nirik, 21:24:19)
* LINK: https://fedorahosted.org/fpc/ticket/12 although hey-o tl;dr
* AGREED: this is approved (nirik, 21:31:10)
* Open Floor (nirik, 21:31:13)
Meeting ended at 21:35:19 UTC.
* nirik will announce new policy
Action Items, by person
* nirik will announce new policy
People Present (lines said)
* nirik (150)
* pjones (109)
* hughsie (74)
* skvidal (63)
* ajax (52)
* mjg59 (51)
* notting (37)
* Oxf13 (29)
* SMParrish (21)
* mclasen (20)
* geppetto (16)
* zodbot (11)
* drago01 (11)
* cwickert (9)
* jsmith (2)
* lmacken (1)
* kylem (0)
19:30:01 <nirik> #startmeeting FESCO (2010-09-28)
19:30:01 <zodbot> Meeting started Tue Sep 28 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:28 <pjones> good lord, my local machine's time drifts a lot.
19:31:01 <nirik> time flies when you're having fun? ;)
19:31:17 <mjg59> Afternoon
19:31:44 <pjones> problem seems to be that it can't talk to anything that's part of fedora.pool.ntp.org
19:31:48 <pjones> oops
19:31:51 * nirik waits for folks to wander in.
19:31:56 * notting is here
19:32:09 <notting> nirik: should we handle kylem's situation as a first item?
19:32:17 <nirik> notting: yeah, likely so.
19:32:25 * SMParrish here
19:32:59 <nirik> ok, thats 5 of us, so I guess we could go ahead and start in.
19:33:13 <mjg59> ajax ought to be around
19:33:27 <ajax> he is.
19:33:28 <nirik> mclasen was just around in devel.
19:33:46 <mclasen> I'm here, no ?
19:34:04 <nirik> yeah, just didn't see if you were active. ;)
19:34:28 <nirik> #topic Kylem unable to attend meetings in this timeslot
19:34:32 * hughsie is here too
19:34:40 <nirik> so, kylem has a conflict with this time for the next 10 weeks.
19:34:50 <pjones> so, the problem is kylem has class on tuesday afternoons?
19:34:58 <pjones> that is, it's not just this timeslot, right?
19:35:02 <nirik> we could try and move the meeting time, but as I recall we had not much choice for times everyone could make.
19:35:05 <nirik> yes.
19:35:26 <notting> have other people's availability changed since we first did this?
19:35:31 <mclasen> we could just rescan for another time ?
19:35:48 * mclasen has had some variation in afternoon unavailability
19:35:52 * nirik is available most times (still)
19:35:54 <mjg59> Ok
19:36:02 <pjones> I think it mostly depends on mclasen? though the later parts of tuesday afternoon are now available for me (and monday has become less available)
19:36:08 <mjg59> Maybe we should do another run of scheduling and see if we can improve things
19:36:13 <pjones> sounds like it
19:36:27 <nirik> I could possibly dig up the old one and people could just adjust it.
19:36:36 <SMParrish> I have some flexibility
19:36:37 <pjones> yeah
19:36:50 <mclasen> nirik: sounds like its worth a try
19:37:21 <nirik> it seems to be gone. ;(
19:37:51 <nirik> oh wait.
19:37:53 <nirik> http://whenisgood.net/ee8prq/results/z5binx
19:38:38 <nirik> could folks adjust what they had there? I can mail everyone to ask for updating and we can revisit next week?
19:38:50 <mjg59> nirik: Sounds good
19:39:15 <pjones> I've forgotten - why isn't the 10am timeslot (EST5EDT) even listed there?
19:39:34 <nirik> If we can't change the time and kylem has to step aside, I'll note that bruno is the next highest vote getter in the last election.
19:39:52 <nirik> pjones: not sure.
19:40:04 <pjones> I think that'd be an incredibly poor thing to do.
19:40:04 <nirik> that would be 8am for me tho.
19:40:29 <pjones> okay, so it would suck for you. still seems weird that I can't select it, but okay.
19:40:46 * mclasen could do 6am-7am most days :-)
19:41:08 <pjones> mclasen: ... which would be 4am-5am for nirik ;)
19:41:12 <nirik> I think I adjusted it to add that.
19:41:30 <nirik> I guess depending on the day, I could just pull an all nighter. ;)
19:41:32 <notting> mclasen: well, if we're getting that silly, mmm, 12am edt
19:42:07 <pjones> okay. I don't think we're going to get meaningful results at least until kylem gets out of class today.
19:42:08 <nirik> proposed: try and find a new time, revisit next week?
19:42:11 <mjg59> +1
19:42:12 <nirik> yeah.
19:42:35 <pjones> +1
19:42:44 <ajax> +1
19:42:47 <SMParrish> +1
19:42:55 <nirik> #agreed try and find a new time, revisit next week.
19:43:19 <nirik> ok, moving along.
19:43:23 <nirik> #topic Updates policy / Vision implementation status
19:43:24 <nirik> .fesco 351
19:43:24 <nirik> .fesco 382
19:43:24 <nirik> .fesco 454
19:43:25 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:43:28 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:43:32 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454
19:43:38 <pjones> I'm guessing you mis-pasted there.
19:43:55 <nirik> pjones: Just pulling all these tickets under one topic.
19:44:00 <pjones> Oh, okay.
19:44:04 <pjones> reasonable enough
19:44:11 <nirik> I posted https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft to the list last week.
19:44:17 <nirik> I tried to pull in all feedback I could.
19:45:13 <mclasen> do we vote on this ? it looks great to me
19:45:34 <nirik> we can. If everyone could look it over and see if there's anything we should fix/change that would be great...
19:45:46 <ajax> diffs between last week and now: https://fedoraproject.org/w/index.php?title=User%3AKevin%2FUpdates_Policy_Draft&diff=199095&oldid=197190
19:46:19 <nirik> I added a kde example that I was unsure of how to word.
19:47:22 <mjg59> I think this version looks good
19:47:23 <mclasen> looking at the diff, on thing that might be worth mentioning is that there is an updates-testing repo for branched releases, but no -updates (since you mentioned this for rawhide)
19:47:56 <pjones> I'm for this version, though it may still need some tweaking later depending on the practical response to it, as always.
19:47:59 <ajax> yeah, i'm pretty happy with this draft.
19:48:23 <SMParrish> It looks good to me
19:48:24 <nirik> mclasen: yeah, sounds good to add...
19:49:34 <nirik> perhaps a "repos available:" point... so "repos available: base" for rawhide, then 'repos available: base updates-testing" for part of branched, then 'repos available: base updates updates-testing" before release, etc.
19:49:45 <notting> looks reasonable. i'm still concerned that the discussion of the initial posting seems to highlight that the KDE sig (or many of its members) seem to disagree with the vision set down from the board entirely. not sure how we rectify that even with an occasional exception
19:50:47 <drago01> one question does the "Interoperability" section include drivers? (i.e adding support for a new chipset etc)
19:50:48 <ajax> i think the obvious answer is "they get their own release schedule", but that idea's not flown well in the past.
19:50:50 <nirik> yeah, its a sad situation.
19:51:04 <ajax> drago01: the examples were mostly hardware support packages, yes.
19:51:13 <pjones> ajax: or "they get their own repo"
19:51:27 <SMParrish> notting: nothing we do will change some peoples opinions of the board's vision, but the majority of the KDE SIG can work within the guidelines
19:51:27 <pjones> which does have its own downsides.
19:51:43 <drago01> ajax: ok
19:52:01 <nirik> SMParrish: yeah, I wish there was a way for us to better accomodate the kde schedule. ;( I'm trying to come up with ways... but it's not an easy issue.
19:52:09 <pjones> drago01: and remember, exceptions can always happen - we just want to be sure there's a good reason
19:52:38 <nirik> I think we will need to run with this for a cycle or two and then adjust it based on how it went...
19:52:43 <pjones> nirik: yep
19:52:44 <drago01> pjones: fair enough (just wanted to make sure I understood it correctly)
19:53:06 <SMParrish> nirik: Its not an easy issue and I dont really see how we can adjust to meet KDE's schedule without messing with Gnomes
19:53:19 <drago01> there is one way
19:53:32 <drago01> just release the kde spin later
19:53:39 <ajax> that's what i said, yes.
19:53:40 <nirik> ok, so if we approve this, do we need the https://fedoraproject.org/wiki/Package_update_acceptance_criteria still to exist? or does that still hold info thats needed?
19:54:09 <notting> SMParrish: ok. it's just the 'one exception per release' idea doesn't seem to me to be within the guidelines. it's a compromise.
19:55:06 <ajax> nirik: i think that page becomes redundant
19:55:18 <SMParrish> notting: That may be true, but the only other choice is to be so strict in the policy that we will disinfranchise people
19:55:21 <nirik> it has autoqa info I guess...
19:56:26 <nirik> I could try and add that in and make sure it has all the info...
19:56:39 <nirik> do we want to wait for me to do that? or vote on the draft as it is now?
19:56:57 <notting> i think we can vote on it as is
19:57:24 <pjones> I think we can vote on it as is, then we can vote on changes later just for the sake of simplicity.
19:57:35 * nirik is +1 for the draft. I hope it incorporates the board vision and valuable feedback from our maintainers.
19:57:35 <mjg59> Yeah
19:57:41 <mjg59> +1
19:57:43 <mclasen> +1
19:57:45 <SMParrish> +1
19:57:46 * notting is +1
19:57:51 <ajax> +1
19:57:57 <pjones> +1
19:58:14 <nirik> #agreed https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft is approved
19:58:26 <nirik> Shall I try folding in changes before announcing it?
19:58:39 <ajax> changes?
19:58:52 <ajax> oh, the autoqa stuff?
19:58:55 <nirik> any autoqa and other info from the https://fedoraproject.org/wiki/Package_update_acceptance_criteria page
19:59:09 <pjones> nyet.
19:59:42 <nirik> ok, so announce to devel-announce? any other places?
19:59:47 <ajax> whichever i guess? if you're just pulling in links to other stuff then it doesn't really matter.
19:59:52 <mjg59> Should probably Cc: devel
19:59:58 <mjg59> Maybe test-list?
20:00:06 <pjones> If you're just doing see also: [links], then, well, whatever.
20:00:16 <pjones> mjg59: shouldn't all those people be on devel-announce?
20:00:19 <mjg59> People might be interested in seeing why things don't move
20:00:19 <nirik> devel-announce cc's devel, and test-announce cc's test.
20:00:22 <mjg59> pjones: You'd think
20:00:54 <pjones> okay, so the two -announce lists is sufficient.
20:00:58 <nirik> #action nirik will announce new policy
20:01:05 * skvidal turns on his mail filters
20:01:22 <nirik> ok, also on updates... any news on metrics?
20:02:10 <SMParrish> Nothing new from me on metrics. Been a bit distracted this week
20:03:03 <nirik> ok.
20:03:45 <nirik> anything more on updates? or shall we move on? For the tickets, we are waiting on autoqa for one, and the rest of the board vision implementation stuff on the other, can we close the pre-release one?
20:04:13 <mjg59> nirik: Sounds good to me
20:04:14 <ajax> i think we can close the prerelease one
20:04:22 <nirik> ok
20:05:10 <nirik> moving on then.
20:05:18 <nirik> #topic http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
20:05:19 <nirik> .fesco 434
20:05:20 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434
20:05:22 <nirik> any news here?
20:05:33 <nirik> or should we just defer longer term until there is news?
20:05:55 <ajax> who had the followup task on this from last week, mclasen?
20:05:57 <mjg59> dcbw's been talking about implementing this, but I still haven't seen it being handled with the feature proponents
20:07:26 <nirik> yeah, we need those two groups to sit down and hash things out.
20:08:51 <notting> given the feature submission deadline, i don't see we need to lock them in a room just yet
20:09:07 <nirik> yeah, so defer until there is new news?
20:09:14 <nirik> we don't want it to get dropped on the ground tho
20:09:42 <mjg59> Right
20:10:25 <nirik> ok, I guess I will ping owners and we can keep checking back in meeting.
20:10:25 <ajax> remind me what the f15 schedule is? http://fedoraproject.org/wiki/Releases/15/FeatureList is giving me a bad link to it
20:10:50 <nirik> doesn't seem to exist yet. ;)
20:10:52 <nirik> http://fedoraproject.org/wiki/Releases/15/Schedule
20:10:55 <drago01> https://fedoraproject.org/wiki/Releases/15
20:11:20 <notting> hasn't been proposed yet
20:11:26 <notting> (i think)
20:11:37 * cwickert rushes in late
20:11:50 <nirik> welcome cwickert
20:11:57 <ajax> well, defer until whenever i guess. if we haven't heard anything by whenever the "submission deadline" ends up being, i'd be a little cautious about acceptance.
20:12:05 <nirik> yeah.
20:12:18 <nirik> ok, moving on then unless someone has something more...
20:12:19 <pjones> cwickert: you should make sure your times are up to date at http://whenisgood.net/ee8prq/results/z5binx - we're probably going to need to reschedule again.
20:12:46 <nirik> #topic #469 App install related issues
20:12:47 <nirik> .fesco 469
20:12:51 <zodbot> nirik: #469 (App install related issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/469
20:13:13 <nirik> this is a heated topic. :)
20:13:16 <nirik> hughsie: you still here?
20:13:23 <nirik> skvidal / geppetto: you guys?
20:13:26 <hughsie> nirik: am indeed
20:13:30 * skvidal ishere
20:14:15 <ajax> so, since this is way into my SEP field, let me see if i understand
20:14:19 <nirik> so, what exactly do you guys want fesco to decide here? if the package that has the data is allowable in fedora, or if we require this be in repodata? or ?
20:14:36 <skvidal> nirik: the pkg was put up for review to be included in fedora
20:14:45 <ajax> we want some metadata about the packages for UI purposes, and the question is about where to put that metadata. yes?
20:14:46 <skvidal> the pkg containing the metadata - not the program
20:15:08 <hughsie> ajax: correct. i proposed to use the same standard ubuntu and suse are using
20:15:20 <skvidal> we're arguing that metadata/repodata should not be in pkgs in the distro
20:15:23 <skvidal> but it should be in the repodata/
20:15:59 <ajax> as a ballpark thing, how much data does this end up being?
20:16:11 <skvidal> ajax: over time or on a single run?
20:16:12 <hughsie> ajax: about 5mb
20:16:21 <skvidal> hughsie: compressed or uncompressed?
20:16:25 <ajax> skvidal: either, and either.
20:16:26 <hughsie> very compressed
20:16:43 <skvidal> ajax: the data will increase with other repos and with our updates
20:16:49 <hughsie> skvidal: no
20:16:57 <hughsie> skvidal: we always use the latest packages
20:17:04 <skvidal> hughsie: and we add pkgs to a release
20:17:08 <pjones> well, that sounds like a question you guys should agree on the answer to before we vote.
20:17:10 <skvidal> so the data will increase in size
20:17:11 <hughsie> and the other repos will ship thier own data in the rpmfusion-release files
20:17:13 <nirik> ubuntu seems to just ship all the desktop files and icon files in theirs.
20:17:30 <hughsie> skvidal: sure, but in an application installer we just install the latest version
20:17:43 <mjg59> hughsie: How does this work in terms of maintaining consistency as new packages appear in updates-testing and migrate through to updates?
20:17:44 <skvidal> hughsie: we add pkgs to updates
20:17:45 <drago01> pjones: the reason why they wanted fesco is because they obviously couldn't come to an agreement
20:17:47 <hughsie> nirik: sure, they want to get away from this, and to the database format i proposed
20:18:20 <hughsie> mjg59: well, new packages don't appear in the app browser until somebody manually refreshes the data. the logic is we only want to show the popular packages anyway
20:18:29 <pjones> drago01: agreeing on the facts vs agreeing on if this is a reasonably good idea are two different things; if the facts can't be agreed on, bringing it to FESCo is probably the wrong action.
20:18:37 <nirik> hughsie: where would they refresh from?
20:18:52 <ajax> i guess i have difficulty seeing the difference, in user experience terms, between "time to download a 5M package and install it so i can tell you stuff" and "time to download 5M of repodata so i can tell you stuff"
20:18:53 <nirik> a update to the metadata package?
20:18:54 <hughsie> nirik: the person preparing the %foo-release package
20:19:11 <hughsie> ajax: the package would be on the live cd already
20:19:17 <hughsie> i.e. no downloading
20:19:17 <pjones> ajax: presumably the expectation is that an outdated version of the package is usually fine? ;)
20:19:22 <skvidal> hughsie: the repodata is too
20:19:23 <hughsie> pjones: correct
20:19:24 <nirik> hughsie: the metadata could be as well.
20:19:31 <pjones> which sounds pretty silly to me, but...
20:19:54 <ajax> eh. the web does that model quite well. you're always looking at a snapshot of the past.
20:20:01 <geppetto> nirik: It must be … we need primary/etc. already
20:20:03 <hughsie> pjones: not at all -- if you generate the metadata for f13 there's not a single package that changes basename in the release that doesn't obsolete its old name
20:20:34 <geppetto> ajax: Being in the past is fine … as long as you are consistent … this would be more like having one version of primary.xml and another of filelists.xml
20:20:38 <hughsie> pjones: sure, for new packages we don't include them until we refresh, but ubu just refresh the data every 6 months or so
20:20:54 <pjones> hughsie: please, please stop telling me what ubuntu does.
20:21:09 <hughsie> pjones: it's important, as it already works for them
20:21:09 <pjones> it makes me hate your argument on not-the-merits, which is probably not ideal.
20:21:12 <mjg59> hughsie: What's the mechanism for integrating data from external repositories?
20:21:19 <ajax> geppetto: that sounds like a pretty strong statement. i see what you're getting at but i think the issues you're concerned with may not matter for this.
20:21:28 <ajax> i mean
20:21:45 <ajax> if i show an old icon, whatever. that's not a functional problem.
20:21:51 <skvidal> ajax: it matters if a pkg is added to updates and it doesn't show up at all
20:21:53 <hughsie> mjg59: each repo ships it's own .db and gz files in the -release.rpm file, and in the %post script a command is called that merges the data into the system store. the reverse for rpm removal
20:21:58 <skvidal> ajax: b/c it is not in the current metdata
20:22:22 <skvidal> hughsie: so we'd never have one for updates b/c we don't ship a fedora-updates-release.rpm, right?
20:22:28 <geppetto> ajax: There are _lots_ of things in filelists that nobody would notice if they were wrong … but being wrong, for no good reason, is still not a good idea IMO
20:22:40 <SMParrish> skvidal: the package would still show up and be installable just not be in the applications list, is that right hughsie
20:22:50 <hughsie> skvidal: i'm just gerneating the fedora-app-install package from fedora+updates at the moment
20:23:03 <hughsie> SMParrish: right
20:23:03 <pjones> skvidal: we could (in theory) ship an updated version of this package every time we add anything to the packageset, but that sounds like one more thing to drop on the floor by accident.
20:23:04 <geppetto> ajax: I could understand (but probably still disagree with) the argument of being a bit wrong … if we got something out of it, but we don't
20:23:07 <skvidal> SMParrish: right - so if the application is just showing apps in that repodata - then it won't show up at all
20:23:16 <skvidal> pjones: and isn't that the POINT of the repodata?
20:23:45 <skvidal> pjones: remember redhat-rpmdb?
20:23:50 <skvidal> (or was it rpmdb-redhat)
20:24:03 <SMParrish> skvidal: but if the new app performs like the new kpackagekit the user can search for a package by name just like today, its just another way to present the data
20:24:03 <pjones> I do remember rpmdb-redhat.
20:24:26 <mjg59> hughsie: I kind of dislike that this approach effectively means that nothing in updates-testing can be offered to users until it's migrated and the data has been regenerated
20:24:35 <skvidal> pjones: this is rpmdb-redhat but with special data
20:24:44 <geppetto> pjones: Also note that F-13 has 312 packages that weren't there at GA (updateinfo new) … so this isn't something that doesn't happen much
20:24:46 <skvidal> pjones: just out of curiosity - how often did rpmdb-redhat get updated?
20:24:59 <mjg59> hughsie: That's potentially something that we'd be willing to deal with in the main repository, but it seems to limit third party sources
20:25:00 <hughsie> basically, the problem of putting thing in the repodata is I would have to sent somebody two files every time i refreshed the app-install data, and they would manually have to add it to the repomd.xml data. this doesn't work for repos like livna very well.
20:25:20 <skvidal> hughsie: manually add it?
20:25:28 <pjones> skvidal: http://fr2.rpmfind.net/linux/rpm2html/search.php?query=rpmdb-redhat you tell me.
20:25:29 <skvidal> hughsie: why?
20:25:29 <hughsie> mjg59: no, repos like rpmfusion can generate thier own app-install data very easily
20:25:41 <geppetto> hughsie: Why do you have to be involved for any of the repos?
20:25:45 <hughsie> skvidal: so it gets pushed to the mirrors
20:25:48 <pjones> skvidal: I do see your point, though I'm not sure that's a great analogy
20:25:48 <mjg59> hughsie: Yes, but if they adopt the same strategy as us (updates-testing is gated), you *can't* generate against udpates-testing
20:25:50 <skvidal> pjones: that's hilarious :)
20:25:52 * nirik is having a hard time seeing the advantages to the 'package it' side. re-reads https://bugzilla.redhat.com/show_bug.cgi?id=488968#c36
20:26:13 <mjg59> hughsie: Unless you tie every package migration to the app data
20:26:14 <hughsie> mjg59: how do you mean "gated"?
20:26:18 <pjones> yeah, I'm still not seeing how this isn't specspo rehashed
20:26:45 <SMParrish> Does that package as proposed violate any packaging guidelines?
20:26:53 <hughsie> pjones: because the data is automatically generated from the packages themselves, not translators pushing translations into an external package
20:26:55 <mjg59> hughsie: Two new packages get uploaded to updates-testing. appinstall-data gets generated. One of those new packages gets enough karma to move to updates, the other doesn't. When does the appinstall-data migrate?
20:27:13 <ajax> SMParrish: i don't believe so. mostly a taste thing.
20:27:19 <skvidal> SMParrish: the license tag makes me sick inside
20:27:23 <nirik> ok, we are at 15min here. Votes to continue discussion?
20:27:25 <skvidal> SMParrish: does that count?
20:27:27 <notting> pjones: specspo's main failure was no one wanted to do the translation data. there's no manual task involved here.
20:27:27 <hughsie> mjg59: new packages are not that interesting. new packages won't have enough users to be rated highly enough.
20:27:32 <skvidal> SmootherFrOgZ: look at the license tag
20:27:34 <notting> pjones: at least, not of that scale
20:27:34 * nirik is +1, hopefully we can figure this issue out.
20:27:39 <hughsie> skvidal: the licence would be the same in the repodata
20:27:42 <mjg59> hughsie: Right, that's what I said about policy
20:27:45 <SMParrish> +1
20:28:01 <ajax> +1 continue, but not twice.
20:28:09 <hughsie> as I see it, the package doesn't actually violate any guidelines
20:28:30 <mjg59> hughsie: Your approach requires that third party sources follow the same appinstall policy as we do. They may not want to do that.
20:28:38 <pjones> notting: well, there's a manual task of updating it - presumably the idea here is to automate that, though. so the question is: what events trigger a rebuild? how often? why's a package better than another file in repodata?
20:28:40 * nirik doesn't think the package violates any guidelines.
20:28:46 <pjones> notting: none of which have been suitably answered AFAICS
20:28:52 <skvidal> nirik: is that our only criteria?
20:28:54 <hughsie> mjg59: then apps that they ship don't get included in our nice shiny application installers
20:28:59 <nirik> skvidal: I sure hope not. ;)
20:29:10 <mjg59> hughsie: That sounds like a pretty significant limitation!
20:29:24 <pjones> hughsie: so, those questions I just raised - do they have answers?
20:29:35 <hughsie> pjones: sorry, typing as fast as i can
20:29:54 <hughsie> pjones: the app-install data takes about 2 hours to rebuild assuming you have a cache
20:30:00 <notting> pjones: well, my opinion is that the data does seem to be more correctly stored in the repodata. however, this is self-contained enough in its causes and effects that i'm not sure it's worth being outright verboten if no one is stepping up to do the repodata work as opposed to just arguing
20:30:05 <hughsie> getting the cache depend on your net connection, which for me took about 5 hours
20:30:31 <hughsie> notting: that's the thing. people are using the code right now. nobody was willing to do the repodata work at all
20:30:34 <pjones> hughsie: but aren't you going to want to rebuild it at exactly the same times you want to rebuild the repo metadata?
20:30:48 <skvidal> hughsie: when did you ask?
20:30:53 <skvidal> hughsie: and when did anyone try?
20:30:57 <skvidal> we generate lots of external repodata
20:31:01 <hughsie> pjones: no, much less frequently. ubuntu (sorry!) do it one every 6 months
20:31:05 <notting> hughsie: people are using libguestfs too, doesn't mean i don't think there's a better way to do what they do
20:31:06 <pjones> hughsie: nobody includes you?
20:31:06 <skvidal> and adding it to repodata is one modifyrepo command
20:31:16 <nirik> there's also pkgdb here, right? they have app data as well?
20:31:24 <skvidal> nirik: some of it
20:31:28 <hughsie> skvidal: hah, don't you remember the conversations that went along the lines of "not enough cpu" "not enough disk" etc?
20:31:38 <pjones> hughsie: truthfully, doing it every 6 months sounds, to me, like "this process doesn't work but we're paying lip service to it anyway"
20:31:59 <hughsie> pjones: not at all. the data really doesn;t change that much in stable distros
20:32:08 <ajax> pjones: on the other hand, if that's the UX he's happy with, maybe that's not something we should force him out of.
20:32:08 <geppetto> hughsie: Except that it does
20:32:14 <hughsie> geppetto: it does?
20:32:15 <nirik> hughsie: how about the ratings?
20:32:27 <nirik> or would that be somewhere else?
20:32:40 <geppetto> hughsie: I just replied in the ticket … took one package at random, in F-13 … and it's data has already changed for a bunch of apps. in it
20:32:41 <pjones> ajax: hughsie being happy with it isn't the biggest criteria though - adding a misfeature (whether this is one or not) pays a significant disservice to users.
20:32:42 <hughsie> nirik: at the moment i'm just pulling numbers from comps for each spin, but i'm hoping to get app data from gnome-shell when it's being used by more
20:32:57 <hughsie> geppetto: what changed tho?
20:33:14 <hughsie> not the package name or the desktop id
20:33:27 <hughsie> worst case we don't pick up a new translation or new icon for 6 months
20:33:28 <nirik> hughsie: sure, but only updating that every 6 months? some hot new app would not show up for long after people found out about it some other way?
20:33:32 <hughsie> this is for a stable distro
20:33:35 <geppetto> hughsie: You said "doesn't change" … I proved it did … if you want to argue that "somewhat broken" is fine, have fun
20:33:38 <pjones> hughsie: how much is "that much"? can you give us numbers from existing distros on where it would have changed?
20:34:10 <hughsie> pjones: for f13 zero packages changed either the application id or the package base name without obsoleting the former name
20:34:22 <mjg59> hughsie: The documented Fedora definition of stable doesn't prevent new applications entering the distribution
20:34:23 <hughsie> pjones: new packages I didn't measure
20:34:40 <hughsie> mjg59: sure, and they can get caught if we did a build every 3 months
20:34:46 <nirik> skvidal / geppetto: do you have interest/time in working with hughsie and the pkgdb folks on a repodata solution? or is that not something you guys want to do?
20:34:50 <pjones> so you ignored the interesting case?
20:34:52 <mjg59> hughsie: Yeah, but again it just seems artificially limiting
20:34:56 <hughsie> i don't think showing a package that's 3 months old at the top of an application installer is a good idea
20:35:09 <skvidal> nirik: the pkgdb folks have a solution
20:35:17 <geppetto> nirik: This all started because "we" (mostly skvidal) started work on a repodata only version of application data
20:35:27 <hughsie> skvidal: no they don't. the code needs to be written
20:35:28 <geppetto> nirik: And tools to use it
20:35:51 <skvidal> hughsie: they have data that is pulled in from bodhi
20:35:51 <nirik> skvidal: a repodata version? this is different from the one you tested? or?
20:35:53 <skvidal> and added to repos
20:35:54 <pjones> so modifyrepo didn't exist when this discussion started is what you're saying?
20:35:54 <skvidal> and push time
20:36:04 <skvidal> pjones: modifyrepo has existed for many many years
20:36:10 * nirik also notes ffesti had a example version.
20:36:15 <skvidal> pkgtags data - which is from the pkgdb
20:36:17 * lmacken wrote modifyrepo back in 2006
20:36:19 <skvidal> is included in f14-testing now
20:36:20 <skvidal> http://linux.mirrors.es.net/fedora//updates/testing/14/i386/repodata/
20:36:33 <skvidal> if we wish to augment the data
20:36:36 <skvidal> that the pkgdb is storing
20:36:43 <skvidal> and outputting in a db format
20:36:44 <skvidal> we can
20:36:48 * mclasen walks back in
20:36:50 <skvidal> and it will magically be added to the repodata
20:36:53 <skvidal> by the wonders of bodhi
20:37:12 <mjg59> Proposal: Add it as a package until the repodata implementation is finished, and then cut over to that.
20:37:24 <hughsie> mjg59: i woul dbe happy with that
20:37:36 <mjg59> Also, cut the damn baby in half
20:37:43 <ajax> mmm, baby.
20:37:49 <mclasen> geppetto: the app-data review predates 'your' repodata works
20:38:31 <geppetto> mclasen: I agree, but nobody had heard anything for over a year before the repodata work
20:38:37 * nirik wonders how far away the pkgdb db is from hughsie's needs.
20:38:47 <hughsie> nirik: quite a way, i'm afraid
20:38:56 <skvidal> nirik: it's a sqlite db
20:39:00 <hughsie> nirik: i'm using it for the screenshot url andthe groups, but that's about it
20:39:02 <nirik> yeah.
20:39:04 <skvidal> nirik: it can include any table of data it wants
20:39:24 <nirik> hughsie: what other items do you need? icons. translations from desktop file?
20:39:34 <pjones> mjg59: I really don't like that idea - it seems like the sort of thing that just mike stick if we add it at all.
20:39:34 <skvidal> nirik: right now it includes a single table
20:39:48 <hughsie> nirik: ratings are important too, as the kde spin wants different data to the gnome spin
20:39:59 <pjones> the motivation to work on the repodata implementation goes away as soon as we add the package. so if that's what we want done, that's what we need to require.
20:40:06 * nirik notes we have no pkgdb folks here, do we?
20:40:09 <pjones> just "might". I can't type.
20:40:09 <mjg59> pjones: It's not clear to me that fesco has obvious authority to prevent people doing things in suboptimal ways
20:40:19 <pjones> mjg59: they seem to have asked us to.
20:40:28 <mjg59> pjones: Yeah, I have no idea why we're talking about this
20:40:34 <mclasen> geppetto: I'm not really interested in pursing that argument; suffice it to say that other distributions have shipped the very same data format for a while, so 'nobody' seems to be limited to 'no yum developers'
20:40:44 <mjg59> hughsie: I think doing it as a package sucks. I also don't think you need to ask us before you put the package in the distribution.
20:40:54 <geppetto> mclasen: Nobdy elese has shipped "the same data format"
20:40:56 <pjones> mjg59: tbh, it really seems to be "hey, fesco, settle this argument for us because we can't be civil to one another"
20:41:02 <hughsie> mjg59: :-)
20:41:07 <notting> mjg59: because people can't be arsed to work together and instead prefer to talk over each other
20:41:18 <hughsie> geppetto: ubu has for 5 years, albeit in sparse data, not in a database
20:41:18 <geppetto> mclasen: They have done the same idea, but AIUI they did it before anyone in Fedora did anything
20:41:19 <mclasen> geppetto: not biting anymore
20:41:37 <mjg59> I think bringing this kind of thing to fesco is an utter waste of time, and if you wanted to ask us whether our sense of taste matches yours then you seem to have some kind of answer
20:42:00 <pjones> mjg59: this is why I was saying they should at least agree to the *facts* before bringing it here.
20:42:01 <mjg59> And I've got a headache
20:42:06 <hughsie> so i can get my package reviewed without FESCo "blocking" it?
20:42:24 <mclasen> fesco has not been blocking it in the first place
20:42:27 <mjg59> If we could block arbitrary packages that we thought were bad ideas, I don't think it would be top of my list
20:42:29 <pjones> yes, though doing so may bode poorly for future endeavors ;)
20:42:36 <skvidal> hmm
20:42:37 <skvidal> curious
20:42:41 <SMParrish> IMO it boils down to this. Hughsie wants it in a package and as it stands this does not violate any guidelines. If the yum folks want to pursue an alternate solution they can but that should not prevent the package from being reviewed and approved
20:42:47 <notting> pjones: i like the idea of suggesting the better implementation in a 'code speaks' sense - if you think you can do better, go do it
20:42:47 <skvidal> why did spot suggest it was a fesco issue?
20:42:52 <nirik> hughsie: can you at least open a dialog with the pkgdb folks before doing so?
20:42:56 <notting> skvidal: conflict resolution, afaik
20:43:05 <pjones> notting: indeed, though I also like encouraging them to, you know, actually work together.
20:43:11 <pjones> notting: be excellent and whatnot
20:43:20 <hughsie> nirik: i'm talking to them about once a week now. I need their data and help.
20:43:43 <mjg59> Like, shit, the entirity of KDE power management ought to be prevented from going near any computers ever, but...
20:43:57 <pjones> hughsie: anyway, so far it sounds like fesco thinks the package solution is a bad idea. but we also aren't really in a position to stop you. code does, in fact, talk.
20:43:59 <drago01> well the "this can be done in a better way" is a way to block pretty much anything
20:44:13 <hughsie> cool.
20:44:15 <nirik> hughsie: ok, so do you think this might be a fesable way to go? how far off might it be? adding the package seems like a bad idea if you are just going to go to a real implementation.
20:44:36 <hughsie> nirik: well, later than f15, which i'm targetting this for
20:44:41 <pjones> hughsie: but I really encourage you to work on doing this in repodata *instead* of pushing the package.
20:45:02 <nirik> hughsie: really? f15 is a ways still...
20:45:05 <hughsie> pjones: point heeded.
20:45:16 <geppetto> Riiight
20:45:16 <hughsie> nirik: not when you're dealing with KDE and GNOME upstreams
20:45:37 <mclasen> hughsie: to be honest, f15 seems a stretch already, with gnome3 taking all of our attention
20:46:04 <hughsie> mclasen: i've got gnome support done in a local branch. kpackagekit is already skipping releases with the app-install data required
20:46:18 <hughsie> we just need to work on the gnom-shell bits with owen and colin
20:47:10 <ajax> right then
20:47:11 <nirik> so, I would propose: a) please try the pkgdb repodata option b) if that doesn't work at all, revisit? (since we don't need to decide this today do we)?
20:47:22 <notting> nirik: i'm not sure there's anything for us to revisit
20:47:24 <ajax> we're 15 minutes past the last vote, so.
20:47:28 <hughsie> nirik: we do, as i need to know my gnome 3 plans
20:47:33 <nirik> ah yes.
20:47:39 <nirik> votes to keep going on this topic?
20:47:42 <pjones> okay, 15 more minutes of discussion?
20:47:53 <ajax> -1 oh my god please don't, vote and move on.
20:47:56 * nirik would like to at least agree on whatever it is we want to decide.
20:48:09 <pjones> I guess I can be +1 to discussing a slightly more flushed-out plan than the nirik suggested, but -1 to damn near anything else.
20:48:13 <hughsie> ship the package and agree to switch to the repodata version if it ever happens
20:48:22 <ajax> that one. right there.
20:48:37 * nirik is -1 for that personally.
20:48:44 * pjones is also -1 to that
20:48:44 <nirik> other votes?
20:48:55 <SMParrish> But I dont think that is for FESCo to decide
20:48:57 <pjones> also that one sounds passive aggressive to me.
20:49:13 <ajax> pjones: i see you've worked on linux before.
20:49:19 <pjones> SMParrish: presumably our decision is to be taken as a recommendation, since it can be little else.
20:49:22 <pjones> ajax: indeed.
20:49:28 <ajax> +1 to ship-and-port-whenever. dig your own hole, man.
20:49:38 <mjg59> Yeah, +1 to that
20:49:55 <nirik> so, -2/+2
20:49:58 <mjg59> I don't think it's the right approach, but you're the one doing the work
20:50:15 <mjg59> And your work doesn't prevent anyone else doing their implementation
20:50:20 <hughsie> correct
20:50:24 <ajax> SMParrish: you're abstaining, it sounds like?
20:50:25 <SMParrish> Then I say let hughsie proceed as he sees fit.
20:50:27 <skvidal> mjg59: it is if it is the default everyowhere
20:50:35 * notting is +1 to what mjg59 just said. i don't like hughsie's wording thereof
20:50:45 <pjones> mjg59: problem is, this plan discourages him from doing a good implementation.
20:50:48 <skvidal> mjg59: it blocks other implementations b/c he'll be able to say "but there is already a solution, stop yours!"
20:50:50 * nirik thinks doing things in a poor way fast means that you will never get the time/energy to do it in a good way later, but perhaps thats just me.
20:51:03 <pjones> especially with the "if it ever happens" wording.
20:51:15 <nirik> so, -2/+4 ?
20:51:20 <hughsie> "ship the package and agree to switch to the repodata version if it provides the same data"
20:51:27 <mclasen> the 'if it ever happens' wording is a safeguard against the must despised 'stop energy'
20:51:34 <ajax> nirik: it's not just you. my grandfather put it as "if you don't find time to do it right, where will you find time to do it all over again"
20:51:45 <mjg59> pjones: I think it's clear that the only way we can force richard to produce a good implementation is to block this package, and that's not really a precedent I want to set
20:51:53 <pjones> mclasen: I call BS - it's a built-in out so that he doesn't have to work on it and can also disclaim responsibility if he doesn't help.
20:52:12 <SMParrish> mjg59: +1
20:52:12 <pjones> mjg59: we could at least ask him to work on the thing we all think it was better in the statement we agree on.
20:52:15 * nirik looks to see who didn't vote.
20:52:17 <pjones> I mean, seriously.
20:52:21 <mjg59> hughsie: But I think there should be the expectation that you'll involve yourself in the repodata implementation
20:52:24 <hughsie> pjones: not at all. but i've also got to work with other distros
20:52:41 <mclasen> pjones: he already did one complete implementation; so now you want to somehow demand that he work on another one before you accept the first one ?
20:52:44 <pjones> hughsie: you've made multiple disparate data sources work before.
20:52:53 <pjones> mclasen: no, I want to suggest it to him.
20:52:55 <mjg59> hughsie: And ensure that the abstraction is sufficiently well-grounded that you can obtain the data from packages or from repodata, as other distributions see fit
20:53:00 <pjones> officially, on the record.
20:53:07 <hughsie> pjones: i've worked with suse and ubuntu for many hours on this
20:53:15 <hughsie> mjg59: i agree to that
20:53:15 <pjones> good for you!
20:53:20 <geppetto> mclasen: We want him to fix the first one … which should not be a big change, although he's refused for the last 1+ years
20:53:22 <nirik> cwickert / mclasen: votes?
20:53:26 <notting> hughsie: all you care is that you have a db of format XXX on the filesystem somewhere. the transport layer is not your concern?
20:53:57 <drago01> what about "FESCo won't block the package from inclusing but encourged to implement it as part of the repodata"
20:53:59 <mclasen> geppetto: fixing the first one is not asking too much, indeed
20:54:06 <mjg59> But I'm going to go and find some painkillers now
20:54:08 <drago01> pjones: ^^
20:54:12 <hughsie> notting: it is when a "yum clean all" will force the user to download 5Mb of data before an "instant, search as you type" command will complete
20:54:17 <cwickert> +1 from me
20:54:33 <notting> hughsie: that's... not what i asked.
20:54:33 <nirik> ok, so that passes then...
20:54:55 <pjones> hughsie: sounds like something that could get worked on.
20:54:57 <nirik> #agreed ship the package and agree to switch to the repodata version if/when.
20:55:12 <hughsie> cool, can i go and get a stiff drink now?
20:55:17 <pjones> (OTOH - so what? so the user asks to clean it and download again. what's the problem?)
20:55:41 <nirik> hughsie: FYI, sounds like mbacovsk is the pkgdb guy to talk to... I'd be happy to help you guys communicate if you aren't already in touch.
20:55:55 <skvidal> nirik: amusingly they work for the same people
20:56:03 <skvidal> nirik: (I didn't know that until recently, either)
20:56:06 <nirik> cool.
20:56:21 <nirik> ok, anything more on this topic?
20:56:21 <hughsie> nirik: we already talk quite a bit
20:56:30 <drago01> skvidal: doesn't sound like a problem ;)
20:56:32 <skvidal> nirik: just one question
20:56:40 <nirik> hughsie: great. I really hope you can look at a pkgdb solution before the package...
20:56:42 <skvidal> nirik: for furture reference on issues of fedora
20:57:06 <hughsie> nirik: i think pkgdb will be used as a dtasource for the package / repo rather than gernating from pkgdb
20:57:20 <skvidal> do the current fesco members, for purposes of decision-making on features, etc for fedora, care about compatibility with other distros?
20:57:39 <ajax> skvidal: meh. sometimes.
20:57:57 <nirik> skvidal: I don't fesco as a whole has a position, but each member might.
20:58:06 <pjones> It sounds like a very friendly thing to do.
20:58:12 <mclasen> I do
20:58:23 <nirik> I personally like it if we can easily, but not if it's against our values or goals.
20:58:29 <SMParrish> Its something I consider
20:58:48 <notting> that sounds like a setup for a strawman
20:58:50 <mjg59> skvidal: I think there's benefit in increasing the pool of contributors
20:58:54 <skvidal> notting: nope
20:58:54 <pjones> notting: no kidding ;)
20:58:59 <skvidal> notting: I have no other questions
20:59:03 <nirik> ok, shall we move on?
20:59:07 <pjones> let's move on.
20:59:22 <nirik> hughsie / skvidal / geppetto: thanks for being here, even if it was a animated discussion.
20:59:32 <nirik> #topic #467 Make Feature Freeze happen sooner.
20:59:32 <nirik> .fesco 467
20:59:33 <zodbot> nirik: #467 (Make Feature Freeze happen sooner.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/467
20:59:42 <pjones> I am very, very -1 to this proposal.
20:59:47 <hughsie> nirik: no problem, thanks for the invite.
21:00:05 * nirik still doesn't understand it
21:00:13 * mjg59 still has a headache
21:00:49 <Oxf13> let me review this again
21:00:50 <pjones> AFAICS the idea is to make more of a release's development cycle be after feature freeze and less be before. I think that's entirely backwards.
21:01:14 <nirik> I think they want more people to develop in rawhide instead of in the branched release
21:01:22 <Oxf13> the suggestion I had for future releases was to add more time between feature freeze and alpha change freeze (rc phase)
21:01:41 <Oxf13> so that we can still crash land features at the feature freeze point and have time to clean up before we try to make the alpha
21:02:03 <pjones> adding more time I'm all for ;)
21:02:24 <pjones> moving the goalposts without adding time, not so much.
21:02:35 <Oxf13> well.
21:02:37 <Oxf13> this would move the goal post
21:02:58 <Oxf13> it would move the feature freeze goal post say one week earlier, while keeping the alpha change freeze (rc point) at the same spot
21:04:01 <pjones> right. and that, I'm against.
21:04:21 <pjones> because it shortens the time between the starting point and the feature freeze, which I think is critical.
21:04:37 <notting> part of the problem is that this is defining things like go/no-go dates and feature landing dates as a global policy, which implies that all features are created equal in this way, when they're not
21:04:39 <Oxf13> the only other option is to shorten the timeframe between alpha and beta/final
21:04:40 * nirik wonders if we should wait and do this at the same time there's a retrospective... factor in other things we want to before adjusting anything.
21:04:41 <cwickert> a lot of great features we had in the past would not have made it with this proposal
21:04:43 <pjones> (having been a feature implementor before)
21:05:03 <pjones> Oxf13: also (assuming actually adding time is right out) there's the option of not changing it.
21:05:17 <Oxf13> pjones: I'm pretty against not changing it
21:05:18 <pjones> notting: indeed.
21:05:28 <pjones> Oxf13: okay, but it is an option.
21:05:33 <Oxf13> we've had multiple releases in recent timeframe where crash landed features at the feature freeze has led to slipping of lapha
21:05:35 <ajax> i have trouble having an opinion about this.
21:05:53 <cwickert> feature freeze means you need to have "something testable" and "basically complete". a lot of features don't meet these requirements
21:05:55 <pjones> Oxf13: I think that indicates that the schedule simply doesn't have enough time in it.
21:06:15 <cwickert> and if we make the feature freeze happen earlier, it will get worse
21:06:19 <pjones> cwickert: right, and shortening the raw amount of time before feature freeze means *fewer* will meet them.
21:06:24 <Oxf13> pjones: *shrug* either that or people are being too ambitious with their features
21:06:35 <pjones> Oxf13: some features are hard to make smaller :/
21:07:05 <jsmith> Oxf13: And the F14 alpha slip was not caused by crash-landed features, fwiw.
21:07:17 <cwickert> pjones, exactly, and we might loose some great features, especially ones where we are first. so we are in danger of loosing one or our foundations
21:07:20 <Oxf13> I'm more than willing to explore 9+ month development cycles, however I'm afraid the same thing will happen there too
21:07:34 <Oxf13> jsmith: the crash landed features significantly contributed to instability just before the change freeze
21:08:03 <Oxf13> jsmith: the reason we slipped ultimately was not the feature, but the instability leading up to the freeze caused it
21:08:12 <notting> pjones: while i agree that significantly shortening the raw development cycle is bad to some extent, i think there may be benefits to having another week (or heck, 2-3 days) of padding
21:08:17 <jsmith> Oxf13: Are we talking about the alpha, or the change freeze?
21:08:18 <pjones> Oxf13: I'd be amicable to changing the ratio some if it still results in an increase in raw time before the feature freeze.
21:08:21 * nirik likes the idea of 9 month cycles, but can't see how to make it work.
21:08:46 <pjones> notting: I'm not saying adding more time on the right side of feature freeze is bad - I'm saying less time on the left side is worse.
21:08:55 <Oxf13> jsmith: I don't understand the question
21:09:35 <Oxf13> to get to alpha release, we have to get through feature freeze which is the branch event, then we have to get to test compose, then release candidate
21:09:42 <Oxf13> release candidate can't happen until all blocker bugs are fixed
21:10:02 <Oxf13> unstable feature landings have delayed test composes, have delayed release candidates, and have caused slips
21:10:07 <Oxf13> of the actual release
21:11:50 * mclasen is currently torn apart between working on gnome3 in f15 and fixing bugs in f14
21:12:18 <nirik> so, where do we go here?
21:12:20 <Oxf13> mclasen: the good news is that you (and other people) are able to work on gnome3 f15 stuff
21:12:24 <Oxf13> mclasen: at this moment in time
21:12:30 <Oxf13> previously this was not possible.
21:13:39 <Oxf13> nirik: as a release engineer, who is not in fesco, I don't support the proposed change.
21:13:51 <notting> to go back to the ticket
21:13:52 <notting> ...
21:13:57 <notting> 1) Encouraging early development of features in Rawhide (and discouraging "sprinting" to cram a feature into an upcoming Fedora release). 2) Making sure there's well-understood and early-enough go/no-go decision points.
21:13:59 <notting> ...
21:14:07 <notting> the problem i see with #2 is that it's not a global policy
21:14:32 <pjones> the problem with #1 is that I think it does the opposite.
21:14:58 <pjones> (it does change the point we're sprinting to)
21:15:05 <mclasen> Oxf13: true, just saying that moving freezes in a fixed overall schedule just increases overlap
21:15:12 <notting> g/n-g for python-2.7 needed to be two months ago, g/n-g for something like rakudo could be ... now.
21:15:26 <Oxf13> mclasen: overlap was a specific goal
21:15:51 <Oxf13> notting: I hope you're not proposing per-feature go/nogos ?
21:16:01 <Oxf13> that would mean per-feature feature freezes...
21:16:21 <pjones> Oxf13: realistically we *have* per-feature g/n-g, we just pretend we don't for convenience.
21:16:21 <notting> Oxf13: i think we have to have some
21:16:57 <Oxf13> pjones: the example I've seen of that is granting some features /more/ time to land, post-alpha
21:17:12 <Oxf13> as opposed to requiring other features to be "feature complete" earlier than the global feature freeze
21:17:43 <Oxf13> notting: instead of different feature freeze dates, perhaps what we need is better definition and agreement on what makes a feature "feature complete"
21:17:50 <nirik> we are past 15min here now, votes to keep going?
21:17:54 <Oxf13> notting: same date deadline, but per-feature meaning of "completion"
21:18:27 <notting> nirik: how much is left on the agenda?
21:18:54 <nirik> one item... from the FPC
21:20:13 * notting would prefer to table this for next week/a more general retrospective
21:20:34 <ajax> notting: fine with me
21:20:41 <nirik> sounds good to me.
21:20:43 <SMParrish> works for me
21:20:52 * cwickert is for voting instead of revisiting
21:20:57 <cwickert> -1 from me
21:21:24 <notting> is there an actionable propsal to vote on? the requester seemed to rescind it later in the ticket
21:21:49 <pjones> so why are we discussing it then? ;)
21:21:52 <cwickert> :)
21:22:46 <nirik> ok, revist next week, ask submitter for a concrete thing to vote on?
21:23:50 <ajax> sure.
21:23:55 <pjones> yes.
21:24:01 <notting> sure
21:24:10 <SMParrish> yes
21:24:12 <nirik> #info revist next week, ask submitter for a concrete thing to vote on
21:24:19 <nirik> #topic #471 FPC Draft for Ratification
21:24:19 <nirik> .fesco 471
21:24:21 <zodbot> nirik: #471 (FPC Draft for Ratification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/471
21:25:08 <ajax> oh, rpm.
21:25:16 <ajax> one of these days you'll be a real boy.
21:25:45 <pjones> why do they want our vote on this one?
21:26:03 <pjones> have I missed something, or is this a no-brainer?
21:26:14 <ajax> https://fedorahosted.org/fpc/ticket/12 although hey-o tl;dr
21:26:46 <mjg59> pjones: Because some people think it'll make their spec files less readable for no benefit
21:27:09 <ajax> i don't see anything in the fpc ticket about why we're being asked though
21:27:11 <nirik> Is there any move to mass change specs for this? or just as time permits?
21:27:19 <mjg59> ajax: Presumably so FPC can say we agree?
21:27:27 <nirik> ajax: https://fedorahosted.org/fpc/ticket/12#comment:8
21:27:30 <mjg59> Is anyone from FPC here?
21:27:51 <nirik> anyhow, I am +1 to this change, seems fine to me.
21:28:03 <ajax> nirik: that just says "we chose to do it" not "and here's why"
21:28:31 <ajax> afaict anyway
21:28:50 <pjones> the more I read about this the harder it is to care.
21:28:55 <ajax> but still. at worst it's an innocuous change.
21:29:05 <ajax> +1 rubberstamp can it be miller time yet.
21:29:22 <mjg59> +1
21:29:36 <SMParrish> +1
21:29:39 <nirik> thats +4
21:29:52 <pjones> ajax: jorton's first point in comment#7 there seems to be true, though the rest seems religious :/
21:30:12 <pjones> I guess I'm still +1 to it though, in the comment#8 is basically on the right path.
21:30:16 <pjones> in _that_.
21:30:23 <notting> +1
21:30:28 <pjones> typing skills going quickly downhill as I remain sober.
21:30:32 <ajax> hooray majority
21:31:10 <nirik> #agreed this is approved
21:31:13 <nirik> #topic Open Floor
21:31:20 <nirik> I have one item:
21:31:35 <nirik> I folded those changed into the doc we agreed on eariler:
21:31:39 <nirik> https://fedoraproject.org/w/index.php?title=User%3AKevin%2FUpdates_Policy_Draft&diff=199546&oldid=199095
21:32:04 <ajax> thumbs up.
21:32:16 <mjg59> Yup
21:32:33 <nirik> so if that all looks good I can announce that verson
21:33:30 <nirik> any other items for open floor? or thoughts on the doc?
21:34:00 <ajax> nothing from me
21:34:35 <nirik> ok, will close the meeting in a minute if nothing comes up then...
21:34:40 <pjones> sounds good to me.
21:35:15 <nirik> Thanks for coming everyone@
21:35:19 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100928/73a7ec2a/attachment-0001.bin
More information about the devel