4:37 p.m.
===================================
#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-...
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...
(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...
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...
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