3:14 p.m.
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on
irc.freenode.net.
NOTE: The Meeting Time has CHANGED. See above.
Followups:
#351 Create a policy for updates
New Business:
#353 provenpackager request for walters
#352 Proposal: Fesco should have a procedure for removing members of fesco.
#354 Desktop Spin size change should get a feature page
#346 Drop LSB package
#347 tor is not compliant with Fedora guidelines
#355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path
#348 Fedora Packaging Committee items for ratification (2010-02-24):
Complex Font Template fix:
https://fedoraproject.org/wiki/Fix_Complex_Font_Template%28draft%29
Which files to include in python modules:
https://fedoraproject.org/wiki/No_py_removal%28draft%29
- Fedora Engineering Services Tickets/Updates.
https://fedorahosted.org/fedora-engineering-services/
assigned tickets / status update:
#2 SIGs roundup and pinging - jds2001
#5 Fix broken dependencies - itmarjp
#6 Fix packages that fail to build from source - bruno
#7 spec cleanup task: fix the need for perl (etc) in scriptlets - mmcgrath
#8 Document Fedora as android devel platform - stickster
unassigned tickets:
#4 tool idea: script to evaluate buildroot poisoning
Open Floor
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.
kevin
3:20 p.m.
On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote:
#355 Let rel-eng untag embryo from F-13 because it breaks the chain
and upgrade path
Does this one really have to wait for a meeting? It's a pretty straight
forward case, deps are broken, it couldn't have been installed anywhere
to begin with.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:26 p.m.
On Mon, 15 Mar 2010 13:20:09 -0700
Jesse Keating <jkeating(a)redhat.com> wrote:
On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote:
> #355 Let rel-eng untag embryo from F-13 because it breaks the chain
> and upgrade path
Does this one really have to wait for a meeting? It's a pretty
straight forward case, deps are broken, it couldn't have been
installed anywhere to begin with.
oh? I'm a bit confused there...you can install the package just fine by
itself. It's just if you try and install enlightment or have
enlightenment's stack installed that it fails. So, most people wouldn't
have it installed due to the broken dep, but you can indeed install it
by itself ok.
[root@ohm ~]# yum install embryo
Loaded plugins: changelog, presto, refresh-packagekit, security
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package embryo.x86_64 0:0.9.9.063-1.fc13 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
==========================================================================================
Package Arch Version Repository Size
==========================================================================================
Installing:
embryo x86_64 0.9.9.063-1.fc13 fedora 88 k
Transaction Summary
==========================================================================================
Install 1 Package(s)
Upgrade 0 Package(s)
Total download size: 88 k
Installed size: 199 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
fedora/prestodelta | 46 kB 00:00
Processing delta metadata
Package(s) data still to download: 88 k
embryo-0.9.9.063-1.fc13.x86_64.rpm | 88 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : embryo-0.9.9.063-1.fc13.x86_64 1/1
Installed:
embryo.x86_64 0:0.9.9.063-1.fc13
Complete!
[root@ohm ~]# yum install enlightenment
Loaded plugins: changelog, presto, refresh-packagekit, security
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package enlightenment.x86_64 0:0.16.999.050-5.fc12 set to be updated
--> Processing Dependency: libefreet.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_evas.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_x.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_imf.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_txt.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_ipc.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libehal.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_file.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libefreet_mime.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libedbus.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_imf_evas.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_job.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libevas.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libedje.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_con.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Processing Dependency: libecore_fb.so.0()(64bit) for package:
enlightenment-0.16.999.050-5.fc12.x86_64
--> Running transaction check
---> Package e_dbus.x86_64 0:0.5.0.050-3.fc12 set to be updated
---> Package ecore.x86_64 0:0.9.9.050-7.fc12 set to be updated
---> Package edje.x86_64 0:0.9.9.050-6.fc12 set to be updated
--> Processing Dependency: libembryo.so.0()(64bit) for package:
edje-0.9.9.050-6.fc12.x86_64
---> Package efreet.x86_64 0:0.5.0.050-5.fc12 set to be updated
---> Package evas.x86_64 0:0.9.9.050-3.fc12 set to be updated
--> Finished Dependency Resolution
Error: Package: edje-0.9.9.050-6.fc12.x86_64 (fedora)
Requires: libembryo.so.0()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
3:30 p.m.
New subject: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
On Mon, Mar 15, 2010 at 9:26 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Mon, 15 Mar 2010 13:20:09 -0700
Jesse Keating <jkeating(a)redhat.com> wrote:
> On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote:
> > #355 Let rel-eng untag embryo from F-13 because it breaks the chain
> > and upgrade path
>
> Does this one really have to wait for a meeting? It's a pretty
> straight forward case, deps are broken, it couldn't have been
> installed anywhere to begin with.
oh? I'm a bit confused there...you can install the package just fine by
itself. It's just if you try and install enlightment or have
enlightenment's stack installed that it fails. So, most people wouldn't
have it installed due to the broken dep, but you can indeed install it
by itself ok.
That's right, you could install it by itself. It's just nobody would
install it alone. It's only used with enlightenment.
--
LG Thomas
Dubium sapientiae initium
1:45 p.m.
Jesse Keating wrote:
On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote:
> #355 Let rel-eng untag embryo from F-13 because it breaks the chain
> and upgrade path
Does this one really have to wait for a meeting? It's a pretty straight
forward case, deps are broken, it couldn't have been installed anywhere
to begin with.
The question is whether to allow doing the untagging without an Epoch bump,
making F-13 go backwards.
Kevin Kofler
2:16 p.m.
On Tue, 2010-03-16 at 19:45 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
> On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote:
>> #355 Let rel-eng untag embryo from F-13 because it breaks the chain
>> and upgrade path
>
> Does this one really have to wait for a meeting? It's a pretty straight
> forward case, deps are broken, it couldn't have been installed anywhere
> to begin with.
The question is whether to allow doing the untagging without an Epoch bump,
making F-13 go backwards.
Kevin Kofler
I had misunderstood the problem. I assumed when the maintainer told me
that the deps were broken and nobody could install it, that he meant
nobody could install it, not that "it is unlikely that anybody would
install it".
Going backwards only really matters if the package happens to get into
people's systems, that's what we're trying to protect against.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:05 a.m.
On Tue, 16 Mar 2010 11:49:46 -0400
Bill Nottingham <notting(a)redhat.com> wrote:
Kevin Fenzi (kevin(a)scrye.com) said:
> NOTE: The Meeting Time has CHANGED. See above.
>
> Followups:
>
> #351 Create a policy for updates
As has happened in the past, I'd suggest handling this meeting item
later in the meeting so that other business actually gets attended to.
Yeah, I intended to leave it for the end to allow more time for
discussion.
kevin
4:06 p.m.
New subject: Meeting Summary/Minutes for todays (2010-03-16) FESCo meeting
===================================
#fedora-meeting: FESCO (2010-03-16)
===================================
Meeting started by nirik at 19:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-03-16/fesco.2010-03-...
Meeting summary
---------------
* init process (nirik, 19:00:17)
* #353 provenpackager request for walters (nirik, 19:02:24)
* AGREED: walters approved for provenpackager (nirik, 19:05:07)
* #352 Proposal: Fesco should have a procedure for removing members of
fesco (nirik, 19:05:30)
* AGREED: the proposal passes with an amendent for the chair/current
acting chair and with a standard impeachment rule that the cause
for the vote must be made explicit. (pjones, 19:15:59)
* #354 Desktop Spin size change should get a feature page (nirik,
19:18:36)
* LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
(nirik, 19:19:57)
* LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
(Kevin_Kofler, 19:22:05)
* AGREED: This late feature is approved. Please finish up the page and
add it to the right categories/lists. (nirik, 19:23:47)
* #346 Drop LSB package (nirik, 19:24:17)
* AGREED: This proposal is rejected. (nirik, 19:27:48)
* AGREED: FESCo asks FPC investigate a guideline against direct
dependencies on redhat-lsb (nirik, 19:29:57)
* ACTION: notting will ask them to look into it. (nirik, 19:30:11)
* #347 tor is not compliant with Fedora guidelines (nirik, 19:30:20)
* AGREED: FESCo will ask tor maintainer to not use install_initd and
will see if FPC can codify scriptlet output issues. (nirik,
19:39:25)
* ACTION: nirik will contact tor maintainer (nirik, 19:41:44)
* ACTION: ajax will talk to FPC about scriptlet output (nirik,
19:46:02)
* #355 Let rel-eng untag embryo from F-13 because it breaks the chain
and upgrade path (nirik, 19:46:16)
* AGREED: FESCo will allow releg to untag this package for now,
revisit this next week if there are still issues. (nirik, 20:00:08)
* #348 Fedora Packaging Committee items for ratification (2010-02-24)
(nirik, 20:00:28)
* AGREED: Both guidelines changes are accepted. (nirik, 20:03:30)
* Fedora Engineering Services Tickets/Updates. (nirik, 20:03:46)
* #351 Create a policy for updates (nirik, 20:05:52)
* LINK:
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
(nirik, 20:06:42)
* AGREED: Section 1 of the proposal is approved. (nirik, 20:17:00)
* LINK:
http://kojipkgs.fedoraproject.org/mash/branched-20100316/logs/critpath.log
(nirik, 20:25:16)
* AGREED: Section 2 is Approved. Implementation details will need to
be worked out for listing/noting important packages. (nirik,
20:29:17)
* AGREED: Section 3 will not be entirely removed. (nirik, 20:32:18)
* AGREED: Section 3 + KevinK's Amendemnt B passes (nirik, 20:52:27)
* None of this will take effect until implementation is made and
announced and ready. (nirik, 20:53:28)
* Open Floor (nirik, 20:59:07)
* FESCo members will be voiced starting next meeting to help avoid
confusion. (nirik, 21:01:29)
Meeting ended at 21:04:45 UTC.
--
19:00:01 <nirik> #startmeeting FESCO (2010-03-16)
19:00:02 <zodbot> Meeting started Tue Mar 16 19:00:01 2010 UTC. The chair is nirik.
Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:05 <nirik> #meetingname fesco
19:00:06 <zodbot> The meeting name has been set to 'fesco'
19:00:11 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones
cwickert mjg59
19:00:12 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik
notting pjones skvidal
19:00:17 <nirik> #topic init process
19:00:23 <pjones> I suppose I'm here.
19:00:25 * skvidal is here
19:00:25 * cwickert is here
19:00:33 <mjg59> Here
19:00:40 <ajax> a friend in need is a friend indeed
19:01:05 * notting is here. behind on some stuff, but here.
19:01:15 <Kevin_Kofler> Present.
19:01:31 <nirik> dgilmore: you around?
19:01:41 <skvidal> I just pinged him on jabber
19:01:46 <nirik> skvidal: thanks.
19:01:58 <dgilmore> nirik: i am
19:02:11 <nirik> ok, I would like to leave the updates policy for last, so hopefully
we can get the rest of these agenda items taken care of...
19:02:24 <nirik> #topic #353 provenpackager request for walters
19:02:30 <nirik> .fesco 353
19:02:31 <zodbot> nirik: #353 (provenpackager request for walters) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/353
19:02:52 <pjones> I think we should give it to him. Seriously.
19:03:01 <mjg59> I can't see any reason why not
19:03:18 <Kevin_Kofler> I'm a bit worried about his plans to touch packages he
doesn't own to add things which aren't in the guidelines.
19:03:29 <cwickert> +1
19:03:38 <Kevin_Kofler> And it was the only reason given for the request.
19:03:39 <dgilmore> im +1
19:03:47 <nirik> I'm +1 on it... I think it will help fedora to have him able to
work on other items. I agree he shouldn't add things that are outside the guidelines.
19:03:51 <Kevin_Kofler> So I'm afraid I have to vote -1 due to lack of a valid
rationale.
19:03:52 <dgilmore> I think he will be responsible
19:03:55 <notting> i'm +1 just for the desktop co-maintenance aspect
19:04:00 <mjg59> +1
19:04:01 <skvidal> +1
19:04:17 <cwickert> I agree with Kevin_Kofler. It's not that I think he is a bad
maintainer, but the rationale is poor
19:04:34 <skvidal> cwickert: so you're not +1?
19:04:36 <pjones> Kevin_Kofler: I still don't know why you think he's going
to run all across every package or something. he's talking about changing a smallish
group of packages as a (benign) experiment, AFAICS.
19:04:47 <cwickert> skvidal, I was +1 to what Kevin_Kofler said
19:04:49 <pjones> I'm also +1 purely for the desktop co-maintenance aspect.
19:04:50 <ajax> the guideline, if it existed, would be optional anyway.
19:04:57 <skvidal> cwickert: so not to the proposal
19:05:03 <cwickert> right skvidal
19:05:07 <nirik> #agreed walters approved for provenpackager
19:05:12 <skvidal> cwickert: sorry, that wasn't clear fro mthe flow
19:05:15 <ajax> (+1 to provenpackager, for the record)
19:05:30 <nirik> #topic #352 Proposal: Fesco should have a procedure for removing
members of fesco
19:05:34 <nirik> .fesco 352
19:05:38 <zodbot> nirik: #352 (Proposal: Fesco should have a procedure for removing
members of fesco.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/352
19:05:43 <nirik> there was some discussion of this in the ticket.
19:05:52 <cwickert> skvidal, my bad
19:06:25 <pjones> I think this should get s/Chair/Chair or de facto chair/ injected
into it at the obvious place.
19:06:28 <Kevin_Kofler> I still think this policy needs to be restricted to concrete
wrongdoings, not just "voting off".
19:06:32 <pjones> otherwise I'm pretty much for it.
19:06:43 <pjones> Kevin_Kofler: afraid you've done some of them?
19:06:55 <Kevin_Kofler> No.
19:07:03 <ajax> pjones: "de facto chair"? who would that be?
19:07:09 <skvidal> ajax: if the chair is absent
19:07:11 <skvidal> repeatedly
19:07:13 <skvidal> for example
19:07:14 <pjones> ajax: whoever is acting as chair if chair is missing.
19:07:17 <skvidal> and we have some sitting in
19:07:17 <nirik> I admit it's vuage... I suppose the fact that it would take 8
to do it would cause it to not be done lightly?
19:07:19 <Kevin_Kofler> I just don't think it makes sense to allow "voting
off" people without a specific concrete reason.
19:07:36 <skvidal> nirik: I think it makes it fairly difficult, yes
19:07:37 <pjones> Kevin_Kofler: it requires a specific reason - it just doesn't
require that the policy enumerated them all.
19:07:38 <cwickert> I think "serious misconduct" is to vague.
19:07:38 <Kevin_Kofler> And we should clarify beforehand what those concrete reasons
are.
19:08:00 <Kevin_Kofler> cwickert: Right, "serious misconduct" is not
concrete.
19:08:00 <notting> i would agree, but i don't think attempting to list all the
things that could possibly qualify as 'serious misconduct' is practical
19:08:00 <skvidal> cwickert: if we get specific then we end up writing ourselves
into a corner
19:08:01 <nirik> well, it's hard to list all the possible things that could come
up
19:08:02 <Kevin_Kofler> It's abstract. :-)
19:08:06 <dgilmore> im +1 for the proposal
19:08:16 * skvidal is +1 too
19:08:17 <mjg59> Any policy which tries to enumerate concrete reasons will either
fail in an awkward corner case or will have people try to push any situation they want
into one of those concrete cases
19:08:29 <cwickert> I think if we really go for something like "serious
misconduct", skvidal would be in danger of being removed for some os his statements
in the last meeting
19:08:39 <dgilmore> I think that there would be a good obvious reason for removing
someone. the community would uproar if there was not
19:08:49 <notting> i would assume it would be like stewart definition of obscenity
19:08:51 <skvidal> cwickert: bring it
19:08:56 <pjones> cwickert: I don't think you could get us all to agree to that;
therefore, you're incorrect.
19:09:01 <Kevin_Kofler> Without requiring a concrete reason, this undermines
democracy.
19:09:16 <pjones> notting: I can't define it, but I know it when I piss on your
mom?
19:09:17 <ajax> people. let's save the personal attacks for the octagon.
19:09:20 * drago01 notes that there is something called "common sense" ... you
don't have to write _everything_ down
19:09:31 <cwickert> skvidal, see mschwend's mail on f-a-b list
19:09:33 <skvidal> cwickert: and I'd love to see what the serious misconduct is
19:09:35 <skvidal> cwickert: hahahaha
19:09:39 <pjones> yeah, I really think this is a fine policy.
19:09:41 <notting> pjones: classy.
19:09:41 <nirik> Kevin_Kofler: well, for example the us has 'high crimes and
misdemenors'... but thats also subject to subjective issues.
19:10:15 <skvidal> this policy is simply following on the board's policy
19:10:22 <pjones> I think subjective vague criteria is fine here.
19:10:23 <Kevin_Kofler> dgilmore's downplaying of the current contributions of
one of Fedora's most longstanding contributors could also qualify as "serious
misconduct".
19:10:24 <dgilmore> without listing evry possible thing and then missing something
you cant be overly speciifc in the policy
19:10:26 <skvidal> I find it amusing that we're having more complicated
discussion of it than they have
19:10:26 <cwickert> skvidal, "orphan your packages and go. I'll be glad to
clean up that mess" IMHO is serious misconduct
19:10:36 <Kevin_Kofler> We really need to define what exactly is serious enough to
get one voted off.
19:10:36 <ajax> i would be for this proposal with pjones' amendment about de
facto chair, and with a standard impeachment rule that the cause for the vote must be made
explicit.
19:10:37 <pjones> so long as it's clear that there must be some concrete reason
for the removal vote.
19:10:51 <dgilmore> i think it will be obvious when we need to remove someone
19:10:54 <pjones> ajax: exactamundo.
19:10:58 <skvidal> cwickert: then by all means - vote for the policy
19:10:59 <mjg59> cwickert: I think it's inappropriate, but not serious
misconduct. So, in its proposed form, the proposal would not have resulted in Seth being
removed
19:11:13 <skvidal> cwickert: and then argue for my removal.
19:11:19 <skvidal> cwickert: that's how it is supposed to work
19:11:25 <cwickert> skvidal, it was not my intention
19:11:25 <mjg59> Ok. How about we vote on the amendment?
19:11:33 <pjones> mine or ajax's or both?
19:11:43 <mjg59> ajax's subsumes yours
19:11:43 * notting is +1 to the proposal with ajax's amendments
19:11:46 <cwickert> my question is: who is to define "serious
misconduct"?
19:11:46 <mjg59> So let's go with that first
19:11:51 <mjg59> nirik: ?
19:11:59 <skvidal> cwickert: WE ARE
19:12:01 * skvidal is +1
19:12:03 <nirik> I'm +1 to the proposal with ajax's amendments...
19:12:08 * pjones is +1 to ajax's
19:12:09 <mjg59> +1 from me
19:12:12 <cwickert> skvidal, simple majority?
19:12:19 <Kevin_Kofler> mjg59: That's why "serious misconduct" needs
to be defined.
19:12:25 <mjg59> Kevin_Kofler: Nonsense.
19:12:27 <ajax> obviously i'm in favor of my own proposal.
19:12:34 <nirik> cwickert: no, it would be 8 of 9 of us agree the other was doing
'serious misconduct'
19:12:39 <pjones> cwickert: any one of us can come and say "hey, I think
you're engaging in serious misconduct." then we discuss it as a group and decide
if, by unanimous vote, we want rid of the plausible misconductor.
19:12:39 <skvidal> cwickert: did you even read the policy? the FESCO member in
question may be removed by unanimous vote of the other members of FESCO
19:12:40 <mjg59> Kevin_Kofler: If it's not defined, it gets interpreted by the
current committee
19:12:55 <Kevin_Kofler> I'm -1 to the policy with or without ajax's
amendment.
19:13:09 <pjones> of course you are.
19:13:19 <cwickert> skvidal, this is the second step AFTER voting if something is
"serious"
19:13:24 <skvidal> cwickert: no
19:13:36 * nirik tries to tally
19:13:41 <ajax> cwickert: yeah, i don't really think that's the case...
19:13:44 <pjones> cwickert: no, it's one step. "I think you're
engaging in serious misconduct. "
19:13:44 <skvidal> nirik: I see 4 +1 and 1 -1
19:13:46 <mjg59> Kevin_Kofler: So, obviously, it would be possible for everyone to
decide that the use of the word "KDE" was serious misconduct, and then vote
someone off because of that. But then nobody would ever listen to that committee about
anything again ever, the board would get involved and things would get fixed.
19:13:48 <Kevin_Kofler> pjones: Is this an implied accusation? :-/
19:13:54 <pjones> Kevin_Kofler: no.
19:14:01 <nirik> skvidal: did you get dgilmore's? I think it's 5 +1 and 1
-1
19:14:06 <mjg59> skvidal: I see 5 +1
19:14:11 <skvidal> nirik: I missed his
19:14:12 <skvidal> you're right
19:14:13 <skvidal> sorry
19:14:18 <pjones> Kevin_Kofler: I think you're generally against everything you
didn't write, but that's not misconduct, it's just annoying.
19:14:29 <mjg59> Shall we move on?
19:14:30 <ajax> cwickert: i mean, it doesn't even matter. if a simple majority
says something is "gross misconduct", and it goes to a vote, and it's still
only simple majority, then it's no effect.
19:14:33 <nirik> can we drop the back and forth please?
19:14:38 <skvidal> in favor we have: nirik, skvidal, notting, pjones, mjg59,
dgilmore
19:14:39 <cwickert> pjones, ok, but what if we all agree if this or that is serious
but not if foo should be removed? this are two different decisions IMO
19:14:46 <ajax> skvidal: and myself.
19:14:49 <pjones> cwickert: only the last one matters.
19:14:53 <skvidal> ajax: of course, right
19:14:55 <skvidal> so it's in
19:15:00 <nirik> #agreed the proposal passes with an amendent for the chair/current
acting chair.
19:15:00 <skvidal> nirik: I think we're done, right?
19:15:14 <pjones> nirik: you got that wrong
19:15:17 <nirik> skvidal: yes, except can someone write this up in the wiki and
announce it?
19:15:23 <nirik> pjones: ok.
19:15:24 <Kevin_Kofler> pjones: I'm against everything that doesn't make
sense.
19:15:25 <nirik> #undor
19:15:27 <nirik> #undo
19:15:27 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at
0x284fbd10>
19:15:30 <Kevin_Kofler> Whether I wrote it or not is irrelevant.
19:15:31 <ajax> cwickert: this is why i said the charge needs to be written.
19:15:33 <nirik> pjones: care to try?
19:15:33 <pjones> Kevin_Kofler: I know that to be false.
19:15:43 <mjg59> Hurrah for meetbot!
19:15:50 <skvidal> mmm, democracy successfully undermined
19:15:59 <pjones> #agreed the proposal passes with an amendent for the
chair/current acting chair and with a standard impeachment rule that the cause for the
vote must be made explicit.
19:16:04 <cwickert> ajax, just for the record what exactly was your amendment?
19:16:17 <nirik> pjones: thanks.
19:16:26 <ajax> cwickert: i might think that pjones needs to be removed because he
called me fat. but if he's brought to vote for sabotaging other people's
packages, when he didn't, i would be acting in bad faith if i voted to remove him
anyway.
19:16:28 <nirik> who will write this up /announce it?
19:16:31 <pjones> cwickert: exactly as quoted just now
19:16:37 <pjones> ajax: fat.
19:16:55 <ajax> 15:10 <ajax> i would be for this proposal with pjones'
amendment about de facto chair, and with a standard impeachment rule that the cause for
the vote must be made explicit.
19:16:59 <ajax> cwickert: ^^^
19:17:07 <skvidal> nirik: I'll write it up
19:17:20 <skvidal> nirik: and post a draft to the wiki - where should it be put in?
19:17:30 <nirik> skvidal: thanks. Should go in the fesco policy wiki space and go to
devel-announce I would guess? or should we announce it?
19:17:53 <pjones> I don't think there's any real need for an announcement.
19:18:01 <Kevin_Kofler> And why can such a policy be passed with only 6 +1 votes
when those wouldn't be sufficient to carry the power of voting somebody off even under
the policy itself.
19:18:01 <adamw> devel-announce doesn't seem right. it's nothing specific to
development.
19:18:02 <notting> given that we have Board/SuccessionPlanning, i suspect it would
go in FESCo/SuccessionPlanning, or similar
19:18:04 <nirik> yeah, perhaps not.
19:18:22 <nirik> ok, moving on.
19:18:22 <Kevin_Kofler> This is quite illogical.
19:18:27 <cwickert> ajax, thanks, IMO this is not enough, so just for the record
I'd like to point out that I'm -1 to the current proposal
19:18:34 <cwickert> anyway, lets move
19:18:36 <nirik> #topic #354 Desktop Spin size change should get a feature page
19:18:42 <nirik> .fesco 354
19:18:43 <zodbot> nirik: #354 (Desktop Spin size change should get a feature page) -
FESCo - Trac - https://fedorahosted.org/fesco/ticket/354
19:19:14 <dgilmore> +1 we need to make it loud and clear that you must have a dvd
for the live image
19:19:36 <pjones> why does it need a feature page? it needs to be announced, but
that's handled in the second comment.
19:19:38 <mjg59> s/dvd/dvd or usb stick/
19:19:45 <mjg59> But yeah, this seems like something that's worth noting
19:19:48 <notting> i'm waffling on this. if it's prominent in the release
notes, i'm not sure it needs a specific Feature page
19:19:57 <nirik> https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:19:57 <ajax> +1 to announcing it somehow, and not just because i hate the live
installer.
19:20:03 <Kevin_Kofler> FWIW, AFAIK we're still targeting 700 MB for KDE (the
Alpha overflowed due to bad kickstarts).
19:20:06 <pjones> it's already /in/ the release notes. we do not need a
feature.
19:20:08 <dgilmore> pjones: because the feature pages is where the release notes
come from
19:20:11 <Kevin_Kofler> So we can point the CD users to the KDE spin. :-)
19:20:17 <pjones> dgilmore: not the documentation beat?
19:20:19 <adamw> i definitely think it needs to be announced (I mailed a suggestion
to that effect to the -desktop mailing list). it's catching quite a lot of users by
surprise
19:20:21 <nirik> Kevin_Kofler: or lxde/xfce. ;)
19:20:22 <drago01> or to the 1990s
19:20:23 <mjg59> pjones: I think "300MB more software" is a feature
19:20:26 <adamw> they tend to assume it's a bug and ask if they should report
it
19:20:41 <ajax> well it'll get reported no matter what we do...
19:20:47 <nirik> a feature page will mean press will pick it up more.
19:20:55 <adamw> sure, but the existence of that behaviour rather indicates it needs
an announcement :)
19:20:57 <Kevin_Kofler> (Actually, the reason for the KDE spin overflowing was bad
timing of freeze overrides and stuff, not really the kickstart's fault.)
19:20:59 <nirik> there already is a release note.
19:21:15 <cwickert> +1 for a feature page, this needs to be in the release notes and
in the wiki, so it is a feature
19:21:21 * nirik is a +1 I guess. It seems kinda a pain, but I think it will help.
19:21:30 * pjones is -1 because it seems redundant.
19:21:42 <mjg59> +1
19:21:51 <notting> before i vote +1, who are we telling to write the page?
19:22:00 <notting> that should probably be part of what we're deciding :)
19:22:01 <Kevin_Kofler> It's already written.
19:22:05 <Kevin_Kofler>
https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:22:08 <nirik> notting: the desktop folks have a draft... see my link above
19:22:25 <notting> oh. so this is essentially ACKing an existing (late) feature
page. ok, +1
19:22:36 <Kevin_Kofler> +1, the feature page is written and it's an important
change which should be mentioned.
19:22:42 <pjones> if the problem is that people won't notice because they
don't read the release notes, adding a feature page is only perpetuating the problem.
19:23:03 <Kevin_Kofler> "User Experience" is wrong.
19:23:09 <Kevin_Kofler> (copied from another feature page)
19:23:09 <nirik> pjones: sure, but its a nasty cycle...
19:23:13 <notting> pjones: that is a large problem to solve than just the context of
this single feature. unless this is your line in the sand? this far, no farther?
19:23:28 <EvilBob> pjones: users don't read, does not mean that it should not be
documented
19:23:40 <pjones> notting: my line of the sand with feature pages is well behind us,
and I'm not going to be the one dragging us farther from it.
19:23:47 <nirik> #agreed This late feature is approved. Please finish up the page
and add it to the right categories/lists.
19:23:48 <cwickert> we already have 5 +1s I think, have we?
19:23:52 * nirik nods
19:23:52 <adamw> EvilBob: pjones' line of thinking is that providing a Feature
page to try and get the news to people who don't read release notes is a workaround
not a proper fix
19:24:10 <adamw> EvilBob: where the 'proper fix' would be reprogramming
users' brains with a large lump of wood with rusty nails in it until they *do* read
release notes
19:24:17 <skvidal> adamw: and it is sorta like giving someone a pamphlet on
illiteracy
19:24:17 <nirik> #topic #346 Drop LSB package
19:24:20 <EvilBob> adamw: +1
19:24:25 <nirik> .fesco 346
19:24:25 <zodbot> nirik: #346 (Drop LSB package) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/346
19:25:04 <notting> -1. it has a willing, if occasionally vacant packager. if we
dropped everything i thought was crazy.....
19:25:04 <nirik> the list pointer in question is about the tor package (an upcoming
topic)
19:25:05 <pjones> as much as I love the idea of dropping the lsb package, I think
this is the wrong thing to do unless we've at least e.g. made a policy that says not
to use lsb stuff for init scripts.
19:25:09 <Oxf13> competent packaging/reviews are hard, lets go shopping?
19:25:12 <pjones> (which I think we /should/ do.)
19:25:30 <pjones> we should certainly try to make as little as possible in the
distro depend on it
19:25:33 <skvidal> dropping lsd is probably not a good idea
19:25:33 <notting> there's already a bug for making redhat-lsb more granular
19:25:40 <skvidal> oh, wait - you said lsB!
19:25:42 <Kevin_Kofler> pjones: BTW, #354 is something I voted for and I didn't
write. :-)
19:25:42 <ajax> says you.
19:26:04 <pjones> Kevin_Kofler: a miracle!
19:26:07 <mjg59> I'm not enthusiastic about dropping a package just because
someone misused it
19:26:22 <pjones> so obviously -1 on the title to this proposal. but what /should/
be done?
19:26:26 <ajax> i would rather see lsb split more granularly, and have a guideline
that packages in fedora should not depend on the umbrella package.
19:26:36 <nirik> I am -1 on this at this time, but think we should ask packaging to
see about adding a guideline to not use lsb... then retire it when nothing uses it.
19:26:41 <ajax> the umbrella package is for portability for ISVs.
19:26:44 <Kevin_Kofler> The rationale for dropping redhat-lsb is that we don't
actually guarantee any level of actual LSB compliance.
19:26:47 <dgilmore> -1
19:26:47 <mjg59> Yeah, it makes sense for the lsb code to primarily be there for
*non*-Fedora packages
19:26:53 <pjones> or would we rather discuss this with #347?
19:26:59 <Kevin_Kofler> And in fact some of the tools don't even work and
don't get fixed, if Enrico is telling the truth.
19:27:12 <notting> Kevin_Kofler: nor do we guarantee POSIX compatibility, but we
don't drop -D_USE_POSIX
19:27:15 <ajax> i think 347 is a separate issue...
19:27:16 <mjg59> Kevin_Kofler: We don't actually guarantee any level of actual
POSIX compliance either
19:27:17 <cwickert> -1, dropping is not a solution. but what IS the solution here?
19:27:29 <skvidal> change the policy
19:27:30 <Kevin_Kofler> That said, I'm also -1 to dropping the package.
19:27:40 <notting> so, i think the proposal failed
19:27:41 <ajax> notting: what's the bug # for splitting lsb further?
19:27:41 <Kevin_Kofler> But the right solution is to explicitly ban packages from
using it.
19:27:48 <nirik> #agreed This proposal is rejected.
19:27:48 <mjg59> The lsb package does need fixing, so if the maintainer isn't
doing that then we should probably contact him directly
19:28:08 <nirik> perhaps we could ask for/get more lsb package maintainers?
19:28:09 <notting> proposal: have FPC investigate a guideline against direct
dependencies on redhat-lsb?
19:28:19 <notting> ajax: 47263{0,3}
19:28:22 <mjg59> notting: I'd be +1 on that
19:28:23 <nirik> +1 to nottings proposal.
19:28:32 <ajax> +1 @notting
19:28:32 <notting> also 245494
19:28:36 <cwickert> notting, +1, good starting point
19:28:39 <skvidal> +1
19:28:40 <Kevin_Kofler> The tor package's abuse of redhat-lsb probably also
violates the initscripts guidelines, but we'd also want to avoid any other redhat-lsb
deps in Fedora packages.
19:28:50 <pjones> +1 to notting
19:28:53 <Kevin_Kofler> +1 to the above proposal from notting.
19:28:57 <pjones> Kevin_Kofler: that's the next topic
19:29:03 <pjones> (maybe next, certainly later)
19:29:10 * notting is +1 to his own proposal
19:29:18 <dgilmore> +1
19:29:24 <nirik> who will take this to packaging?
19:29:48 <notting> i can
19:29:57 <nirik> #agreed FESCo asks FPC investigate a guideline against direct
dependencies on redhat-lsb
19:30:11 <nirik> #action notting will ask them to look into it.
19:30:20 <nirik> #topic #347 tor is not compliant with Fedora guidelines
19:30:25 <nirik> .fesco 347
19:30:27 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo
- Trac - https://fedorahosted.org/fesco/ticket/347
19:30:49 <nirik> I am still confused about which guideline it's not meeting...
non 0 return from post?
19:30:59 <nirik> .fesco 347
19:31:00 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo
- Trac - https://fedorahosted.org/fesco/ticket/347
19:31:06 <Kevin_Kofler> I see at least 2 guideline compliance issues:
19:31:08 * nirik fails a up arrow. ;)
19:31:13 <ajax> nirik: i think the consensus was that we really wished "output
from %post" was a guideline, but that it's not.
19:31:14 <Kevin_Kofler> 1. noisy scriptlet output and
19:31:28 <pjones> ajax: yeah, looks that way to me.
19:31:29 <Kevin_Kofler> 2. non-usage of standard initscripts scriptlet snippets.
19:31:32 <nirik> Kevin_Kofler: there is no guideline against scriptlet output. ;(
19:31:51 <Oxf13> there is just cranky releng / qa folks when that happens
19:31:57 <Kevin_Kofler> I think the usage of subpackages for the initscripts is also
outright bizarre.
19:32:10 <Oxf13> although I think we'd prefer that failures did get logged
somewhere, but perhaps not all over the screen
19:32:11 <pjones> I think I'm more concerned that it's using the lsb
initscripts stuff than that it's using "nonstandard" scriptlets.
19:32:14 * dgilmore does not see what it is volating
19:32:16 <Oxf13> or lost behind packagekit
19:32:21 <dgilmore> though it could probably be cleaner
19:32:23 <Kevin_Kofler> He should use the one style of initscripts we support (as
written in the guidelines) and put those in the main package, using the standard
snippets.
19:32:50 <Kevin_Kofler> Oxf13: This isn't actually a failure, at least not one
that matters to the actual user.
19:33:02 <notting> scripts, for reference: http://fpaste.org/8mIc/
19:33:11 <Oxf13> Kevin_Kofler: I'm talking in general, not specific to Tor
19:33:13 <Kevin_Kofler> And it wouldn't happen if his initscripts-related
snippets were compliant with the initscripts guidelines.
19:33:14 <nirik> for the record I dispise the tor and clamav packaging. I find it
overcomplex, confusing for users, difficult for other maintainers, and for no gain for
99.99% of fedora users.
19:33:23 <skvidal> nirik: +1
19:33:28 <nirik> that said, I don't think it's violating any guidelines. ;(
19:33:34 <Oxf13> Kevin_Kofler: I do twitch a little when I see 2>&1 >
/dev/null stuff in scriptlets
19:33:51 <dgilmore> nirik: i generally dont like the fedora-usermanagement stuff
19:33:52 <Kevin_Kofler> nirik: IMHO it violates both the letter and the spirit of
the guidelines for initscripts.
19:34:04 <dgilmore> ebut im not about to ask that it be removed
19:34:08 <Kevin_Kofler> But all the other Enrico-isms are also weird.
19:34:13 <ajax> okay, so, i count two issues
19:34:13 <Kevin_Kofler> Subpackage abuse in particular.
19:34:31 <ajax> 1) not using standard initscripts practice:
http://fedoraproject.org/wiki/Packaging/SysVInitScript
19:34:57 <ajax> 2) chatty scriptlets are lame
19:35:19 <ajax> 2 is pretty clearly just something someone needs to write down.
19:35:33 <ajax> you can't rely on scriptlet output ever being seen
19:35:44 <nirik> ajax: except new yum does save it. ;)
19:35:49 <notting> we only ban interactive scriptlets?
19:35:49 <pjones> so I propose that we ask FPC to codify #2, and in the mean time
ask enrico to fix #1
19:35:59 <pjones> notting: right, not noisy ones.
19:36:12 <dgilmore> pjones: thats reasonable
19:36:48 <ajax> pjones: he will almost certainly refuse to fix #1 until #522053 is
fixed
19:37:04 <ajax> which is fair, i suppose
19:37:13 <nirik> .bug 522053
19:37:15 <zodbot> nirik: Bug 522053 install_initd fails on Required-Start -
https://bugzilla.redhat.com/show_bug.cgi?id=522053
19:37:17 <pjones> ajax: my thought was more that he shouldn't be using
install_initd ...
19:37:27 <Kevin_Kofler> Indeed.
19:37:43 <Kevin_Kofler> install_initd has no business being used by any Fedora
package.
19:37:53 <Kevin_Kofler> The initscript guidelines clearly write down what to use.
19:37:56 <pjones> install_initd, while broken, seems like something exclusively
reserved for non-fedora packages.
19:38:04 <ajax> does he have other packages where he does this?
19:38:04 <cwickert> exactly
19:38:04 <nirik> ok, shall we vote on pjones proposal?
19:38:09 <mjg59> +1
19:38:12 <pjones> +1
19:38:13 <cwickert> ajax, I hope not
19:38:14 <nirik> +1 here
19:38:17 <ajax> +1 @pjones
19:38:20 <cwickert> +1 to pjones
19:38:24 <Oxf13> before it's lost, I think what pjones just said should be added
tothe initscripts guideline
19:38:25 <skvidal> +1
19:38:30 <Oxf13> (not using install_initrd within Fedora)
19:38:31 <Kevin_Kofler> +1 to pjones's proposal.
19:38:37 <nirik> ajax: I don't think clamav does, because clamd only ships a
sample script you must modify for your specific use case.
19:38:40 <ajax> cwickert: i have to imagine he does it this way because he thinks
there's some good reason to
19:38:53 <pjones> Oxf13: that should be an FPC dictum, I suspect.
19:38:57 <dgilmore> +1 to pjones
19:39:01 <pjones> (so let's ask them to ban it ;)
19:39:18 <Oxf13> pjones: just what I meant.
19:39:24 * notting closes 522053
19:39:25 <nirik> #agreed FESCo will ask tor maintainer to not use install_initd and
will see if FPC can codify scriptlet output issues.
19:39:29 <Kevin_Kofler> pjones: It's a bit redundant with banning redhat-lsb
usage entirely as we've just asked FPC to.
19:39:36 <Oxf13> ajax: he uses Fedora packages, but not really Fedora. He hacks the
crap out of it for his own personal OS
19:39:43 * nirik wonders if he summed up correctly what people voted for?
19:39:43 <pjones> Kevin_Kofler: I'm all for one action that bans both
19:39:46 <Kevin_Kofler> (see the previous meeting point)
19:39:51 <pjones> nirik: seems about right
19:40:07 <Oxf13> Kevin_Kofler: that's probably my fault, I didn't realize
install_initrd was an lsb function
19:40:11 <nirik> ok, who will talk to tor maintainer, and who will talk to FPC?
19:40:21 <dgilmore> install_initd sounds like it should be a wrapper for chkconfig
19:40:24 * nirik tries to make sure this stuff gets followed up on. ;)
19:40:32 <skvidal> nirik: speaking of following up
https://fedoraproject.org/wiki/FESCo/SuccessionPlanning
19:40:54 <nirik> I can update the bug for the tor maintainer if no one else wants
to.
19:41:08 <nirik> skvidal: excellent.
19:41:11 <notting> dgilmore: it's a symlink.
19:41:44 <nirik> #action nirik will contact tor maintainer
19:41:56 <nirik> who wants to talk to FPC about scriptlet output?
19:42:08 <dgilmore> notting: :) we should ask fpc to give us a guideline then that
says use chkconfig only and not install_initd just for clarity
19:42:12 <pjones> dgilmore: it actually parses lsb-only crap in the initscript and
does shit based on it
19:42:34 <pjones> dgilmore: lsb basically re-implements sysv init scripts +
chkconfig in its own wildly sillier way.
19:42:53 <nirik> and our current guidelines say they are not required, but can be
used.
19:43:12 <pjones> right. but we should be clear that that's about the stuff in
the initscript, not the use of the associated shitty stupid tools.
19:43:13 <dgilmore> pjones: eww
19:43:17 <Kevin_Kofler> Yet our review guidelines say we should verify compliance of
initscripts with the initscripts guidelines.
19:43:23 <Kevin_Kofler> (if I'm not mistaken)
19:43:54 * nirik notes we are coming up on 15min on this topic.
19:43:59 <ajax> compliance with the guidelines does not mean implementing all
optional features.
19:44:03 <notting> dgilmore: note that chkconfig invoked as install_initd does
change the behavior slightly
19:44:15 <Oxf13> question from the peanut gallery, how much of this "goes
away" if/when we move to full upstart init style?
19:44:16 <notting> and i think that's enrico's bug. install_initd is
actually enforcing the standard.
19:44:33 <notting> Oxf13: oh, i suspect we'll get an entirely different set of
issues then.
19:44:40 <nirik> "LSB Headers are not required for Fedora SysV-style
initscripts, but they may be used. There is no requirement in the LSB certification for
any system scripts to be LSB compliant, and it can cause issues with ordering."
19:45:36 <nirik> no takers on talking to FPC about scriptlet output?
19:45:40 <ajax> i really don't want to have to cite rfc2119 in the guidelines,
but, here we are.
19:45:44 <ajax> nirik: i'll do that.
19:45:51 <nirik> hurray.
19:46:02 <nirik> #action ajax will talk to FPC about scriptlet output
19:46:16 <nirik> #topic #355 Let rel-eng untag embryo from F-13 because it breaks
the chain and upgrade path
19:46:21 <nirik> .fesco 355
19:46:23 <zodbot> nirik: #355 (Let rel-eng untag embryo from F-13 because it breaks
the chain and upgrade path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/355
19:46:27 <nirik> cwickert: just updated this
19:46:49 <nirik> so, I am happy with waiting a week to give them a chance to fix
it.
19:46:54 <pjones> I think we should probably untag this, since people may have it
installed but they certainly can't be /using/ it.
19:47:10 <Oxf13> yeah, it's extremely unlikely they would have installed it
19:47:12 <mjg59> pjones: But if they've managed to get it installed, updates
will then be broken?
19:47:13 <Oxf13> let alone use it
19:47:18 <Kevin_Kofler> Untagging without an Epoch bump means making the version go
backwards.
19:47:29 <nirik> please read the last comment in the ticket.
19:47:35 <Kevin_Kofler> So it has been suggested that they should just bump Epoch.
19:47:40 <Oxf13> Kevin_Kofler: which is only really a problem if it's actually
been on somebody's system.
19:47:47 <cwickert> IMO this really is a social problem
19:47:48 <Kevin_Kofler> But maybe upgrading the whole stack instead would be the
better solution.
19:47:51 <thomasj_> Nobody will have it installed. It's only used for
Enlightenment.
19:47:54 <cwickert> cassmodiah, can you comment on this?
19:47:59 <Kevin_Kofler> It's already done in Rawhide, it just needs to go into
F13.
19:48:16 <mjg59> Oh, fine
19:48:19 <mjg59> Just leave it for a week
19:48:22 <notting> Kevin_Kofler: ok then. go forth and do, etc.
19:48:31 <ajax> +1 to defer for a week
19:48:41 <Kevin_Kofler> Well, actually it's not complete in Rawhide yet.
19:48:44 <notting> +1 to defer
19:48:49 <dgilmore> -1 to untagging the build
19:48:51 <pjones> Kevin_Kofler: no, putting in a new package reusing the old VR
makes the version go backwards. either way, I'm +1 to defer.
19:48:54 <cassmodiah> i think 1 week isn't enough. I'm currently not
briefed
19:48:57 <cwickert> +1, give them a week to fix ot. not a fesco thing IMO
19:49:03 <nirik> +1 to waiting and revisiting
19:49:06 <Oxf13> thomasj_: do not underestimate the ability for our users to do
silly things we never expect them to do (:
19:49:07 <cwickert> cassmodiah, che will help you
19:49:18 <pjones> mjg59: updates wouldn't be broken so long as the next version
is still newer than the broken one (i.e. release=2 or whatnot.)
19:49:34 <Kevin_Kofler> I'm a bit worried about the schedule for doing an update
of the whole E17 stack for Rawhide now.
19:49:39 <skvidal> +1
19:49:42 <cassmodiah> cwickert i hope that this help isn't too late! :-/
19:49:43 <thomasj_> cwickert, by the way, thanks for the social comment. I will
bring it up again later in a different discussion.
19:49:55 <thomasj_> Oxf13, you're right ;)
19:49:59 <cwickert> thomasj_, welcome
19:50:13 <dgilmore> We have in the past refused requests like this
19:50:23 <Kevin_Kofler> pjones: The point is, it will not be! The proposal is to
revert to an old build without an Epoch bump.
19:50:25 <Oxf13> dgilmore: we have when it was already on people's systems
19:50:35 <dgilmore> I think we need to be consistent and have them fix the issue in
the packaging
19:50:44 <Oxf13> the way I see it, currently nobody can install/test E stuff
19:50:52 <pjones> Kevin_Kofler: right, but that doesn't matter as long as
there's another update /after that/ that fixes the problem and has a newer VR than the
broken one.
19:50:52 <thomasj_> yep
19:50:56 <Oxf13> so we could gain back a week of some limited testing by untagging
19:50:57 <dgilmore> Oxf13: there is no reason that they cant just build a new nvr
19:51:12 <dgilmore> the latest tagged package will win
19:51:12 <thomasj_> Oxf13, and if the new packages go into F-13 it is untested.
19:51:13 <pjones> Kevin_Kofler: the people with a broken version already will remain
affected, it's true, until there's a Real Fix.
19:51:15 <Oxf13> then when everything is ready to go to the newer stuff, we can
re-tag, or get a new build.
19:51:16 <cwickert> Oxf13, the old stuff was tested and used for two years now
19:51:32 <pjones> Oxf13: yeah, that's what I'm seeing
19:51:38 <Kevin_Kofler> dgilmore: That's also against the same "the branch
should not go backwards" rule though.
19:51:40 <Oxf13> cwickert: which doesn't mean it will work with the rest of F13
19:51:46 <cwickert> true
19:52:00 <Oxf13> so the real question here, to me, is how important is that week~ of
testing?
19:52:03 <Kevin_Kofler> And it has no real advantage over just untagging the newer
unwanted build.
19:52:06 * thomasj_ want's the old stuff in F-13 for now, that's why i asked
rel-eng to untag it.
19:52:10 <Oxf13> are the E folks OK with it being impossible to install for a
while?
19:52:26 * thomasj_ thinks it's better to have the new stuff tested first
19:52:38 <nirik> an addition week of testing the already known stable one
doesn't seem to usefull.
19:52:38 <cwickert> Oxf13, I guess, it's already broken for weeks and nobody
complained
19:52:54 <nirik> but it does mean that new users can't install it for now.
19:53:01 <Kevin_Kofler> thomasj_: If you want the old stuff in F-13, then bump
Epoch.
19:53:15 <Oxf13> Kevin_Kofler: that's completely unnecessary
19:53:18 <nirik> (and in rawhide as well to preserve upgrade path)
19:53:23 <cwickert> I think this can be fixed within one or two days, if all people
work together
19:53:25 <thomasj_> Kevin_Kofler, i can do that as well. cwickert told me to ask
rel-eng
19:53:28 <Kevin_Kofler> nirik: Right.
19:53:49 <thomasj_> Kevin_Kofler, and rel-eng said they need the ok from FESCo
there.
19:53:53 <nirik> so, we have enough votes to defer and revisit, shall we just do
that and move on?
19:53:56 <Oxf13> how about we actually look past the words of a rule, and try to
understand the /reason/ for the rule
19:54:00 <cassmodiah> cwickert +1 this can be fixed soon, if there is any teamwork
19:54:08 <Kevin_Kofler> Oxf13: Isn't the current policy that Rawhide should
never go backwards, let alone branched releases?
19:54:16 <Kevin_Kofler> I don't care all that much about that policy.
19:54:26 <Kevin_Kofler> But if we don't want to enforce it, why do we have such
a policy at all?
19:54:41 <Oxf13> Kevin_Kofler: such a policy exists yes, to protect users from being
left out in the cold if the package they have installed goes backwards
19:54:48 <Kevin_Kofler> (FWIW, I think Rawhide or unreleased releases going
backwards is not a big problem.)
19:54:50 <Oxf13> in this case, it is extremely unlikely anybody actually has this
package installed
19:55:00 * nirik does. ;)
19:55:00 <Oxf13> /and/ there would be a newer n-v-r coming soon, after testing
19:55:29 <cwickert> Oxf13, they *cannot* install the package because it's
broken/the broken deps prefent people from installing it
19:55:33 <Oxf13> untagging may break the words of the rule, but certainly not the
spirit or reason for the rule.
19:55:39 <notting> if it's going to be fixed soon, just fix it
19:55:40 <Oxf13> cwickert: that's... not true
19:55:47 <nirik> cwickert: not true. You can install it by itself. You can't
install it with any of the rest of the stack
19:55:49 * cwickert looks...
19:55:53 <abadger1999> cwickert: .... they could have installed embryo without the
other deps.
19:56:00 <mjg59> Do we need to discuss this any further?
19:56:01 <thomasj_> yep
19:56:06 <thomasj_> oh, yep to abadger1999
19:56:23 <dgilmore> mjg59: nope we need to say that it cant be untag and needs fixed
within the packaging
19:56:23 <nirik> I guess we have votes to defer and revisit...
19:56:24 <cwickert> I doubt that anybody has installed it embryo, it's not in
comps, it's a lib
19:56:40 <thomasj_> Yep
19:56:45 <Oxf13> cwickert: right, which is why I said it's highly unlikely, but
not impossible.
19:56:54 <cwickert> ok then Oxf13
19:57:05 <nirik> I have it installed... because I was curious about it... others
might have installed it due to our dicussions?
19:57:14 <Kevin_Kofler> Well, the lead Release Engineer says we should just untag
this.
19:57:25 <mjg59> But we've also decided that we can leave it for a week
19:57:31 <Kevin_Kofler> So IMHO we should do as he said.
19:57:42 <Oxf13> untagging would actually be better than leaving it for a week and
waiting for a fix
19:57:50 <Kevin_Kofler> His arguments make sense.
19:57:51 <pjones> yeah, I'm with Oxf13 here
19:57:51 <Oxf13> untagging would allow people who want to install E to actually be
able to
19:58:00 <mjg59> Oxf13: Ok, fine, utterly happy to defer to you on this
19:58:17 <pjones> right. people with it already installed will have a broken one,
but everybody else avoids damage. untagging is best.
19:58:17 <Oxf13> the time to fixed package doesn't really change here.
19:58:25 <cwickert> +1 for untagging, but rel-eng closed the untag request WONTFIX
19:58:34 * notting defers to Oxf13, then. +1 to untag
19:58:39 <mjg59> +1 for untagging
19:58:42 <dgilmore> anytime something like this has come up we have consistently
said if it has been pushed to rawhide(i.e. any repo really) it can not be untagged and
needs to be fixed via a epoch if it must go backwards
19:58:45 <Kevin_Kofler> +1 to untagging (and we can reopen the rel-eng request)
19:58:47 * nirik shrugs. I don't much care except that we might get more people with
diffrerent issues asking us to untag things.
19:58:49 <pjones> +1 for untagging since I've said that like 50 times now.
19:58:58 <notting> cwickert: rel-eng was not going to break policy to untag w/o
fesco approval, as i understand it
19:59:06 <dgilmore> there is a reason we ahve always said no to untagging
19:59:07 * skvidal is with nirik - having hard time caring
19:59:09 <Oxf13> dgilmore: the reason behind that is to protect people who have
potentially installed it.
19:59:10 <cwickert> notting, i see
19:59:12 <ajax> 0, don't care, just make it go away.
19:59:17 <Oxf13> dgilmore: please please read past the bare words of the rule.
19:59:20 <skvidal> ajax: I like this answer
19:59:23 <dgilmore> Oxf13: right and people may have in this case also
19:59:26 <mjg59> I think we're done
19:59:32 * nirik tallys
19:59:37 <pjones> dgilmore: right, but not untagging it doesn't protect them any
in this case
19:59:37 <dgilmore> Oxf13: at least nirik has it installed
19:59:46 <mjg59> Especially as we'll be at 15 minutes in 2 minutes
19:59:50 <cwickert> untag and revisit next week (if still necessary)
19:59:57 <cwickert> period
20:00:08 <nirik> #agreed FESCo will allow releg to untag this package for now,
revisit this next week if there are still issues.
20:00:14 <mjg59> Full stop carriage return carriage return THE END
20:00:18 * dgilmore is going to leave the meeting now
20:00:19 <mjg59> Ok
20:00:28 <thomasj_> Thank you.
20:00:28 <nirik> #topic #348 Fedora Packaging Committee items for ratification
(2010-02-24)
20:00:38 * nirik sighs
20:00:40 <Oxf13> untagged.
20:00:46 <mjg59> Does anyone have any arguments against these proposals?
20:00:54 <nirik> .fesco 348
20:00:54 <ajax> nope.
20:00:55 <zodbot> nirik: #348 (Fedora Packaging Committee items for ratification
(2010-02-24)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/348
20:00:58 <pjones> I vote we rubber stamp these with great force.
20:01:08 * skvidal waits for it
20:01:19 <ajax> i say your three cent titanium tax doesn't go too far enough.
20:01:29 <ajax> +1
20:01:30 <nirik> should we do them one at a time?
20:01:31 <cwickert> +1 to all of them
20:01:44 <mjg59> nirik: Unless anyone has any arguments against, no real point
20:01:49 <nirik> true.
20:01:49 * notting is +1 to both
20:01:51 <nirik> +1 to both
20:01:52 <mjg59> Both seem sane, so I'm +1 to both
20:02:00 <Kevin_Kofler> Wait a minute…
20:02:00 <pjones> looks like 5.
20:02:01 <skvidal> +1 to both
20:02:06 <Kevin_Kofler> About the "Add a Dummy Macro" part.
20:02:16 <Kevin_Kofler> Can we not just mass-change all the packages instead?
20:02:30 <mjg59> Kevin_Kofler: My recollection is that one of the font maintainers
was unhappy about doing so
20:02:46 <Kevin_Kofler> That's what we have provenpackagers for.
20:02:56 <nirik> Kevin_Kofler: there are also still font packages that don't use
the current guidelines.
20:02:56 <Kevin_Kofler> But I'm +1 to both guideline changes.
20:02:58 <mjg59> And while we could mandate that, the packaging committee have found
a mechanism that doesn't require it
20:03:20 <mjg59> So, while it's not ideal, it's also not obviously damaging
20:03:20 <pjones> yeah, I think the reason for the dummy macro is really that we
expect packages to lag behind the guidelines, if only slightly.
20:03:28 <ajax> i would certainly prefer that all the font packages be updated, but
i'm not going to insist on it this week.
20:03:30 <nirik> #agreed Both guidelines changes are accepted.
20:03:36 <skvidal> next!
20:03:46 <nirik> #topic Fedora Engineering Services Tickets/Updates.
20:03:56 <nirik> I don't have much to report here, so I am not going to go over
them all.
20:04:04 <nirik> There is steady progress on most of the larger ones.
20:04:11 <nirik> mmcgrath: you have anything to note?
20:04:33 <mmcgrath> Nothing major, incremental progress from last week. I got a few
broken deps fixed
20:04:47 <mmcgrath> For the most part though it seems most of the broken deps are
actually known by the packagers.
20:05:05 <nirik> cool.
20:05:08 <mmcgrath> It's just the fix sometimes requries work from upstream.
20:05:12 <mmcgrath> so generally things are good.
20:05:29 <nirik> if anyone would like to join in and help things, follow the wiki
page...
20:05:37 <nirik> if anyone has additional tickets to work on, file away.
20:05:41 <nirik> thanks mmcgrath
20:05:47 <nirik> and now the fun part. ;)
20:05:52 <nirik> #topic #351 Create a policy for updates
20:05:56 <nirik> .fesco 351
20:05:57 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/351
20:06:10 <nirik> notting made a number of changes last week.
20:06:27 <notting> yeah, i made some changes after talking with QA
20:06:30 <nirik> Kevin_Kofler has some amendments to discuss.
20:06:42 <nirik>
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:06:48 <notting> if it makes things simpler, we can vote on each of the three
segments separately
20:06:51 <nirik> can everyone take a minute to just re-read the proposal?
20:06:54 <notting> they stack on top of each other, more or less
20:07:30 <adamw> quick note: QA is still working on a policy to document the whole
process of how updates are actually managed
20:07:33 <Kevin_Kofler> FWIW, I'm also still -1 to the proposal as a whole, even
amended, as I don't see a need for such a policy at all.
20:07:41 <wwoods> ...
20:08:10 <Kevin_Kofler> But if the policy is taken as a given, then let's at
least get my amendments to a vote (and hopefully approve them).
20:08:12 <pjones> Kevin_Kofler: can we just take that as a given from here on out?
20:08:21 <adamw> since last week's meeting didn't show much enthusiasm for
merging it with notting's policy on update requirements during the draft phase, and
notting said he'd prefer to work on his update requirements document just as it is for
now, i'm trying to nudge the broader QA proposal in the direction of being a
'shell' into which notting's update requirements document would plug
20:08:49 <pjones> adamw: sounds backwards.
20:08:50 <adamw> so fesco could approve notting's requirements policy and then
consider the broader process policy whenever we're done drafting it, and the agreed
requirements policy would not need to change
20:09:39 <adamw> pjones: how do you mean?
20:09:58 <jlaska> pjones: notting's proposal focuses on package acceptance
criteria, which is what QA is hoping to get consensus on so we can refine
https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_accept...
20:10:26 <pjones> jlaska: yes, but wedging something else around it later sounds
unlikely to produce fruitful results
20:11:04 <nirik> so, how should we move forward here? shall we discuss
Kevin_Kofler's amendments first? or decide we want more QA buyin of nottings proposal
in general before voting?
20:11:09 <adamw> pjones: i don't think it's particularly tricky, we just
yank the stuff about specific requirements out of the draft we had last week, and instead
link into notting's policy when saying what the actual requirements to move from step
to step are
20:11:49 <nirik> adamw: so, nottings proposal would be a subset of the overall
updates qa flow?
20:11:53 <notting> nirik: i'd like to offer up section 1 for a vote first. i
would think it's the least controversial, and Kevin didn't have an amendment to
it
20:12:01 <nirik> ok.
20:12:22 <nirik> I have a question. ;) Point 4.... is that taking into account
multilib? ;)
20:12:36 <adamw> nirik: right. and if we never manage to agree on a policy to cover
the whole process, notting's policy on requirements can still stand alone. so i think
the approach is fairly safe.
20:12:39 <notting> nirik: sure.
20:12:48 <Oxf13> fwiw, from a releng pov, section 1 is very good
20:12:59 <nirik> so, packages with broken multilib would fail and be unable to push
as updates?
20:13:04 <notting> nirik: the overriding theme of those requirements is DON'T
BREAK THE REPO
20:13:07 <Oxf13> in fact, it's the type of thing I plan to put as a barrier of
entry to /any/ published Fedora package collection
20:13:15 <Oxf13> eg rawhide, branched, etc...
20:13:28 <nirik> in any case thats nitpicking. I'm +1 for section 1.
20:13:32 <pjones> adamw: I don't think you're necessarily wrong. I do think
we shouldn't discuss this until after we've /got/ a policy ratified.
20:13:48 <Kevin_Kofler> +1 to section 1, that's something that sounds obvious
even to me. :-)
20:14:10 <Kevin_Kofler> (and it's pretty much why AutoQA is being developed in
the first place)
20:14:40 <nirik> ok, thats +1
20:14:44 <nirik> +2 rather
20:15:02 * notting is +1, obvs.
20:15:03 <mjg59> +1
20:15:04 <Kevin_Kofler> Though maybe "Packages must not break upgrade
path" should be clarified to ensure that it's possible to queue the same update
to multiple releases at the same time.
20:15:05 <abadger1999> Question on scope: Does this section (or the whole policy)
cover updates only or updates + updates-testing?
20:15:06 <cwickert> +3 at least ;)
20:15:09 <adamw> pjones: yeah, no, i agree, at this meeting, just discuss
notting's proposal. i just wanted to make sure the fate of QA's proposal was on
the record in case anyone wondered where it had disappeared to after last week =)
20:15:30 <nirik> abadger1999: see the bottom of that section.
20:16:04 <nirik> "As a discussion point, some subset of these tests could be
run on pending updates, and the results used to block updates going to updates-testing as
well."
20:16:09 <pjones> what, precisely, is being voted on?
20:16:21 <nirik> pjones:
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:16:21 <notting> pjones: section 1 of the proposal.
20:16:22 <abadger1999> ah... so pending updates are updates in updates-testing, not
updates that are pending in bodhi...
20:16:23 <nirik> section 1
20:16:27 <pjones> +1 to section 1 then
20:16:42 <nirik> abadger1999: yeah, I guess thats confusing...
20:16:42 * skvidal +1's section one
20:17:00 <nirik> #agreed Section 1 of the proposal is approved.
20:17:08 <nirik> next section.
20:17:08 <ajax> +1 to section one (late)
20:17:14 <Oxf13> Kevin_Kofler: re multiple updates at the same time, lets leave that
for implementation
20:17:24 <notting> ok, section 2. Kevin_Kofler has an amendment to this section.
20:17:29 <adamw> section 1 lists whether the tests should be applied to
updates-testing as a 'discussion point'
20:17:32 <adamw> was that settled yet?
20:17:50 <mjg59> adamw: Given that we've already voted on it, can we please
delay discussion until later?
20:18:01 <nirik> adamw: no. We could discuss adding that after?
20:18:21 <adamw> nirik: sure, so for now it's unsettled.
20:18:26 <nirik> adamw: yep. ;)
20:18:33 <notting> i'm not in favor of Kevin_Kofler's amendment, as rather
than "ensur[ing] the SIGs controlling the desktops can make autonomous decisions
about when to push updates to their desktops without being reliant on external groups such
as QA.", i'd prefer the SIGs work with and within QA
20:18:54 * skvidal is -1 to the amendment, too
20:19:14 <Kevin_Kofler> Can we at least seed the initial list with at least 1 member
of each desktop's SIG until we have more of it?
20:19:16 <mjg59> Wait
20:19:17 <nirik> I would also be -1, but I would hope the criteria to be a
proventester would allow anyone from those SIGs who already does testing to be able to
have that status
20:19:17 <Oxf13> where is this amendment ?
20:19:24 <mjg59> Are we voting on the amendment, or the amended proposal?
20:19:26 <nirik> Oxf13: in the ticket.
20:19:33 <ajax> Oxf13: https://fedorahosted.org/fesco/ticket/351#comment:12
20:19:52 * nirik thought we were voting on the amendment. Should we vote on the proposal
first?
20:19:56 <Kevin_Kofler> I'd nominate rdieter for KDE, he's done that
"job" as a rel-eng member for pending releases so far and he did it well (even
for non-KDE packages).
20:19:58 <mjg59> And, given the constraints Kevin imposed, are we looking at section
two or section 3?
20:20:07 <skvidal> I think we are looking at
20:20:08 <skvidal> Amendment proposal C: In section 2, codify that the group of
testers empowered to give the magic karma needs to include at least 1 member (or in the
event the criteria get changed to require some karma n rather than 1, n members) of each
SIG behind one of the desktops considered "critical" by section 2.
20:20:08 <skvidal> Rationale: This ensures the SIGs controlling the desktops can
make autonomous decisions about when to push updates to their desktops without being
reliant on external groups such as QA.
20:20:16 <mjg59> nirik: It's generally faster to just vote on the amended
proposal
20:20:19 <adamw> for information, the current proposal for having people become
'proven testers' is
http://lists.fedoraproject.org/pipermail/test/2010-February/088824.html . it's still
heavily under discussion, though
20:20:22 <mjg59> nirik: That way you don't need to have a second vote if it
passes
20:20:45 <Oxf13> fwiw, as an outsider, I'm also against that amendment.
20:20:50 * gholms|mbp rings the 15 minute bell
20:20:52 <Oxf13> to date, we do not have any criteria for the proventesters group
20:21:11 <nirik> yeah, 15min. ;) Shall we continue? votes?
20:21:13 <nirik> +1 here
20:21:14 * cwickert would like to give this another 15 minutes
20:21:15 <pjones> adamw: please stop injecting confusion to this discussion. it is
not helping.
20:21:16 <mjg59> Continue
20:21:16 * notting is +1 to continuing discussion
20:21:18 <Oxf13> therefor the amendment text would be better served on the proposal
for the proventesters group composition
20:21:19 <skvidal> +1 to continuing
20:21:27 <pjones> I think we should continue. What's the url for kevin's
amendment?
20:21:34 <Oxf13> leaving the updates policy to just reference the proventesters
group
20:21:40 <nirik> pjones: https://fedorahosted.org/fesco/ticket/351#comment:12
20:21:49 <adamw> pjones: it was in response to nirik's question about the
criteria to be a proven tester. i thought that in context it would be fairly helpful for
nirik to see what the discussion about those criteria was.
20:21:52 <pjones> Oh, it's on the ticket. how interesting.
20:22:16 <nirik> I would hope that sigs/desktops/important app/critical path using
people would be able to become proventesters.
20:22:29 <Oxf13> they should be
20:22:30 <adamw> nirik: at present i think that's very likely to be the case.
oxf13 would you agree?
20:22:31 <nirik> especially those people who already do that kind of testing for
their sig/app/desktop/etc
20:22:49 <nirik> ie, if KDE has some folks who do a lot of their testing, I would
hope they would be able to get this status...
20:23:00 <Oxf13> proventesters would be in line with provenpackagers, no real
restrictions on who can join, just a criteria to meet and peer approval
20:23:03 <nirik> so, no need to mandate it.
20:23:25 <nirik> Kevin_Kofler: would that meet your concerns?
20:23:49 <Kevin_Kofler> I guess it would.
20:23:56 <nirik> so, any other general comments on section 2?
20:24:03 <Oxf13> but again, any sort of verbiage about who makes up the 'defined
group of testers' should go in the proposal and policy for proventesters, not in the
update policy
20:24:12 <nirik> notting: we don't have a current list do we?
20:24:28 <notting> nirik: list of...?
20:24:41 <nirik> notting: 'important packages'
20:24:52 <Kevin_Kofler> Other than that I don't see the need for such added
bureaucracy at all? :-) (But section 3 is the worst.)
20:25:03 <notting> there is the critical path list. we can, if people want, expand
the definition of critical path as described
20:25:08 <nirik> Kevin_Kofler: we will get to 3 next. ;)
20:25:13 <wwoods> Kevin_Kofler: think we agreed to take that objection as a given.
20:25:16 <nirik>
http://kojipkgs.fedoraproject.org/mash/branched-20100316/logs/critpath.log
20:25:18 <notting> in which case, it's just a matter of tweaking the tools that
create that llist
20:25:27 <abadger1999> Is there a rationale for having two separate lists (critpath
and non-critpath important packages).
20:25:38 <nirik> notting: ok, but it currently doesn't have KDE/LXDE/XFCE in it.
;)
20:25:45 <adamw> i thought the original reason we came up with critpath in the first
place was to feed into a policy like this
20:25:46 <nirik> abadger1999: which is?
20:25:53 <Oxf13> for the sake of the proposal at this time, I think section 2 lists
enough package names in addition to critpath
20:25:59 * nirik notes that still has the xfce4-notifyd thing in it.
20:26:12 <cwickert> nirik, this is a yum problem
20:26:14 <adamw> so it would seem a bit odd to have critpath exist and then be
expanded when we actually use it. would we actually use the non-expanded critpath list for
anything?
20:26:15 <notting> abadger1999: only that critpath is not currently defined for the
other desktops, and i think this proposal should cover them
20:26:22 <wwoods> there's definitely rationale for having multiple layers above
critpath; section 2 seems to be defining one of those layers
20:26:35 <abadger1999> notting: In that case, I'd rather see critpath
expandedtoo voer them instead.
20:26:38 <Kevin_Kofler> That's also something kinda weird: Why would those be
critical for updates, but not for new releases?
20:26:39 <wwoods> no.
20:26:49 <skvidal> cwickert: a yum problem?
20:26:50 <Oxf13> .... and we're getting lost in teh weeds
20:26:51 <Oxf13> look
20:26:57 <notting> ok, duly noted... separate proposal:
20:27:02 <Oxf13> does it really matter if the packages are 'critpath' or
"critpath + some other stuff' ?
20:27:03 <abadger1999> * expanded to cover them
20:27:06 <Oxf13> that's not the real issue here
20:27:06 * nirik thinks this is a sort of implementation detail.
20:27:10 <skvidal> yes
20:27:12 <Oxf13> nirik: very much so
20:27:13 * notting redacts his typing
20:27:15 <abadger1999> Oxf13: Implementatoin wise, yes.
20:27:23 <mjg59> I'm +1 for section 2 as is
20:27:38 <Oxf13> abadger1999: for the sake of "does this policy make sense to
work toward" it really doesn't matter.
20:27:41 <wwoods> "critpath" has a specific definition that (e.g.) does
not include desktops other than the default. If you want to define another larger group
that's a superset of critpath, that's an excellent idea
20:27:45 <mjg59> And now I'm going to find some caffeine
20:27:46 * notting is +1 for section 2 as written
20:27:49 <Kevin_Kofler> skvidal: It picks the notification daemon with the shortest
name because the requirement is intentionally not specific.
20:27:55 <abadger1999> Oxf13: We can now modify critpath in the pkgdb... maintaining
a second list for no reason means extra coding needs to be done in pkgdb and the mash
driver script. bpodhi, etc
20:27:57 <cwickert> skvidal, right, both notification-deamon and xfce4-notifyd
provide "desktop-notification-daemon" and this makes yum think that several xfce
packages are critical path
20:27:58 <nirik> I'm +1 for section 2 and we can worry about the implementation
details later.
20:28:11 <Kevin_Kofler> Not really a "problem" in yum, but in the way yum
is being used to compute transitive closure here.
20:28:12 <Oxf13> abadger1999: again, not really important for today's meeting
and today's vote.
20:28:15 <skvidal> cwickert: and how is that yum's fault - specify what you
mean...
20:28:18 <pjones> nirik: likewise.
20:28:25 * skvidal is +1 for section 2
20:28:32 <cwickert> skvidal, problem != fault
20:28:34 <wwoods> (and if you want to use those newly-defined larger groups in
various proposals/policies that's also excellent. but don't go throwing new things
into critpath willy-nilly.)
20:28:44 <abadger1999> Oxf13: Are you going to write the bodhi and pkgdb and mash
patches?
20:28:50 <mjg59> Ok, we're at 5 for section 2 as written
20:28:54 * nirik nods.
20:29:13 <cwickert> +1 for section 2
20:29:15 <mjg59> And we've got 30 minutes to get through section 3
20:29:16 <Kevin_Kofler> For the record: -1 to section 2, not needed.
20:29:17 <nirik> #agreed Section 2 is Approved. Implementation details will need to
be worked out for listing/noting important packages.
20:29:36 <nirik> ok, on to section 3.
20:29:51 <Oxf13> abadger1999: not if the proposal doesn't get approved because
we're too busy worried about the road signs 500 miles down the road and can't even
get intot he car and start driving.
20:29:55 <mjg59> I'd like to propose that we firstly vote on section 3 as
amended by Kevin's first proposal, ie the complete striking of section 3
20:29:55 <notting> Kevin's first amendment here i think can just be construed as
a -1 vote on this section
20:30:09 <mjg59> To which I am -1
20:30:13 <Kevin_Kofler> Right, the first proposal is to strike it entirely.
20:30:23 <pjones> I'm -1 to striking section 3
20:30:29 <nirik> mjg59: you are -1 to not remove it? man, thats a lot of negativity.
;)
20:30:33 <Kevin_Kofler> The second one is to at least allow 1 proventester to
approve stable pushes as for critical packages.
20:30:33 <abadger1999> Oxf13: How does having an accurate map before you get in the
car sound like a bad idea to you?
20:30:51 <Oxf13> abadger1999: we've moved on, you should too.
20:31:07 * skvidal is -1 to striking section 3
20:31:12 * nirik is -1 to striking section 3.
20:31:20 <Kevin_Kofler> +1 to striking section 3, for the reasons given in the
ticket.
20:31:29 * notting is -1 to pre-emtpively striking it
20:31:35 <skvidal> that's 5
20:31:37 <pjones> abadger1999: Oxf13 can you both quit it with the stupid
metaphors?
20:31:59 <mjg59> I see that as -5 to striking section 3
20:32:07 * nirik nods.
20:32:18 <nirik> #agreed Section 3 will not be entirely removed.
20:32:32 <notting> at least, not yet. it may not pass a approval vote... ;)
20:32:37 <cwickert> +1 for section 3, just for the record
20:32:46 <Kevin_Kofler> (i.e. -1 to striking it? :-) )
20:32:47 <ajax> so. on section 3. "the[ir] specified positive bodhi karma
threshold" is...
20:33:02 <notting> ajax: what the update maintainer specified on submission
20:33:06 <adamw> can that be 0?
20:33:12 * dgilmore proposes that new packages are not considered updates.
20:33:13 <notting> adamw: is 0 positive?
20:33:14 <nirik> 0 isn't positive
20:33:19 <ajax> 0 isn't positive (at least not in two's complement)
20:33:20 <adamw> i dunno, i took history, not math =)
20:33:35 <nirik> so, Kevin_Kofler has a amendment now for section 3.
20:33:35 * pjones votes adamw off the island
20:33:38 <skvidal> adamw: is 2000 or 2001 where the century turned over? :)
20:33:38 <adamw> (hence the question, now answered)
20:33:45 <pjones> skvidal: no.
20:33:53 <skvidal> pjones: it's a history question!
20:33:54 <skvidal> sorta
20:34:05 <notting> fwiw, i'm fine with considering Kevin_Kofler's amendment
B here (in essence, that this proposal is not ever more strict than part 2)
20:34:05 <ajax> ANYWAY
20:34:07 <pjones> by which I both want you to STFU and also neither of those is when
that event happened.
20:34:09 <Kevin_Kofler> The big problem with the first point of section 3 is: what
if I want to not have the package automatically be pushed to stable when reaching the
threshold, but have the option to push it?
20:34:15 * nirik is +1 for this amendment
20:34:26 <Kevin_Kofler> +1 for my own amendment, obviously. :-)
20:34:43 * notting is +1 for the amendment
20:34:43 <mjg59> Kevin_Kofler: Specify karma, don't specify automatically push?
20:35:03 <Kevin_Kofler> mjg59: Bodhi doesn't currently allow that.
20:35:05 <nirik> if we get a proventester to test the update, it should be no more
strict than the 'important packages' section.
20:35:18 <mjg59> Kevin_Kofler: That's an implementation detail
20:35:22 <nirik> (or proventesters as the case may be)
20:35:29 <mjg59> Just to clarify:
20:35:38 <mjg59> Are we voting on the amendment, or are we voting on the amended
proposal?
20:35:40 <dgilmore> mjg59: we are supposed to be working out the implementation
20:35:53 <ajax> amendment B does seem sensible, although i have trouble considering
it different than submitting an update with threshold 1
20:36:12 <Kevin_Kofler> mjg59: Given that striking failed, it's pretty much the
same.
20:36:15 <pjones> amendment b, though written in a terrible way that makes
considering it unnecessarily difficult, does seem sensible.
20:36:22 * gholms rings the 30 minute gong
20:36:30 <mjg59> +1 to continuing discussion
20:36:38 <skvidal> +1 to continuing the argument
20:36:41 <nirik> +1 here
20:36:42 <mjg59> Kevin_Kofler: The latter potentially saves us a vote
20:36:46 <Oxf13> ajax: a threshold of 1 would mean it would automatically go when 1
is hit, instead of not being able to go until at least 1 is hit
20:36:54 <pjones> in the future, can we all try to write "section 3 should read
<new language>" so we can tell what it's actually supposed to say?
20:36:54 <Kevin_Kofler> +1 to continuing discussion
20:36:54 <Oxf13> but this is a bodhi RFE, not a policy issue.
20:36:56 <cwickert> +1 for amendment b
20:36:57 <notting> +1 to watching skvidal and mjg59 debate whether it's a
discussion or an arugment
20:36:58 <pjones> patches in english suck.
20:37:12 <cwickert> +1 for continuing the discussion
20:37:27 <nirik> mjg59: ok, we could just vote on the section as amended if you
prefer.
20:37:30 <pjones> +1 to more mass confusion
20:37:42 <notting> so, while i proposed section 3, and think it's a good idea, i
am concerned about the large number of packages that seem to be unable to find testers
now
20:37:47 <nirik> +1 to section 3 as amended by Kevin_Kofler's amendment B
20:38:08 <Oxf13> notting: A) testing timeout. B) Engineering Services ?
20:38:18 <nirik> notting: so, the 1 week timeout helps them?
20:38:21 <mjg59> Ok, I'm +1 to section 3 as amended
20:38:26 <adamw> notting: maybe reduce the time requirement? it would be nice to
look at how long it usually takes before anyone files a -1 on a package, when people *do*
file -1s
20:38:29 <ajax> ES doesn't really seem like QA for hire.
20:38:40 <adamw> if it never takes a week, then waiting a week is sort of
unnecessary
20:38:45 <pjones> I think we need to actively recruit testers for individual
packages if and when they're having trouble getting testers.
20:38:47 <dgilmore> FTR 2 weeks in testing works fine for EPEL
20:38:55 <skvidal> pjones: agreed there
20:38:58 <Oxf13> ajax: *shrug* I thought ES is what we make of it? (not really a
discussion for here/now though)
20:39:00 * nirik things we could get FES to make tools to get more testers
20:39:25 <nirik> well, it takes a while for a package to get out there...
20:39:38 <nirik> pushed one day, mirrored, someone has to update or install it,
etc.
20:39:40 <Kevin_Kofler> dgilmore: 2 weeks is too long.
20:39:43 <notting> nirik: sure, but given the loud complaints from maintainers, i
wonder whether it can be categorized as "one week is too long" or "any time
is too long"
20:39:46 <Kevin_Kofler> 1 week is the maximum tolerable.
20:40:02 <notting> jwb: Oxf13: non-testing updates currently go out daily-ish,
or...?
20:40:02 <Jeff_S> Ramereth: /win 24
20:40:06 <nirik> notting: we could setup a poll? :)
20:40:08 * Jeff_S hides
20:40:12 <Oxf13> notting: weekdayish
20:40:23 <adamw> I usually get -testing pushes around 12 hours after I see the mail
hit the list, fwiw.
20:40:24 <Kevin_Kofler> Even 1 week is an annoyance.
20:40:35 <Kevin_Kofler> But 2 is just too frigging long.
20:41:13 <pjones> notting: so you're wondering if people will simply always
complain?
20:41:21 <nirik> its a balancing act for sure...
20:41:28 <nirik> we can always adjust things.
20:41:35 <notting> pjones: i would like to both ensure we don't push broken
things, while still honor their concerns where possible
20:41:41 <dgilmore> notting: 2 weeks is really not that long and i think is the
amount of time we should mandate
20:41:51 <notting> i wonder if this should be considered in light of the board's
update mandate
20:41:56 <pjones> so what we've really got isn't just a number for how much
positive testing has happened, but also a confidence interval (which is unfortunately
unmeasured)
20:42:02 <dgilmore> positive karma can always shorten it
20:42:08 <pjones> the question is, at a mere 5 days, how high can that confidence
interval actually be?
20:42:20 <notting> pjones: 7 calendar, five-ish business
20:42:24 <nirik> yeah, if you want something faster, make it +1 and get one friend
to vote on it (or currently, just the maintainer? )
20:42:27 <pjones> notting: question still remains.
20:42:36 <wwoods> I think it's worth considering the idea that nothing gets
tested mostly because we don't require any testing
20:42:44 <Oxf13> wwoods: +1
20:42:52 <Kevin_Kofler> dgilmore: Most packages will never get positive karma,
unless somebody gets nagged for it, which won't be the way to get real testing.
20:42:56 <pjones> anyway, I'm +1 on section 3 as amended
20:42:57 <wwoods> and that our ability to test stuff quickly - especially vitally
important things - will change *rapidly* once it's actually required
20:43:08 <notting> wwoods: hm.
20:43:12 <ajax> +1 to section 3 plus amendment B.
20:43:13 <wwoods> people want new bits. If you tell them "you don't get new
bits unless someone tests this package" someone's gonna test that package.
20:43:16 <nirik> we are at 4 +1's
20:43:17 <drago01> wwoods: might be true for "important" stuff but not for
every package
20:43:27 <pjones> wwoods: that's what we're banking on really, yes.
20:43:29 <notting> can/should we amend these proposals with the notion that they
will only apply to future releases?
20:43:42 <pjones> wwoods: though that rapid change may have to be facilitated by
more action
20:43:46 <dgilmore> where is the amendment?
20:43:49 <nirik> notting: I think that may cause a lot of problems.
20:43:50 <mjg59> nirik: I think we're at more than +4
20:43:52 <Oxf13> drago01: I bet we'll see a lot more email posts with "can
somebody quickly test this and give it karma"
20:43:56 <wwoods> drago01: I believe the current proposal only has hard requirements
on the critpath (i.e. important) stuff?
20:43:57 <ajax> dgilmore: https://fedorahosted.org/fesco/ticket/351#comment:12 , for
the third time.
20:44:09 <adamw> wwoods: well, we could certainly get people to sign on with getting
the new bits from -testing. at that point, though, they have the bits. actually filing
votes on the bits doesn't get them anything extra.
20:44:15 <dgilmore> ajax: this discussion is almost impossible to follow
20:44:23 <mjg59> I see notting, me, pjones, nirik, ajax
20:44:23 <pjones> notting: I don't think that's necessary since it really
only makes hard requirements for critical path
20:44:39 <notting> mjg59: technically, i haven't +1'd this proposal yet
20:44:43 <mjg59> notting: Oh, sorry!
20:44:50 <notting> pjones: ... how so? part #3 applies to all other non-critpath
updates
20:44:54 <dgilmore> section 3 as written by notting ill give a +1 to
20:44:54 <mjg59> That's why I was asking whether we were voting on the amendment
or the amended proposal
20:44:58 <drago01> Oxf13: yeah but the "go hunt for testers" route
isn't really a solution but well ...
20:45:03 <nirik> notting: ie, if we set this for f13 only, we will get a lot of
newer NVR packages in older releases... and confuse maintainers.
20:45:06 <dgilmore> any of those amendments I cant accept
20:45:14 <Kevin_Kofler> What's wrong with amendment B?
20:45:21 <nirik> mjg59: yeah, thats since I said we were voting on the amendment +
proposal.
20:45:25 <pjones> notting: well, in that we have not decided the specified amount of
time...
20:45:33 <Kevin_Kofler> Why would we not allow a non-critical package to go out on
the same rule a critical one can go out under?
20:45:55 <drago01> wwoods: I have no idea ... there are like ten proposals floating
around
20:46:20 <notting> pjones: but the only amount of time to require that is compatible
with current practice is zero
20:46:20 <nirik> current proposal:
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from
https://fedorahosted.org/fesco/ticket/351#comment:12
20:46:39 <pjones> notting: which is basically what we get until we decide on a time,
AFAICS
20:47:00 <nirik> if we have no timeout, there will be little used packages that
never get out of updates-testing.
20:47:23 * Oxf13 is curious what the meeting is waiting for
20:47:33 <Oxf13> there have been +5 votes on this
20:47:35 <nirik> at least one more +1 on the current proposal
20:47:38 <mjg59> Oxf13: Who?
20:47:53 <Oxf13> <mjg59> I see notting, me, pjones, nirik, ajax
20:48:02 <notting> Oxf13: i have not voted yet
20:48:02 <mjg59> notting confused me
20:48:04 <nirik> Oxf13: notting has not voted.
20:48:09 <Oxf13> oh, sorry, my bad.
20:48:24 <skvidal> Oxf13: wait - you voted?
20:48:27 * cwickert is hafing a hard time to follow. once "amendment" means
nottings proposal, once it means Kevin_Kofler's suggestions
20:48:41 * Oxf13 notes that having it as a week now, and seeing where it goes, and can be
adjusted later, isn't a bad way to do things.
20:48:47 <nirik> current proposal: Section 3 from
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from
https://fedorahosted.org/fesco/ticket/351#comment:12
20:48:50 <Oxf13> skvidal: I didn't vote, I copy/pasted mjg59's statement.
20:48:52 <adamw> cwickert: it's notting's proposal as amended by KK's
Amendment B
20:48:54 <Kevin_Kofler> notting was +1 to just the amendment, but not to the
combination of his own policy and the amendment?!
20:48:56 <dgilmore> -1
20:48:56 <drago01> skvidal: he copied mjg59's message ... so the "me"
= mjg59
20:48:58 <skvidal> Oxf13: ah - I misunderstood
20:49:13 <notting> Kevin_Kofler: i was +1 to having the policy we consider be the
amended policy
20:49:20 <notting> darned lack of context
20:49:22 <nirik> dgilmore: what are you reasons?
20:49:56 <mjg59> skvidal: Do you have an opinion?
20:49:59 <cwickert> nirik, +1 then, I thought we had already voted about this
20:50:06 <skvidal> at the moment I'm trying to piece together what I'd be
voting FOR
20:50:18 <skvidal> i looked away to #yum for a few minutes and I've lost the
thread
20:50:18 <cwickert> I though we were at section 3 of Kevin_Kofler's additions
20:50:26 <nirik> current proposal: Section 3 from
https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from
https://fedorahosted.org/fesco/ticket/351#comment:12
20:50:37 <mjg59> skvidal: Section 3 of notting's proposal, as amended by
Kevin's amendment B
20:50:39 <skvidal> okay
20:50:41 <nirik> skvidal: understandable.
20:50:42 <skvidal> so here's my take
20:51:10 <skvidal> kevin being in favor of this section with an amendment makes me
think he sees a loophole in it and is going to try and play silly buggers
20:51:13 <dgilmore> nirik: i dont feel that the ammedndment gives anything more.
and is just added noise
20:51:14 * nirik notes another 15min are up. ;)
20:51:36 <Kevin_Kofler> Are we not at +5 already? mjg59, pjones, nirik, ajax,
cwickert
20:51:37 <nirik> +1 to keep powering on. There's a light at the end of the
tunnel.. I hope it's not a train.
20:51:39 <skvidal> so In general I'm -1 to the section with the amendment but
I'm +1 to the section w/o the amendment
20:51:56 <mjg59> Ok, we're at +5
20:51:56 <Kevin_Kofler> skvidal: I'm not really in favor of either variant.
20:52:00 <notting> i just updated the wiki with the amendment included, basically.
20:52:13 <mjg59> HEALTH CARE FOR ALL
20:52:23 <notting> mjg59: +1 to that. oh wait.
20:52:27 <nirik> #agreed Section 3 + KevinK's Amendemnt B passes
20:52:37 <nirik> ok, so there are lots of implementation details here.
20:52:54 <notting> can we note that none of this is going live without work that is
still to be done to bodhi, autoqa, etc?
20:52:57 <mjg59> I propose that we deal with those implementation details out of
band
20:53:07 <nirik> notting: yeah.
20:53:11 <ajax> notting: quite.
20:53:14 <mjg59> Since it's going to involve working with the maintainers of
everything involved
20:53:23 <pjones> yes.
20:53:26 <dgilmore> mjg59: why, we are the body that iis tasked with working out
the implementation
20:53:28 <nirik> #info None of this will take effect until implementation is made
and announced and ready.
20:53:30 <mjg59> And then come back to it at a meeting once we have those hammered
out?
20:53:46 <mjg59> dgilmore: Because we're constrained by the fact that the actual
implementation of this involves volunteers who we have no direct control over
20:54:07 <mjg59> And certain issues may be constrained by implementation issues
20:54:09 <nirik> I think asking rel-eng/qa/infrastructure what it would take to
implement and having them get back to us might be good.
20:54:21 <nirik> and we can decide further questions based on that...
20:54:27 <nirik> like if we need another important packages group
20:54:41 <nirik> or if maintainers can vote on their own updates
20:54:43 <nirik> or whatever.
20:54:51 <dgilmore> mjg59: we should work out how we want it implemented ask that it
be done. if its not possible those doing the implementation should report back and list
what is possible
20:55:05 <notting> ok, so i'll write this up. where in the wiki namespace does
this go?
20:55:27 <nirik> notting: under fesco policies I guess. Make sure it has a ! not yet
implemented.
20:55:32 <pjones> dgilmore: that's a horrible way to write software.
20:55:39 <nirik> dgilmore: so should we task some subset of us to write a spec?
20:55:48 <dgilmore> nirik: no
20:55:52 <dgilmore> we should write the spec
20:55:57 <dgilmore> and ask it be implemented
20:56:21 <nirik> well, we have 5 minutes left in our meeting slot... how do we go
about this?
20:56:28 <Oxf13> I thought the spec was just passed
20:56:40 <Oxf13> and now it's up to the software owners of the things which need
to be modified to work from that spec and make it possible.
20:56:58 <mjg59> And where the spec contradicts reality, we discuss the issue
further
20:57:03 <nirik> or come back and tell us that it's not or won't work
20:58:18 <ajax> nirik: i think we wait a week before moving any further.
20:58:18 <nirik> we should at least see who we have to ask here. bodhi will need
lots of things... rel-eng scripts need any changes?
20:58:39 <ajax> in which time we'll probably think of a list of things that need
addressing.
20:58:41 <nirik> ajax: for the flames to burn?
20:58:50 <ajax> well, that too.
20:59:01 * Kevin_Kofler rings the 1 minute until the end of the 2 hours bell. :-)
20:59:04 <nirik> ok, we can revisit next week and work on what we need to do.
20:59:05 <ajax> i was trying to be a little more utopian
20:59:07 <nirik> #topic Open Floor
20:59:08 <pjones> I'd like to propose that we table any more discussion today
just because.
20:59:11 <Oxf13> all of this also needs autoqa to get in place, so....
20:59:12 <nirik> anything for open floor?
20:59:15 * gholms prepares the fireworks
20:59:40 <notting> i had a ticket i filed today with meeting tag, but it was
probably too late
21:00:01 <skvidal> quick item
21:00:01 <gholms> Quick question:
21:00:03 <ajax> nirik: is it possible to get the meeting bot to give +v to the
chairs?
21:00:03 <nirik> yeah, saw that, but the agenda was already pretty full.
21:00:13 <skvidal> when do we start the discussion for elections, etc? at the
release?
21:00:16 <ajax> nirik: would make it a little easier to visually identify who's
who.
21:00:28 <nirik> ajax: I don't think so, but I could do that as part of the
startup process.
21:00:40 <pjones> that's a good idea.
21:00:53 <pjones> it also means we could change the mode on the channel when
discussion gets too confusing.
21:00:57 <nirik> ajax: I will note it for next time.
21:01:10 <nirik> skvidal: https://fedoraproject.org/wiki/FESCo_election_policy
21:01:21 <gholms> Quick question: If we end up getting working EC2 images up by
release time should that make it into the release notes or features, or should such an
announcement wait until F14?
21:01:29 <nirik> #info FESCo members will be voiced starting next meeting to help
avoid confusion.
21:01:41 <skvidal> ok
21:02:22 <Oxf13> gholms: well, we're well past the feature freeze, so if you
wanted it as a feature, you'd have to get an exception
21:02:41 <notting> gholms: if we get working images, i don't see why they
can't be in the relnotes
21:02:58 <nirik> skvidal: I'm not sure who runs that process... but yeah, we
might see about making sure it's dates are met, etc.
21:03:01 <gholms> Ok, that answers that question.
21:03:24 <nirik> I think inode0 ran things last time.
21:03:40 <gholms> If the meeting bot is going to voice people it'll need ops in
every channel it regulates.
21:04:09 <nirik> gholms: the bot can't do that itself. It would need to be me or
something.
21:04:17 <nirik> anything else? will close the meeting in a few.
21:04:40 <nirik> thanks for coming everyone!
21:04:45 <nirik> #endmeeting
5176
days inactive
5177
days old
8 comments
5 participants
participants (5)
-
Bill Nottingham -
Jesse Keating -
Kevin Fenzi -
Kevin Kofler -
Thomas Janssen