===================================
#fedora-meeting: FESCO (2011-11-28)
===================================
Meeting started by t8m at 18:00:48 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-11-28/fesco.2011-11-...
.
Meeting summary
---------------
* init process (t8m, 18:01:00)
* #667 Request to fix CRITPATH update process (t8m, 18:02:24)
* LINK:
https://fedorahosted.org/bodhi/ticket/642#comment:4 (nirik,
18:03:06)
* The timeout for the critpath packages is now implemented. (t8m,
18:03:35)
* LINK:
http://fedoraproject.org/wiki/Updates_Policy (nirik,
18:10:56)
* AGREED: The critpath packages will now require just one regular +1
karma vote in Pre-beta phase and two regular +1 karma votes in other
phases to be pushed. (t8m, 18:16:06)
* ACTION: nirik will file the bodhi ticket (t8m, 18:19:58)
* ACTION: t8m will edit the wiki page to add the timeout and announce
it (t8m, 18:23:23)
* #699 Proposal to remove the package "tzdata" from Critical Path (t8m,
18:23:45)
* ACTION: notting will implement this and close the ticket then (t8m,
18:26:45)
* #705 Reconsider when to shut off updates-testing by default (t8m,
18:26:53)
* AGREED: We will keep the updates-testing switchover point at the RC
compose time. (t8m, 18:43:10)
* #706 Are updates guidelines descriptive or prescriptive? (t8m,
18:43:37)
* ACTION: abadger1999 will come up with clearer wording for the policy
(t8m, 19:18:38)
* #708 F17 Feature: DRI2 Drivers only -
http://fedoraproject.org/wiki/Features/DRI2DriversOnly (t8m,
19:21:38)
* AGREED: The feature is allowed (t8m, 19:24:01)
* #709 F17 Feature: Software rendering for gnome-shell -
https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
(t8m, 19:24:52)
* AGREED: The feature is allowed (t8m, 19:25:39)
* #710 F17 Feature: Inscript2 Keymaps -
https://fedoraproject.org/wiki/Features/Inscript2_Keymaps (t8m,
19:25:48)
* AGREED: The feature is allowed (t8m, 19:27:18)
* Next week chair (t8m, 19:28:03)
* ACTION: ajax is the next week chair as it will be his last time in
FESCo :) (t8m, 19:32:14)
* Open Floor (t8m, 19:32:44)
* REMINDER: Please change your password and upload a new ssh key if
you have not already. Deadline is 2011-11-30! (nirik, 19:33:36)
* LINK:
http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html
(nirik, 19:33:39)
Meeting ended at 19:36:48 UTC.
Action Items
------------
* nirik will file the bodhi ticket
* t8m will edit the wiki page to add the timeout and announce it
* notting will implement this and close the ticket then
* abadger1999 will come up with clearer wording for the policy
* ajax is the next week chair as it will be his last time in FESCo :)
Action Items, by person
-----------------------
* abadger1999
* abadger1999 will come up with clearer wording for the policy
* ajax
* ajax is the next week chair as it will be his last time in FESCo :)
* nirik
* nirik will file the bodhi ticket
* notting
* notting will implement this and close the ticket then
* t8m
* t8m will edit the wiki page to add the timeout and announce it
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* t8m (92)
* nirik (59)
* mjg59 (52)
* abadger1999 (52)
* notting (31)
* mmaslano (22)
* pjones (22)
* sgallagh (19)
* adamw (17)
* ajax (14)
* zodbot (11)
* cwickert (5)
* shaiton (1)
---------------------------------------
18:00:48 <t8m> #startmeeting FESCO (2011-11-28)
18:00:48 <zodbot> Meeting started Mon Nov 28 18:00:48 2011 UTC. The chair is t8m.
Information about MeetBot at
http://wiki.debian.org/MeetBot.
18:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:59 <t8m> #meetingname fesco
18:00:59 <zodbot> The meeting name has been set to 'fesco'
18:01:00 <t8m> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones
sgallagh
18:01:00 <t8m> #topic init process
18:01:00 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones
sgallagh t8m
18:01:09 * nirik is here.
18:01:12 * sgallagh is here for one hour
18:01:13 * ajax waves
18:01:14 <t8m> Hello all
18:01:15 <mmaslano> hi
18:01:23 <pjones> hello.
18:01:37 * cwickert is here
18:01:45 <mjg59> Hello
18:02:04 * notting is here
18:02:11 <t8m> OK, let's start.
18:02:24 <t8m> #topic #667 Request to fix CRITPATH update process
18:02:28 <t8m> .fesco 667
18:02:32 <zodbot> t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac
-
https://fedorahosted.org/fesco/ticket/667
18:02:42 <t8m> Anything new here?
18:02:48 <nirik> so, the bodhi change is done now I think.
18:03:06 <nirik>
https://fedorahosted.org/bodhi/ticket/642#comment:4
18:03:07 <t8m> Yep, I noticed that on one of my critpath updates.
18:03:30 <nirik> There was a bit more feedback about proventesters... but not much
discussion
18:03:35 <t8m> #info The timeout for the critpath packages is now implemented.
18:04:16 <t8m> So what about leaving the proventesters as is for now? Or is there a
different proposal?
18:04:25 <mmaslano> nirik: I hope you come back with some response from
proventesters
18:04:37 <mjg59> There's still the proposal to remove the proventester karma
requirement
18:04:58 <nirik> mmaslano: well, adamw and several others responded on the list...
18:05:00 <mjg59> So far what I've seen is "In the future we could have a
wonderful new update system"
18:05:04 <nirik> but not much answer to them. ;)
18:05:21 <mjg59> But no suggestions for how to improve things right now
18:05:38 <mjg59> So we can either leave things as they are, or we can remove the
proventester karma requirement for critpath
18:05:49 * nirik nods.
18:05:50 <t8m> I saw the bodhi v2 karma system proposal from adamw - seems it could
help somehow but it still relies on having proventesters.
18:06:29 * nirik would be ok waiting and seeing if the 2 week timeout addresses/helps
folks before deciding on proventesters.
18:06:31 <mjg59> I haven't seen any real argument against dropping the
proventester karma requirement
18:06:51 <t8m> mjg59, +1
18:07:20 <mjg59> The numbers we have indicate that the requirement does almost
nothing to prevent broken updates going through
18:07:28 <pjones> yeah, it really seems to have been invented for the sake of
inventing things.
18:07:39 <t8m> OK, let's vote on the proposal
18:07:49 <mjg59> So it's a requirement that doesn't seem to aid our aims,
and it's one that makes it harder to get packages in
18:08:18 <mmaslano> which proposal? remove requirement on proventeter?
18:08:20 <sgallagh> t8m: Could you please phrase the proposal carefully?
18:08:54 <nirik> proposal: change updates requirements where they say
'proventester' to be 'any logged in user'
18:08:55 <t8m> #proposal The critpath packages will now require just two regular +1
karma votes (regardless of the proventester status) to be pushed.
18:09:27 <sgallagh> +1
18:09:29 <mjg59> +1
18:09:33 <mmaslano> +1
18:09:34 <ajax> +1
18:09:36 <t8m> +1
18:09:46 * nirik is fine with trying that. +1
18:09:57 <notting> -1... want to see how the two week limit works out first
18:10:06 * nirik wonders if we shouldn't start asking proposals be diffs against the
updates policy.
18:10:20 <pjones> +1 of course
18:10:32 <pjones> nirik: I'd be in favor of that.
18:10:49 <pjones> nirik: ... but only if we put the policy somewhere that allowed
for easy diffing.
18:10:56 <nirik>
http://fedoraproject.org/wiki/Updates_Policy
18:11:02 <pjones> i.e. a git repo instead of a wiki. (maybe mechanically mirror it
to the wiki or something)
18:11:16 <pjones> the wiki allows easy changes, but not easy changes in a reviewable
way like a diff.
18:11:17 <t8m> Hmm... my proposal would actually strenghten the policy for pre-beta
18:11:19 <nirik> yeah, it's a pain to deal with the wiki sure.
18:11:45 * nirik thinks t8m's proposal wasn't specific enough.
18:12:30 <t8m> so let's vote again
18:12:33 <pjones> nirik: ... go on?
18:13:08 <nirik> well, there's different proventester requirements depending on
where we are in the cycle.
18:13:26 <nirik> changing all of them to 2 +1 votes actually makes pre beta more
restrictive
18:13:54 <nirik> currently that just requires one +1 from a proventester
18:14:07 <t8m> #proposal The critpath packages will now require just one regular +1
karma vote in Pre-beta phase and two regular +1 karma votes in other phases to be pushed.
18:14:19 <t8m> +1
18:14:34 <mjg59> +1
18:14:41 <cwickert> +1
18:14:42 <sgallagh> +1
18:15:06 <nirik> so, really the only point of critpath is that they require +2 karma
after this?
18:15:12 <mjg59> Yes
18:15:17 <mjg59> At present
18:15:26 <mmaslano> +1
18:15:59 <pjones> +1
18:16:06 <t8m> #agreed The critpath packages will now require just one regular +1
karma vote in Pre-beta phase and two regular +1 karma votes in other phases to be pushed.
18:16:13 <notting> -1, same reasnaing as above
18:16:17 <notting> reasoning, even
18:16:22 <nirik> ok, we can try it out... +1 (but we should leave the proventester
group around in case we need it for bodhi 2.0 or need to revive)
18:16:49 <t8m> nirik, sure I think we might want it for the blocker -1s or so
18:17:44 <t8m> Who is volunteering to open a ticket against bodhi to implement the
change?
18:18:31 <nirik> we also need to adjust the wiki page for this, and announce it and
the 2 week timeout to packagers.
18:19:32 <nirik> I can file the bodhi ticket.
18:19:58 <t8m> #action nirik will file the bodhi ticket
18:20:27 <t8m> I assume we can change the wiki and send the announce as soon as the
change is implemented in bodhi.
18:21:03 <nirik> sure. The existing 2 week timeout tho needs that done asap
18:21:57 <t8m> nirik, who can edit the wiki page? I see it is locked for me.
18:22:16 <nirik> anyone should be able to. make sure you are logged in.
18:22:54 <t8m> ah looks like a glitch in the mediawiki, after reload I see the edit
there
18:23:23 <t8m> #action t8m will edit the wiki page to add the timeout and announce
it
18:23:32 <t8m> next topic
18:23:45 <t8m> #topic #699 Proposal to remove the package "tzdata" from
Critical Path
18:23:49 <t8m> .fesco 699
18:23:50 <zodbot> t8m: #699 (Proposal to remove the package "tzdata" from
Critical Path) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/699
18:24:08 <t8m> notting, anything new on the whitelisting?
18:24:17 <pjones> tzdata updates almost merit a fastpath update, whereas critpath is
a slowpath.
18:24:37 <notting> t8m: bodhi is now reading critpath from pkgdb
18:24:54 <notting> the script that creates a critpath has been modified to exclude
tzdata
18:24:56 <t8m> pjones, yep, we agreed on that last week, it was just a problem how
to do the whitelisting
18:25:03 <notting> i just need to run it and push the results to pkgdb
18:25:09 <pjones> ah, sorry.
18:25:14 <pjones> haven't gotten a chance to read the log.
18:25:53 <t8m> notting, OK, will you close the ticket when it is implemented?
18:26:20 <notting> sure
18:26:45 <t8m> #action notting will implement this and close the ticket then
18:26:53 <t8m> #topic #705 Reconsider when to shut off updates-testing by default
18:26:53 <t8m> .fesco 705
18:26:57 <zodbot> t8m: #705 (Reconsider when to shut off updates-testing by default)
- FESCo - Trac -
https://fedorahosted.org/fesco/ticket/705
18:28:22 <nirik> I guess I'd like to get some input from rel-eng and qa here...
18:28:31 <adamw> t8m: quick note - my mail wasn't a proposal so much as just an
example to show why non-numeric karma is really important, and the use of proventesters in
my example doesn't mean it's *necessary*. we could do good things with non-numeric
karma without PTs.
18:28:55 <t8m> adamw, OK
18:29:21 <adamw> no-one should get too attached to the *details* in my mail,
it's the big picture that matters. =) sorry, interruption ends
18:30:43 <t8m> nirik, me too, It seems moving the point to beta could help a little
the users who install beta but on the other hand it would make less testing of the
packages in testing which might be undesirable
18:31:17 <sgallagh> Could we perhaps make this a toggle button in pre-release
install media?
18:31:18 <adamw> i don't think qa really has much of a problem with the current
system
18:31:42 <adamw> the 'turnover point' issue is a bit annoying but is going
to happen as long as there is a transition, it doesn't matter when it happens
18:32:31 <t8m> maybe a compromise would be to switch it sometime during the beta
phase - that is on the beta install media still have the updates testing enabled but
change it sooner than just before the RCs?
18:32:55 <nirik> sgallagh: you already can change it in the install media I
think...
18:32:59 <notting> i'm not sure we have a good post-beta time other than rc
18:33:04 <adamw> nirik: that affects what media get used *during install*
18:33:12 <nirik> true.
18:33:13 <adamw> nirik: but no matter what you pick, you get updates-testing enabled
after install.
18:34:41 <adamw> really, i'm not sure there's a problem here. i think the
current system works fine and achieves what it's intended to. i'm not really
convinced the thing garret identifies as a problem really *is* a problem.
18:34:41 <t8m> notting, why not just have the package with yum repo configs updated
in the middle of the beta phase? Does it have to be an exact point of time?
18:35:14 <t8m> But if qa thinks the current situation is fine I have no problem with
it.
18:35:31 <sgallagh> adamw: Well, during the F16 cycle, there were several packages
that shipped at release without full dependencies, because they were met only by
updates-testing.
18:35:38 <notting> t8m: just that we don't have a schedule milestone it cleanly
maps to other than 'arbitrary post-beta point'
18:35:55 <adamw> sgallagh: well, we scan the media for issues like that and fix
them: the media cannot ship with dependency issues
18:36:11 <sgallagh> adamw: This was, fortunately, non-media packages.
18:36:34 <adamw> sgallagh: for anything outside the media i just don't really
see the problem: okay, in some kind of theoretical way, the 'frozen' repos should
be consistent, sure, but in practice, as long as any issues are resolved by an update
package, i can't see any practical consequence
18:36:37 * nirik is fine with just leaving it.
18:36:46 <adamw> sgallagh: well, there's nothing 'fortunate' about it,
we have procedures in place to ensure the media are okay.
18:36:57 <t8m> #proposal Leave things as is for now.
18:37:00 <adamw> (there's a script that tests it and any failures are filed as
blockers)
18:37:04 <sgallagh> adamw: ALlow me to rephrase.
18:37:27 <sgallagh> There were some packages (not on the media) that required a
specific version of a package that didn't exit updates-testing in time for release.
18:37:49 <sgallagh> But I'm okay with leaving things as-is. Just wanted to cover
everything
18:38:50 <adamw> sgallagh: ideally anything in that situation should get a 0-day
update, sure. i'm not convinced changing this would fix that problem, though; it's
not as if the dependency issues are hidden, at present, there's a daily notification
mail which identifies them all, isn't there?
18:39:17 <sgallagh> adamw: You're probably right.
18:39:59 <t8m> Do we want to vote on the 'Leave things as is'? Or should I
just close the ticket as there is no proposal for change?
18:40:14 <notting> technically, there are three proposals in the ticket
18:41:24 <t8m> yes, but there is noone here who is proposing them :) except the
default of keeping things as is.
18:41:42 <adamw> to make it clear: i haven't discussed this with the rest of the
qa group, but my personal opinion is that the current situation is fine and i don't
think that changing the point where we do the switchover to updates-testing disabled would
address any particular real-world problems we have.
18:42:05 <mmaslano> adamw: great, so we can leave it as is?
18:42:10 * mmaslano is fine with this proposal
18:42:26 <t8m> so +1 to keeping things as-is
18:42:27 * pjones is +1 to leaving it as it is for now until there's a more clear need
to change it.
18:42:29 <cwickert> +1
18:42:36 <notting> +1
18:42:37 <nirik> sure, +1
18:42:39 <mjg59> +1
18:42:42 <t8m> great
18:42:43 <mmaslano> +1
18:42:51 <sgallagh> +1
18:43:10 <t8m> #agreed We will keep the updates-testing switchover point at the RC
compose time.
18:43:37 <t8m> #topic #706 Are updates guidelines descriptive or prescriptive?
18:43:46 <t8m> .fesco 706
18:43:47 <zodbot> t8m: #706 (Are updates guidelines descriptive or prescriptive?) -
FESCo - Trac -
https://fedorahosted.org/fesco/ticket/706
18:44:34 <mjg59> I'm kind of confused by this.
18:44:40 <ajax> "use your brain" is apparently not good enough.
18:45:16 <mjg59> It's pretty clear that the list isn't meant to be
prescriptive
18:45:17 <t8m> can we make it somehow that "use your brain" would be
sufficient?
18:45:22 <nirik> abadger1999: you around?
18:45:41 <notting> i think it should be made obvious that just because a specific
case isn't listed, it doesn't mean it's kosher
18:45:43 <mjg59> But I don't think that's the point Toshio is trying to
make
18:45:44 <pjones> somebody learned a new word...
18:46:31 <sgallagh> Could we simply add "If there is any ambiguity, ask
FPC"?
18:46:31 <t8m> notting, on the other hand exceptions are there and will be there
18:46:35 <mjg59> The discussion that led to this was whether a use case that
isn't supported by the packager or upstream is intended to be considered when deciding
whether to push an update
18:46:56 <mjg59> Which doesn't seem to have anything to do with whether the
guidelines themselves are prescriptive or descriptive
18:46:59 <nirik> sgallagh: or fesco really.
18:47:08 <ajax> all within the context of the kernel which _already_ has exceptions
in the update policy (iirc)
18:47:15 <mjg59> "If you think you need to ask, don't push it"
18:47:19 <sgallagh> Sorry, misread "updates guidlines" as "packaging
guidelines"
18:47:27 <adamw> it seemed to me that it's clearly the case that kernel updates
don't really strictly follow the distro policy, but it's still probably the way
kernel updates should be done, all things considered. and the way the discussion was done
seemed somewhat bizarre and just complicated things.
18:47:45 <mjg59> adamw: That's not what's under discussion
18:48:03 <nirik> proposal: add a "If in doubt about a specific update or policy
not enumerated here, please consult with FESCo before pushing that update" ?
18:48:08 <adamw> mjg59: sorry, i didn't really explain what i meant well. skip
it.
18:48:25 <t8m> nirik, fine +1
18:48:49 <mjg59> adamw: You can break objections to kernel updates into two
categories. One is that stuff that we don't care about gets broken. The other is stuff
that we do care about gets broken.
18:48:55 <abadger1999> nirik: hi
18:49:00 <nirik> abadger1999: hey.
18:49:27 <adamw> mjg59: yeah, i mostly followed the tangent the discussion went
down, but it just seemed like a very odd side alley to get bogged down in.
18:49:30 <abadger1999> So mjg59's statements on the list indicate that he thinks
that the list is prescriptive.
18:49:32 <mjg59> The latter clearly contravenes the letter and the spirit of the
update policy, but we don't get too angry because the kernel is effectively a special
case
18:49:39 <mjg59> abadger1999: uh. No.
18:49:41 <abadger1999> mjg59: But his comments here indicate that he thinks it's
not :-)
18:49:49 <nirik> adamw: ditto
18:50:04 <abadger1999> mjg59: which is, you know, another reason I think the
loanguage needs to be clarified.
18:50:09 <mjg59> abadger1999: I think that use cases that aren't supported by
upstream or the packagers are entirely irrelevant
18:51:06 <abadger1999> mjg59: I don't agree with that from the language -- I
mean, there's libraries where upstream bumps soname willy-nilly but we tell packagers
that they aren;t to do those upgrades in a released Fedora.
18:51:08 <adamw> mjg59: btw, it seems non-controversial that the kernel should be
considered a special case, but afaics, that isn't actually written down at present. at
least, 'kernel' does not appear anywhere in
https://fedoraproject.org/wiki/Updates_Policy .
18:52:01 <mjg59> abadger1999: Those libraries are presumably intended to be used by
people. The kernel isn't inteneded to be used in this way.
18:52:32 <t8m> abadger1999, but that is breaking supported use cases of applications
that use the library if they will not be running due to missing dep
18:53:29 * cwickert needs to leave now
18:53:37 <t8m> I do not see we can agree on anything more concrete than the
nirik's proposal above.
18:53:53 <nirik> well, there could be a more general thing here...
18:53:59 <abadger1999> I really don't need to get into another discussion about
whether the kernel specific case is allowed -- I think that other language in the policy
fits with the kernel case just fine.
18:54:08 <notting> isn't nirik's proposal already in there?
18:54:18 <abadger1999> But I do think that the updates policy is being
misinterpretted right and left.
18:54:28 <abadger1999> So I'd like to clarify the language.
18:54:33 <nirik> but it's hard to word... 'cases where an upstream
explicitly disclaims use cases, those use cases can be ignored for puposes of updates'
?
18:54:38 <abadger1999> But to do that I need to understand what it's supposed to
mean :-)
18:54:43 <mjg59> abadger1999: Any specific cases?
18:55:02 <mjg59> abadger1999: It means "Don't do anything that's likely
to break supported use cases"
18:55:07 <t8m> notting, hmm you're right
18:55:33 <abadger1999> mjg59: That's not good enough -- what is supported? Who
defines it?
18:56:02 <nirik> upstream and the packager... but where is a good question.
18:56:05 <mjg59> The person who has the authority to define it
18:56:22 <mjg59> Why are you attempting to codify this?
18:56:39 <mjg59> Because I'm pretty sure you're not going to succeed
18:56:40 <notting> having fesco and/or the updates pages attempt to define what is
supported for any/all packages seems wrong to me
18:57:09 <abadger1999> Because one of the things that discourage people from
contributing is the appearance that the rules don't apply evenly to all people.
18:57:41 <mjg59> If you use internal symbols in a library and it gets broken, you
have no expectation of it being made right
18:58:03 <mjg59> But really I think you're looking for a bright line case that
simply doesn't exist
18:58:06 <t8m> abadger1999, I slightly agree with you on this but it seems only like
appearance and not a real thing
18:58:31 <ajax> abadger1999: ignoring the citation-needed on whether that's
true, the rules _are_ uneven, so...
18:58:33 * sgallagh notes this would be less of an issue if we disallowed non-public
functions from being exposed in libraries.
18:58:51 <sgallagh> Mandated link-scripts, for example
18:59:13 <mjg59> sgallagh: Exposed how? Two tightly bound .so files from the same
package may use each other's symbols
18:59:32 <abadger1999> all I want is to write down the rules so that people can see
that there isn't a special case for "RedHat-employees", "Fedora old
timers", "other exclusive cabal".
18:59:44 <sgallagh> mjg59: Ok, I didn't consider that angle
18:59:57 <nirik> abadger1999: perhaps we just start adding them as we come to them?
19:00:00 <ajax> sgallagh: that'd be nice, in a sense, but we don't require
that packagers be enough of programmers to write that where it doesn't exist
19:00:00 <notting> if the assumption is that there *is* such a special case,
attempting to write down that there isn't won't dissuade people
19:00:03 <mmaslano> abadger1999: it's more about packages than people
19:00:13 <mjg59> abadger1999: Again, I think you're trying to define something
that doesn't exist in the way you want it to
19:00:24 <t8m> We are discussing this topic for more than 15 minutes, do we want to
continue?
19:00:29 <abadger1999> mjg59: why not.
19:00:40 <abadger1999> what are you thinking needs to be defined?
19:00:47 <abadger1999> And why do you think it doesn't exist?
19:00:58 <mjg59> abadger1999: There is no general rule that makes it clear whether a
specific use case is supported or not
19:01:09 <abadger1999> mjg59: why not?
19:01:17 <pjones> abadger1999: because they're subjective by nature!
19:01:24 <abadger1999> pjones: Right. So what?
19:01:28 <mjg59> Because it's not a strict technical decision
19:01:35 <abadger1999> pjones: someone gets to judge what counts and what
doesn't right?
19:01:39 <abadger1999> So just codify that.
19:01:50 <abadger1999> Say "maintainers get to choose what makes sense"
19:01:52 <abadger1999> or
19:01:59 <abadger1999> "FESCo must judge exceptions"
19:02:00 <nirik> I suppose the decision should be up to maintainers.
19:02:25 <mjg59> So, so far I haven't seen anyone actually cite a specific
example of a problem here
19:02:25 <notting> i thought 'fesco must judge exceptions' was already on
there. if it's only implied, we can surely state so
19:02:30 <pjones> abadger1999: that's exactly what we have done, and you're
saying it's abused
19:02:36 <pjones> (without citation, mind you)
19:02:58 <abadger1999> notting: I read that in there -- so why did the kernel not
come to fesco and ask to be able to do this?
19:03:00 <mjg59> #proposal In the absence of indication of actual problems caused by
existing guidelines, leave as is
19:03:11 * abadger1999 notes that he thinks that would have been silly.
19:03:21 <t8m> mjg59, +1 to your proposal
19:03:33 <sgallagh> +1
19:03:44 <abadger1999> So would much rather we take the sections that already exist
on maintainers being able to make decisions and make those the default rather than the
fesco exception being the default.
19:03:45 <nirik> I think the better question would be: can our users find out a list
of these and know whats 'supported' ?
19:03:47 <mmaslano> mjg59: great proposal +1
19:03:59 <pjones> mjg59: +1
19:04:06 <notting> abadger1999: i'm not seeing what they needed an exception
for
19:04:06 * nirik is -1 I think we could clarify things more here.
19:04:15 <abadger1999> mjg59:
https://admin.fedoraproject.org/updates/python-fedora-0.3.25.1-1.fc14
19:04:19 <abadger1999> There's one.
19:04:41 <mjg59> abadger1999: You're going to need to provide more context
19:04:49 <nirik> "this update breaks virtualbox!" "we don't
support out of tree modules" "oh? where does it say that? I didn't
know"
19:04:53 <pjones> changelog says... bugfixes.
19:05:00 <abadger1999> people are confused about what is an update that is
disallowed by the guidelines.
19:05:15 <mjg59> abadger1999: That update appears to have been filed by you
19:05:23 <abadger1999> mjg59: That's why I know about it, yep.
19:05:27 <mjg59> abadger1999: What aspect of it do you think may have been
inappropriate for F14?
19:05:35 <abadger1999> As maintainer, I think it was appropriate.
19:05:53 <t8m> abadger1999, so what is this example about?
19:06:00 <abadger1999> But clearly, pother people think that it was inappropriate --
thuse their negative karma and explanations of why they think it was inappropriate in the
update request.
19:06:04 <notting> the complaint from the users has been that "adding 20 new
packages to my system" is a regression/material affect to their experience/something
like that
19:06:12 <abadger1999> yep.
19:06:22 <mjg59> Ah, this is the one that resulted in a pile of new packages being
dragged in?
19:06:26 <abadger1999> Yeah.
19:07:00 <mjg59> Do any of those dependent packages start anything by default?
19:07:15 <abadger1999> mjg59: no.
19:07:23 <abadger1999> (We might be on a tangent, though)
19:07:33 <mjg59> Then eh, it's something that has no impact on the users so I
have no idea why you would feel it was inappropriate under the update policy
19:08:18 <abadger1999> right. Yet there are quite a few people who do (two on the
update request, I think it's three on the subsequent bugzilla, and another two I
remember on the mailing list).
19:08:56 <mjg59> But I don't think it's the kind of thing that would be made
better by clarification
19:09:01 <abadger1999> So it's another example where I would like to look at the
update policy and figure out how to reword it so that it's clearer here.
19:09:25 <mjg59> Unless you say "It's ok for packages to gain dependencies
in updates" and then we're on the road to enumerating every single thing
19:09:38 <nirik> perhaps if we tried to define 'user experence' ?
19:10:05 <abadger1999> yep, can define user experience better; can define how much
latitude the maintainer has.
19:10:21 <t8m> ugh
19:10:23 <ajax> that's going to be a very very very long document.
19:10:26 <abadger1999> Remembering that it's not going to be perfect,
there's still multiple ways to make things better.
19:10:33 <mmaslano> abadger1999: sorry, but if you feel that new update is needed,
then new packages were okay. I would believe maintainer in this case
19:10:37 <nirik> ha, iso defines it as: ""a person's perceptions and
responses that result from the use or anticipated use of a product, system or
service"
19:11:00 <mmaslano> abadger1999: imho long document makes developer experience
worst
19:11:04 <mmaslano> worse
19:11:41 <abadger1999> mmaslano: Sure. But clearer language is not necessarily
longer.
19:12:08 <pjones> Proposal: ask abadger1999 to come back with recommended language
changes.
19:12:10 * nirik isn't sure we will solve this here. Perhaps abadger1999 could try and
come up with some proposed changes now?
19:12:19 <abadger1999> So here's the thing -- I'm volunteering to try and
draft a clearer policy.
19:12:22 <mmaslano> abadger1999: could you come with diff?
19:12:27 <pjones> excellent!
19:12:34 <abadger1999> But I do need to know what is intended in the present policy
to do that.
19:12:52 <abadger1999> For instane, there is language revolving around maintainer
perogative.
19:13:02 <abadger1999> But there's also language about exceptions having to go
through fesco.
19:13:26 <abadger1999> I could strike one or the other or define that there's
some sort of line between the two.
19:13:43 <abadger1999> but I need to know what the intention of the current policy
is to make that decision.
19:13:44 <nirik> I would put the line at 'if you have doubts as a
maintainer' ?
19:14:09 <t8m> that's because everything should be considered by maintainer and
only if he really does not know or after the update is in updates and testers are
rejecting it only then it should be brought to fesco
19:14:34 <notting> (the second part of t8m's statement is already in the
guidelines)
19:14:35 <abadger1999> t8m: I like that just fine. Can I modify the document with
that POV?
19:15:27 <t8m> abadger1999, and isn't it like this already? but if it isn't
please do and come with the diff to FESCo :)
19:15:47 <abadger1999> And we are clear that the current policy is descriptive, not
prescriptive, correct?
19:16:08 <notting> being a drafted document, it's conscriptive
19:16:20 <abadger1999> heh :-)
19:16:21 <pjones> the examples can't possibly be prescriptive. that doesn't
make sense at all.
19:16:22 <t8m> :)
19:16:31 <abadger1999> pjones: That's what I thought. Thank you :-)
19:16:38 <mmaslano> abadger1999: when you will be writing, please think about non US
developers
19:16:46 <t8m> we are discussing this topic for 30 mins
19:17:07 <abadger1999> mmaslano: In terms of not using US idioms and such? Can do.
19:17:14 <notting> officially:
19:17:24 * abadger1999 has enough to work on a new draft
19:17:28 <notting> #proposal have abadger1999 come up with clearer wording for the
policy
19:17:28 <mmaslano> abadger1999: that would be first great thing ;-)
19:17:46 <t8m> notting, I don't think we have to vote on this
19:17:55 <notting> ... ok
19:18:38 <t8m> #action abadger1999 will come up with clearer wording for the policy
19:19:26 <t8m> There are three features that were added to the ticket system
recently. Do we want to vote on them today?
19:19:57 <notting> i'm fine to go through them now. others?
19:20:03 <ajax> i would have to abstain from two of them, since they're my
features.
19:20:05 * sgallagh has to leave now
19:20:36 <nirik> fine to go thru them for me.
19:20:40 <nirik> do we still have quorum?
19:20:47 <t8m> I think so
19:20:59 <mjg59> Still here
19:21:12 * mmaslano is also here, so please quickly
19:21:19 <t8m> ok, let's go through them
19:21:38 <t8m> #topic #708 F17 Feature: DRI2 Drivers only -
http://fedoraproject.org/wiki/Features/DRI2DriversOnly
19:21:47 <t8m> .fesco 708
19:21:48 <zodbot> t8m: #708 (F17 Feature: DRI2 Drivers only -
http://fedoraproject.org/wiki/Features/DRI2DriversOnly) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/708
19:22:07 <nirik> +1 here.
19:22:16 * ajax here to field questions
19:22:36 <mjg59> +1
19:22:37 <t8m> +1
19:23:06 <notting> ajax: as i read this, this means 'dropping dri1 GL
drivers', not 'drop all X drivers that do not have dri2 support'
19:23:08 <notting> ?
19:23:31 <ajax> notting: correct. i couldn't possibly do the latter anyway
(vesa etc)
19:23:41 <ajax> i can clarify that on the feature page though
19:23:42 <notting> +1, then
19:23:50 <mmaslano> +1
19:24:01 <t8m> #agreed The feature is allowed
19:24:27 <t8m> ajax, please put that statement on the feature page
19:24:52 <t8m> #topic #709 F17 Feature: Software rendering for gnome-shell -
https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
19:24:58 <t8m> .fesco 709
19:24:59 <zodbot> t8m: #709 (F17 Feature: Software rendering for gnome-shell -
https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/709
19:25:04 <mjg59> +1
19:25:06 <t8m> +1
19:25:23 <nirik> +1
19:25:24 <notting> +1
19:25:28 <cwickert> +1
19:25:39 <t8m> #agreed The feature is allowed
19:25:48 <t8m> #topic #710 F17 Feature: Inscript2 Keymaps -
https://fedoraproject.org/wiki/Features/Inscript2_Keymaps
19:25:54 <t8m> .fesco 710
19:25:55 <zodbot> t8m: #710 (F17 Feature: Inscript2 Keymaps -
https://fedoraproject.org/wiki/Features/Inscript2_Keymaps) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/710
19:26:23 <ajax> +1
19:26:25 <t8m> +1
19:26:32 <mjg59> +1
19:26:51 <nirik> sure, +1
19:27:05 <mmaslano> +1
19:27:08 <notting> +1. summary could be reworded a bit, but, whatever
19:27:18 <t8m> #agreed The feature is allowed
19:27:48 <t8m> I suppose we do not have anything new on the Engineering services
tickets?
19:27:54 <nirik> nope.
19:28:03 <t8m> #topic Next week chair
19:28:04 <nirik> please see me if you wish to help out reviving things there.
19:28:35 <t8m> Anybody volunteers to be next week chair?
19:29:52 <notting> can't do next week .can do two weeks from now
19:30:22 * mmaslano is not sure wheter it's the first meeting of new fesco or not
19:30:40 <mjg59> Oh yeah
19:30:42 <nirik> oh, yeah, 2011-12-05 is the end of elections.
19:30:43 <mjg59> People should go and vote
19:30:44 <mmaslano> I could do it if i'm still member ;-)
19:31:07 <nirik> yeah, it would be the current fesco again next week...
19:31:11 <nirik> then the next folks the week after.
19:31:20 <ajax> i could do one last time i suppose
19:31:52 <mmaslano> ajax: it's yours ;-)
19:32:14 <t8m> #action ajax is the next week chair as it will be his last time in
FESCo :)
19:32:24 <ajax> suitable punishment ;)
19:32:24 <t8m> (for now)
19:32:44 <t8m> #topic Open Floor
19:33:09 <nirik> I have one announcement/reminder:
19:33:36 <nirik> #info REMINDER: Please change your password and upload a new ssh
key if you have not already. Deadline is 2011-11-30!
19:33:39 <nirik>
http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html
19:34:32 * nirik has nothing else.
19:35:37 <t8m> I will end the meeting if nobody speaks up in a minute.
19:36:12 * shaiton will start in 2 minutes then ^^
19:36:48 <t8m> #endmeeting
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb