=================================== #fedora-meeting: FESCO (2010-09-28) ===================================
Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-09-28/fesco.2010-09-28-19.30.log.html Meeting summary --------------- * 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, 19:37:53) * AGREED: try and find a new time, revisit next week. (nirik, 19:42:55) * Updates policy / Vision implementation status (nirik, 19:43:23) * AGREED: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft is approved (nirik, 19:58:14) * ACTION: nirik will announce new policy (nirik, 20:00:58) * http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:05:18) * LINK: http://fedoraproject.org/wiki/Releases/15/Schedule (nirik, 20:10:52) * LINK: https://fedoraproject.org/wiki/Releases/15 (drago01, 20:10:55) * #469 App install related issues (nirik, 20:12:46) * LINK: http://linux.mirrors.es.net/fedora//updates/testing/14/i386/repodata/ (skvidal, 20:36:20) * 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 (nirik, 21:24:12) * #471 FPC Draft for Ratification (nirik, 21:24:19) * LINK: https://fedorahosted.org/fpc/ticket/12 although hey-o tl;dr (ajax, 21:26:14) * AGREED: this is approved (nirik, 21:31:10) * Open Floor (nirik, 21:31:13) * LINK: https://fedoraproject.org/w/index.php?title=User%3AKevin%2FUpdates_Policy_Draft&diff=199546&oldid=199095 (nirik, 21:31:39) Meeting ended at 21:35:19 UTC. Action Items ------------ * nirik will announce new policy Action Items, by person ----------------------- * nirik * nirik will announce new policy * **UNASSIGNED** * (none) 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
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
