17:00:20 <mmaslano> #startmeeting FESCO (2012-03-26)
17:00:20 <zodbot> Meeting started Mon Mar 26 17:00:20 2012 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:25 * notting is here
17:00:28 <mmaslano> #meetingname fesco
17:00:28 <zodbot> The meeting name has been set to 'fesco'
17:00:34 <mmaslano> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:00:34 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:00:37 * limburgher here
17:00:39 <mmaslano> #topic init process
17:00:41 <mitr> Hello
17:00:41 * nirik is here.
17:00:53 <adamw> girigir!
17:01:32 <mmaslano> 5 members here
17:02:15 <pjones> hello.
17:02:37 <t8m> hello
17:02:48 <pjones> I gotta go for about 5 minutes though.  brb.
17:02:50 <mjg59> Hi
17:03:35 <mmaslano> we have quorum, let's start with followups
17:03:44 <mmaslano> #topic #699 Proposal to remove the package "tzdata" from Critical Path
17:03:48 <mmaslano> .fesco 699
17:04:00 <zodbot> mmaslano: #699 (Proposal to remove the package "tzdata" from Critical Path) – FESCo - https://fedorahosted.org/fesco/ticket/699
17:04:12 <mmaslano> what should be done here?
17:04:23 <mmaslano> I guess we came to some conclusion in previous weeks?
17:04:40 <notting> yeah, this was rejected last week
17:04:47 <notting> 19:23:43 <limburgher> #agreed Proposal to remove the package "tzdata" from Critical Path is rejected (+2,-:0,0:6)
17:04:54 <mmaslano> great, it's fast
17:04:57 <limburgher> I think we pulled it from critpath, but didn't want to exempt.
17:05:04 <limburgher> And I forgot to close the trac.
17:05:21 <mmaslano> ok, I'll mark it after meeting
17:05:31 <limburgher> Thanks. <facepalm>
17:05:47 <mmaslano> #action mmaslano will close 699 with proposal from previous week
17:06:09 <mmaslano> #830 F18 Feature: ARM as Primary Arch --https://fedoraproject.org/wiki/Features/FedoraARM
17:06:28 <mmaslano> #topic #830 F18 Feature: ARM as Primary Arch --https://fedoraproject.org/wiki/Features/FedoraARM
17:06:43 <mmaslano> .fesco 830
17:06:44 <zodbot> mmaslano: #830 (F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM) – FESCo - https://fedorahosted.org/fesco/ticket/830
17:06:44 <sgallagh> Sorry I'm late
17:06:49 <limburgher> This was mildly contentious. :)
17:07:06 <nirik> I think we are still in 'collecting data' phase...
17:07:35 <limburgher> Right. I think we've got two questions, one, what should the promotion criteria be, two, does arm meet them?
17:07:42 * nirik nods.
17:07:47 <limburgher> Would it be helpful to split to two tickets?
17:07:52 <mmaslano> I'm fine with discusion, but we could sum up known problems
17:07:52 <notting> #2 is obviously "no", and will not be "yes" any time soon
17:08:14 <nirik> given the lack of a #1, I suppose so.
17:08:31 <limburgher> I think #1 will give the ARM team a roadmap for #2.
17:08:32 <mitr> I'm not sure we can successfully fix a set of criteria (so that we promise acceptance if they are fulfulled)
17:08:37 <mmaslano> limburgher: +1
17:08:53 <mmaslano> we can discuss it again after some criteria are met
17:09:02 <limburgher> mitr:  What about a set of general targets but reserving FESCO discretion?
17:09:10 <nirik> so, as we have done in the past, perhaps we should empower a subset of us to draft a wiki page/proposal on this for us to start from...
17:09:17 <mitr> Anyway, what _are_ the controviersies?
17:09:19 <mitr> The only one that was very prominent was build time - and that's just unknown.
17:09:30 <mitr> Interestingly, just about nobody complained about having to port/bug fix software for the platform.
17:09:37 <mitr> IIRC
17:09:44 <limburgher> And there's nothing really stopping an improvement of the ARM buildsystem prior to PA.
17:09:49 <t8m> I think the proposal of criteria that was sent to the mailing list by mjg59 is a good start
17:09:50 <sgallagh> mitr: I did
17:09:55 <mitr> sgallagh: sorry
17:09:59 <limburgher> mitr:  I'm actually looking fwd to it.
17:10:06 <sgallagh> mitr: I made repeated comments about the lack of hardware availability for such fixes
17:10:07 <nirik> limburgher: in fact such is planned... but since the hardware doesn't exist yet it's hard to say how well it will do.
17:10:17 <mmaslano> list of all build failures even arm is here http://ausil.fedorapeople.org/f17-failures.html
17:10:23 <mmaslano> it's not so terribly long
17:10:25 <limburgher> nirik: Pffft. Oh, that. :)
17:10:28 <t8m> mitr, I'd actually like to not have x86 monoculture as PA
17:10:33 <mitr> t8m: same here
17:10:39 <limburgher> t8m: ditto.
17:10:40 <t8m> mitr, however the build time issue is serious
17:10:56 <bconoboy> most of the ARM failures in F17 are due to circular dependencies.  we're working through them.
17:11:34 <t8m> mitr, not for my package but I suppose things like gcc, glibc, kernel, and even libreoffice and other big desktop packages are the critical thing
17:11:43 <t8m> the build time must be reasonable for them
17:11:56 <pjones> okay, so we really don't need to discuss the current state of arm much here
17:12:06 <mitr> Returning to the original ticket/proposal, it starts with strongly integrating the ARM secondary arch infrastructure even without it being declared PA.  Are we OK with that?  On the surface it seems reasonable, but I haven't noticed much feedback from infrastructure or rel-eng about this part.
17:12:06 <notting> is build time anything that can be reasonably discussed until the new build system is available?
17:12:09 <bconoboy> sgallagh: re hardware-availability, anybody with an x86 host can start a qemu session and have an arm host.
17:12:13 <limburgher> <brainstorming>  What if we had something where ARM was nearly PA, was on SCM, koji, wtc, but builds/releases were decoupled?  This would fix x86 security patch speed worries.
17:12:32 <limburgher> mitr:  I'd love that.
17:12:44 <jonmasters> notting: we have predictions around build time. I agree it will be good when we have the actual hardware in place
17:12:54 <mmaslano> limburgher: if it's possible on koji, then why not
17:12:58 <notting> limburgher: builds/releases being decoupled essentially *is* seconday
17:12:58 <nirik> mitr: which parts of it?
17:13:00 <mitr> limburgher: https://fedoraproject.org/wiki/Features/FedoraARM#Scope steps 1-4 :)
17:13:01 * nirik goes to look again.
17:13:07 <mitr> nirik: ^^
17:13:09 * jonmasters is ok with progressively getting closer. There seems no problem with us moving the build system to Phoenix even as a secondary, etc.
17:13:17 <dgilmore> limburgher: not possible
17:13:31 <notting> we've had secondary builders in phx before. *shrug*
17:13:32 <bconoboy> limburgher: A transition plan involving nearly-PA is necessary part of the journey.  I don't believe we can run both builds on the same koji server, though
17:13:49 <limburgher> dgilmore: What's the blocker?
17:13:57 <dgilmore> we have ppc builders in phx today
17:14:01 <limburgher> bconoboy: server meaning hub or builder?
17:14:05 <nirik> mitr: infrastructure has no issues with that. We already have s390 and ppc secondary arch machines in our datacenter (on a seperate network). Adding arm there should be fine.
17:14:20 <jonmasters> anyway, I think we all support the idea that we need a set of marching orders/requirements. If you guys can get us a concrete set - using mjg's post as a starting point for example - we will meet whatever you ask us to within reason
17:14:27 <notting> nirik: we have a s390???
17:14:27 <dgilmore> limburgher: koji would need a major rewrite to support something like that
17:14:28 <bconoboy> limburgher: hub- builders are fine
17:14:40 <nirik> notting: the koji hub is in phx2 (it's a x86 box tho)
17:14:45 <limburgher> dilgmore:  That's was I was wondering.  Dang. :(
17:15:08 <t8m> the question is whether sharing the koji hub is really necessary
17:15:11 <dgilmore> limburgher: it flies in the face of how koji was designed to work
17:15:28 <notting> what does sharing the koji hub allow that is needed here?
17:15:28 <bconoboy> t8m: it's necessary for PA
17:15:32 <dgilmore> t8m: for it to be primary it is
17:15:44 <nirik> jonmasters: I think we need a general 'how does something promote to primary' roadmap... I think we need to work on that outside this meeting with interested parties.
17:15:45 <t8m> bconoboy, sure, but not for the transitional phase
17:15:47 <jonmasters> we'll have faster build hardware in the next 3-6 months. Further out, we get 8+ core 64-bit systems over the next couple years that will remove any concerns around performance of builds, and before then it gets gradually faster. There will be a point where we meet whatever you need
17:15:55 <jonmasters> nirik: exactly agree with you
17:16:03 <pjones> limburgher: there's a very real way in that the defining characteristic of a secondary arch is /not/ sharing koji with primary.
17:16:13 <pjones> limburgher: in fact that's exactly why we *created* secondaries.
17:16:16 <bconoboy> t8m: right- putting it on the same hub is in a sense the end of the transition because at that point koji will treat ARM failures like x86 failures and vice-versa
17:16:27 <t8m> bconoboy, yeah
17:16:38 * jonmasters thought this meeting was at 2pm EDT, I guess it's actually pinned to UTC and the adjust yesterday moved it. Good to know.
17:16:57 <limburgher> jonmasters: We'll actually be considering that.
17:17:00 <mjg59> So from my perspective the expectation is that ARM should be identical to a primary architecture with the exception of the koji instance and whether or not ARM bugs are considered release blockers
17:17:25 <limburgher> pjones, dgilmore:  So essentially we need to see how close we can get to PA without crossing that line.
17:17:29 <pjones> mjg59: you mean that as the requirement for promotion?
17:17:33 <pjones> limburgher: exactly
17:17:34 <jonmasters> mjg59: well, we're not going to be "identical". We're more like an appliance model for installation for example
17:17:35 <nirik> mjg59: you mean to keep being a secondary arch?
17:17:38 <sgallagh> mjg59: Isn't that basically the definition of Secondary Arch?
17:17:39 <mjg59> And the transition from secondary to primary would simply be cutting over to the main koji and then paying attention to it for the release QA
17:17:39 <dgilmore> mjg59: well as things are today secondary arch blockers are primary arch NTH
17:17:56 <mjg59> pjones: Yes, pretty much
17:18:35 <mjg59> jonmasters: There's obviously going to be specific hardware differentiations - I don't think we're going to be demanding anaconda on hardware that only supports one piece of media at a time, for instance
17:18:39 <pjones> limburgher: when we think they're identical except for those things, and we think the build time issue is mostly solved, we flip the switch to move them to main koji and call them primary, and tell everybody that they should be treating them that way as well
17:19:13 <mjg59> nirik: I think secondary architectures should be at the level of quality of a primary architecture /before/ we promote, yes
17:19:24 <dgilmore> mjg59: there is one thing that we would need to decide on as a implementation detail, and that si is the cutover importing the secondary arch binaries, and moving forward. or is it adding the secondary arch binaries as an external repo and doing a mass rebuild to pick up the secondary arch
17:19:35 <limburgher> pjones: It sounds like we're more or less expressing our SA/PA criteria. :)
17:19:47 <bconoboy> mjg59: that's something of a moving target, don't you think?
17:19:47 <mjg59> dgilmore: Would rel-eng have a recommendation?
17:19:52 <pjones> jonmasters: I expect long term the "appliance model for installation" will be true of some machines but not others; I don't think anybody's going to find that distinction to be unpalatable.
17:20:03 <pjones> bconoboy: being a primary is always a moving target.
17:20:06 <mjg59> bconoboy: To the extent that our quality is inconsistent between releases, sure
17:20:11 <jonmasters> mjg59: well good. What you posted last week was the first time I've seen an attempt at FESCo defining promotion requirements. So we achieved one of our objectives, which is to get this debated. If you guys will collectively define what you need, we can make counter-proposals, and offer input
17:20:12 <dgilmore> mjg59: both have pros and cons
17:20:22 <nirik> I guess the detail here is what 'identical' means.
17:20:23 <dgilmore> mjg59: we would need to take a outage of koji to do the import
17:20:38 <mitr> pjones: Given that we are fine with Live CDs, I think the non-anaconda path is actually quite feasible.
17:20:51 * jonmasters proposes strongly that FESCo form a sub-team to define formal promotion requirements
17:21:01 <limburgher> jonmasters: +1
17:21:05 <pjones> mitr: I don't forsee making anaconda work /on suitable machines/ to be in any way difficult.  it's a non-issue.
17:21:06 <dgilmore> mjg59: but to setup the external repo and do a mass rebuild would mean no outage, but would mean we have the time of the mass rebuild
17:21:08 <limburgher> And write it up for discussion.
17:21:14 <mjg59> jonmasters: I think the idea of formal promotion requirements is problematic
17:21:16 <jonmasters> limburgher: yup
17:21:19 * nirik is fine with that (given I suggested it a while ago :)
17:21:25 <nirik> mjg59: why?
17:21:26 <mjg59> jonmasters: I don't think we want to commit to "You tick these boxes, you must be promoted":
17:21:28 <sgallagh> jonmasters: I further propose that it should be a joint venture with FPC
17:21:29 <limburgher> mjg59: How so?
17:21:30 <mitr> pjones: right
17:21:37 <jonmasters> mjg59: if we don't have a formal list, there's nothing to stop you guys from coming back later and say "but you didn't..." :)
17:21:44 <limburgher> sgallagh: Reasonable.
17:21:47 <sgallagh> mjg59: I think it's "you tick these boxes and FESCo makes a final decision"
17:21:47 <notting> sgallagh: how so? not sure how FPC plays in here. packaging standards should be identical
17:21:51 <nirik> it could well be a 'if you pass these things we will consider your promotion'
17:21:52 <mjg59> jonmasters: Yes, and your job is to make sure that we have no reason to do that
17:21:54 <tibbs> Not really sure what FPC would be able to do here.
17:22:08 <limburgher> mjg59, jonmasters:  We need to include that FESCO makes the ultimate call.
17:22:10 <mjg59> jonmasters: If fesco starts making unreasonable demands then we're already screwed
17:22:19 <mjg59> And I'd expect the board to step in
17:22:22 <dgilmore> sgallagh: why does the FPC need to be involved
17:22:23 <pjones> sgallagh: which brings the argument to being perfectly circular: if there's really a meaningful set of checkboxes, why would we need to make the final decision?
17:22:24 <jonmasters> mjg59: our job cannot be nebulously undefined without a set of reasonable criteria or we'll still be debating PA in 2 years from now when 64-bit ARM servers have taken over.
17:22:25 <sgallagh> nirik: Maybe I misunderstood, but I thought there were substantial differences between ARM chips that we would need to account for
17:22:28 <sgallagh> Or is that only for the Kernel?
17:22:43 <nirik> sgallagh: not sure what you mean... in packaging?
17:23:00 <mjg59> jonmasters: We can write as long a list of requirements as you want. Fesco could still refuse.
17:23:01 <jonmasters> sgallagh: only for the kernel. Userspace, e.g. on v7 is surprisingly bland
17:23:07 <sgallagh> nirik: Given the number of puzzled responses I'm getting, I clearly misunderstood. Carry on.
17:23:12 <dgilmore> sgallagh: the packaging guidelines today cover arm apckaging just fine
17:23:13 <jonmasters> sgallagh: we even do unaligned memory these days ;)
17:23:20 <notting> pjones: we're in uncharted territory (requirements for promoting a secondary arch). even if it becomes a checkbox procedure, someone's gotta define that
17:23:31 <bconoboy> sgallagh: 99.5+% of packages are just recompile and ready to go, there's no special-arm consideration necessary.
17:23:39 <jonmasters> mjg59: fine, but don't you think a reasonable starting set of criteria gives us more than "go away and think about it some more"?
17:23:41 <sgallagh> jonmasters: Yeah, memory alignment makes me nervous. But that's somehow no longer an issue?
17:23:43 <pjones> notting: right, but I don't think for a second we're going to get the checkbox list right the first time
17:24:01 <mjg59> jonmasters: I do, and if I didn't I wouldn't have posted what I did
17:24:02 <pjones> notting: so better to give them guidance instead and re-evaluate when we think we're closer
17:24:02 <nirik> thats not a reason not to try and refine... ;)
17:24:19 <notting> pjones: sure, but guidance can be a list too. "chief among these requirements is..."
17:24:26 <mjg59> jonmasters: I just want to make it clear that this shouldn't be an exercise in automatic promotion if you meet a specific set of requirements
17:24:28 <t8m> but why not define check box list with the last checkbox meaning 'Fesco approved the promotion of this SA to PA'
17:24:29 <limburgher> nirik: +1
17:24:29 <pjones> sgallagh: it's transmutated to a performance issue AIUI
17:24:33 <jonmasters> mjg59: right. We debated writing such a list, but we wanted FESCo to do so. Your post is a great starting point, but it's not official.
17:24:36 <pjones> notting: sure
17:24:49 <jonmasters> mjg59: I'm totally ok with the idea that we don't get a rubber stamp
17:25:00 <jonmasters> mjg59: but give us a list of things you want that we can discuss officially
17:25:16 <sgallagh> pjones: So glibc (or similar) does it under the hood with a performance hit? Interesting
17:25:18 <mjg59> jonmasters: The way this stuff generally works is that we post something to a mailing list and then see whether anyone disagrees
17:25:25 <mjg59> Ok, so how about this:
17:25:47 <t8m> I think we should approve the mjg59 list possibly with some ammendments like adding the last checkbox
17:25:50 <mjg59> Proposal: Adopt the list of criteria I posted to fedora-devel as a base level of requirements for a secondary arch to meet before promotion can be considered
17:25:52 <notting> proposal: a FESCo subcommitee comes up with a necessary-but-not-sufficient set of criteria that helps define primary arch readiness. meanwhile, the ARM team endeavors to make their F17 release "as primary-like as possible"
17:25:53 <jonmasters> sgallagh: no, the hardware does unaligned access on v7. On v5 you take an exception and handle it
17:25:59 <nirik> mjg59: link to post?
17:26:01 <mitr> jonmasters: Considering that several of the things brought up in the proposal are things FESCo wouldn't probably think of independently, I think the conversation is going uite well, and there is unlikely to be major surprises form FESCo.
17:26:02 <pjones> sgallagh: kernel traps the faults and fixes them up is how some architectures do it; I haven't investigated arm thoroughly but I'm sure you can as bconoboy outside of this discussion.
17:26:19 <nirik> notting: +1
17:26:22 <notting> mjg59: i'd prefer you and pjones coalesce your lists somehow
17:26:26 <t8m> notting, +1
17:26:34 <pjones> mjg59: sure, we can do that this afternoon.  should take about 5 minutes.
17:26:41 * jonmasters would like us to have some time to discuss mjg's criteria before it's rubber stamped. Could you agree to work on this and whatever that thread concludes you'll vote on as a starting set?
17:26:47 <mjg59> nirik: http://lists.fedoraproject.org/pipermail/devel/2012-March/164276.html
17:26:49 <nirik> perhaps a wiki page off of https://fedoraproject.org/wiki/Architectures with a draft on it?
17:26:57 <pjones> jonmasters: what did you think the last week was?
17:27:00 <bconoboy> I'd like to see a definition of 'primary-like' if that's used in a proposal
17:27:27 <jonmasters> pjones: a mailing list thread without the explicit label of "this is going to be what FESCo require".
17:27:27 * mmaslano says 20 minutes on topic
17:27:36 <mitr> Can we +1 notting's proposal without signing up for the subcommittee? :)
17:27:39 <bconoboy> (again, more checkboxes, so we can definitively evaluate our primary-likeness)
17:27:52 <jonmasters> bconoboy: +1
17:27:59 <mjg59> Given that we're 9 people, I have no idea what a subcommittee would look like
17:28:10 <dgilmore> mjg59: 3 or 4?
17:28:26 <mjg59> For now I'd suggest that people just continue discussing it on the list, and we can revisit next week to see if there's any significant changes people want?
17:28:30 * nirik would be happy to help draft. sounds like pjones offered to start things.
17:28:52 <pjones> nirik: Well, I was more expressing that our lists aren't terrible different
17:28:56 <t8m> mjg59, could you make a wiki page with the proposal?
17:29:00 <mitr> Re mjg59's list, I think 3) is too strict (see conversation above), 5) should be perhaps limited to the toolchain (
17:29:01 <pjones> but sure, I can help draft language.
17:29:07 <mjg59> t8m: Can do, but I'd really prefer the discussion to happen on-list
17:29:14 <mmaslano> sure
17:29:14 <mjg59> t8m: wikis are a dreadful place to discuss
17:29:21 <t8m> sure
17:29:31 <mmaslano> but we need some summary of facts
17:29:36 <mjg59> How about I push it to the wiki at the end of the week?
17:29:36 <nirik> sure we can discuss on list, as long as we end up approving something and putting it in a nicer place.
17:29:39 <limburgher> mmaslano:+1
17:29:51 <nirik> 200+ post threads are not easy to find things in.
17:30:08 <mmaslano> but some facts are repeated over and over
17:30:09 * jonmasters would like to see this ultimately go to a wiki entry of requirements to summarize the thread
17:30:16 <bconoboy> nirik: anything us completely-objective arm-pushers can do to help? :-)
17:30:21 <notting> i'd be fine with a discussion on the list too
17:30:34 <notting> mini-proposal: retitle ticket as "define requirements for secondary arch promotion"
17:30:38 <nirik> lets try and hash out a draft however we can and discuss next week?
17:30:40 <jonmasters> bconoboy: got your rubber stamp handy? I've got mine here
17:30:42 <mmaslano> notting: +1
17:30:45 <sgallagh> notting: +1
17:30:46 <pjones> notting: strong +1
17:30:48 <mjg59> notting: +1
17:30:53 <mitr> +1
17:30:58 <notting> as i think 'make ARM a primary arch' is not under discussion rightnow
17:31:00 <jonmasters> cool, thanks guys
17:31:24 <t8m> notting, +1
17:31:29 <jonmasters> (btw, hi Jon and Jake...we look forward to the writeup in LWN, it'll save us doing one)
17:31:36 <nirik> :)
17:31:45 <mmaslano> I see +6
17:31:57 * nirik is for that too... +1
17:32:03 <mmaslano> #action mmaslano will rename ticket to "define requirements for secondary arch promotion"
17:32:17 <limburgher> +1
17:33:15 <mitr> jonmasters: BTW, it seems you were unhappy with mjg59's proposed list - feel free to object directly if you think the proposed requirements don't make sense.
17:33:41 <mmaslano> another proposal: mjg59 will prepare wiki at the end of a week with list of requirements from devel list
17:33:48 <notting> mmaslano: +1
17:33:52 <jonmasters> I will reply with some additional thoughts, yea
17:34:00 <bconoboy> jonmasters: likewise
17:34:09 <jonmasters> bconoboy: do not bait the trolls :P
17:34:22 <bconoboy> jonmasters: who, me?
17:34:26 <jonmasters> :)
17:35:01 <t8m> mmaslano, +1
17:35:14 <mmaslano> mjg59: do you want to rephrase it or is it ok?
17:35:26 <mjg59> mmaslano: I think that's fine
17:35:33 * nirik is +1 to that too... although I think we should vote on any drafts as a whole before we approve them.
17:35:34 <mmaslano> +1 for my proposal
17:36:05 <mjg59> +1
17:36:15 <mitr> +1, echoing nirik's caveat
17:36:22 <limburgher> +1
17:36:31 <mjg59> Yeah, I'll make sure it's labelled draft
17:36:36 <pjones> +1
17:37:10 <mmaslano> #agreed mjg59 will prepare wiki at the end of a wek with list of requirements from devel list (+8,-0)
17:37:11 <sgallagh> +1
17:37:36 <mmaslano> #agreed mjg59 will prepare wiki at the end of a wek with list of requirements from devel list (+9,-0)
17:37:53 <mmaslano> what else do you want to discuss about arm?
17:38:00 <mmaslano> postpone for next week?
17:38:20 <pjones> well, next week's discussion appears as though it won't be about arm ;)
17:38:22 * nirik nods. Revisit the primary promotion stuff next week
17:38:58 <mmaslano> let's go to new business
17:39:04 <sgallagh> mmaslano: +1
17:39:20 <mmaslano> #topic #829 New sponsor request: Pavel Alexeev (hubbitus)
17:39:28 <mmaslano> .fesco 829
17:39:29 <zodbot> mmaslano: #829 (New sponsor request: Pavel Alexeev (hubbitus)) – FESCo - https://fedorahosted.org/fesco/ticket/829
17:39:46 <notting> so, this was +1 -2 on the sponsors list
17:40:24 <tibbs> BTW, from context I suspect he really just wanted provenpackager.
17:40:47 <nirik> well, "There are some packagers, who submit some interesting software titles to Fedora, but they still not sponsored yet. I believe, that I can help them too."
17:40:53 <limburgher> tibbs: That's what I got from this also.  I'm -1 on sponsor.
17:40:56 <mmaslano> nirik: yes
17:41:21 <limburgher> Does he understand the difference?
17:41:22 <mmaslano> I'm not on sponsors list, so I can't say
17:41:23 <sgallagh> As a general rule, I vote -1 on contentious sponsorships.
17:41:24 * nirik is a weak -1... and would suggest as a alternative to just add as co-maintainer on ImageMagick stuff.
17:42:03 <limburgher> nirik:  He maintains ImageMagick.  this is to fix API/ABI breakage.
17:42:18 <nirik> yes, I mean the dependent packages he wants to rebuild.
17:42:28 <limburgher> nirik:  I *just* figured that out. :)
17:42:53 <notting> reasons for -1 included language/communication barriers
17:43:16 <t8m> I gave +1 and I still think it would be ok if he would be a sponsor so +1
17:44:36 * drago01 thinks that telling him "-1 on sponsor list so no" without telling him the reasons for the -1 is odd
17:44:47 <drago01> unless he has been cced to those mails
17:45:51 <limburgher> I don't think he has.
17:45:51 <notting> drago01: in prior times, sponsors objected to making their feedback directly attributable to them
17:46:10 <mitr> Yeah, it sort of makes the additional step of FESCo discussion meaningless, if it is just an automatic confirmation of the previous step
17:46:23 <drago01> notting: a summary without "foo said x and baz said y" would be fine
17:46:34 <mmaslano> -1 I believe sponsor should know procesess like adding more components into bodhi. I would be ok with provenpackager probably, because he's working on different packages
17:46:35 <notting> mitr: we've overruled -1s on the list before
17:46:38 <tibbs> FESCo has allowed sponsor status over on-list objections before.
17:46:45 <tibbs> Pretty recently, I recall.
17:46:47 <limburgher> drag01: +1
17:46:54 <nirik> the sponsors list feedback is advisory only.
17:47:10 <pjones> the language barrier is my biggest objection; he seems to want to actually do sponsor work as well as the provenpackager stuff (which would be a separate discussion)
17:47:19 <limburgher> It should certainly inform out decision, but we can go either way.
17:47:29 <tibbs> Lack of any standards for who gets provenpackager/sponsor continues to be an issue, I think.
17:47:30 <limburgher> pjones: And should be.
17:47:32 <drago01> notting: I don't no him so I am not arguing for +/- but my point is "tell him why"
17:47:36 <drago01> *know
17:47:46 <mmaslano> -5/+2
17:48:19 <pjones> I think I'm vaguely +1
17:48:24 <mmaslano> it would be nice if sponsors could add into ticket why he was refused
17:48:26 <limburgher> drag01:  For sure, he should have an idea of what to do to be +1 next time he asks.
17:48:48 <mjg59> Can I just mention again that being asked to form an opinion when we can't read the sponsors list is really really awkward?
17:48:52 <mmaslano> he was refused twice and didn't know what he should improve
17:49:08 <notting> mjg59: let's discuss that in open floor?
17:49:14 <mjg59> notting: Sure
17:49:20 <mmaslano> -5/+3
17:49:32 <mjg59> I'm also vaguely +1
17:49:40 <mjg59> Which I think is everyone
17:49:44 <notting> -5 means it can't pass, right?
17:49:51 <pjones> yep
17:49:53 <mitr> I'd be +1 to provenpackager, -1 to sponsor right now... but do we want to open that discussion?
17:50:02 <t8m> mmaslano, I think you have the count wrong - it's -5/+2 only
17:50:20 <t8m> So what would be the summary of objections?
17:50:20 <limburgher> mitr: I think it'd be better to say -1, here's why, if you meant PP file another ticket.
17:50:35 <mmaslano> t8m: yes, right
17:50:47 <mitr> limburgher: works for me as well
17:51:06 <tibbs> Oh, this is also the five-space tabs guy.
17:51:16 <pjones> t8m: huh?  right now I count me, you, mjg59.
17:51:26 <pjones> tibbs: that's weird, but we're all weird.
17:51:54 <tibbs> You miss the point that he wants to mess with other people's spec files.
17:51:56 <t8m> pjones, that was at the time when mjg59 not voted yet
17:52:18 <pjones> tibbs: that's pp not sponsor, and no, I don't miss that point.
17:52:33 <tibbs> sponsor implies provenpackager, you know.
17:52:40 <pjones> sigh, yes.
17:53:07 <pjones> but you're failing to differentiate between wanting to help out, which we need more of, and wanting to change things for the sake of change.
17:53:20 <tibbs> Untrue.
17:53:21 <t8m> and he wants to help with sponsoring people who are waiting on the to-be-sponsored queue with new packages
17:53:29 <mitr> tibbs: "The guy" means... what?  Personal preference, or tendency to apply it to other's packages?
17:53:33 <t8m> so he clearly declared that he wants to be a sponsor
17:54:10 <tibbs> Anyway, you folks will do what you like.
17:55:05 <mmaslano> #proposal reject the sponsor status because of language barrier and what sponsors didn't like?
17:55:39 <t8m> mmaslano, I think the sponsor status was already rejected by the votes
17:55:49 <pjones> yeah, I don't think we need another proposal here.
17:55:54 <limburgher> Agreed.
17:55:54 <t8m> mmaslano, we just need a summary of the objections
17:56:15 <mmaslano> t8m: and I'm asking what should I write
17:56:46 <t8m> The objections were: Language barrier and?
17:56:56 <limburgher> Experience, IIRC.
17:56:59 <notting> t8m: unspecified due to -enotime
17:57:12 <nirik> more detailed reviews.
17:57:17 <nirik> more experence.
17:57:28 <pjones> mostly capricious.
17:57:32 <nirik> improve communication in bugzilla.
17:58:16 <nirik> we could ask those people who did vote no to add areas to improve to the ticket?
17:58:21 <mmaslano> ok
17:58:47 <mmaslano> #agreed hubbitus was rejected as a sponsor (-6,+2)
17:59:08 <mmaslano> I'll sum it up in the ticket
17:59:12 <mmaslano> #topic Next week's chair
17:59:37 <sgallagh> I will be on a plane during next week's meeting.
17:59:54 <mitr> I haven't chaired in a while, i can do that.
18:00:02 <pjones> mmaslano: pretty sure it was +3
18:00:27 <mmaslano> pjones: I go through log again... There was too many +1 on different topics
18:00:40 <mmaslano> #agreed mitr will be chairman next week
18:00:44 <t8m> mmaslano, it was +3
18:00:45 <pjones> it was me, t8m, and mjg59.
18:00:49 <t8m> yes
18:00:57 <mmaslano> ok, I'll fix it
18:01:10 <mmaslano> #topic Time change
18:01:31 <pjones> definitely +1 to completely banning the time change from now perpetually.
18:01:40 <pjones> everywhere.
18:01:47 <nirik> pjones: +1
18:01:54 <mmaslano> I'm almost content with current time 17UTC, which means 19CEST for three of us
18:01:54 <t8m> pjones, you mean banning DST? :D
18:01:55 <sgallagh> pjones: So lock onto UTC forever?
18:02:10 <pjones> sgallagh: I'm not against time zones
18:02:21 <sgallagh> pjones: I think your proposal was unclear, then
18:02:37 <pjones> sgallagh: nobody else seemed to have any trouble.
18:02:59 <mitr> sgallagh: I think it was locked to 18UTC.
18:03:23 <pjones> anyway, so as not to derail with a joke, the actual question is whether to move the meeting, yes?
18:03:33 <sgallagh> Not a helpful answer. Did you mean that the current time should apply for all future FESCo meetings of this electorate. Of all electorates? And should DST be a factor at any point?
18:03:38 <notting> i'm fine with this week's time
18:03:49 <limburgher> notting: metoo
18:03:59 <t8m> notting, +1
18:04:02 <sgallagh> This week's time worked fine for me
18:04:04 <nirik> proposal: leave at 17UTC for now and ever. (ie, if local time changes, we still meet at 17UTC)
18:04:10 <t8m> nirik, -1
18:04:13 <mitr> Overall, it doesn't matter whether it is UTC or E[SD]T, because they are the same most of the year.
18:04:30 <sgallagh> nirik: -1
18:04:31 <mitr> We can always special-case the 4 weeks.
18:04:36 <pjones> mitr: right.  it's just 3-4 weeks a year that it's an issue
18:04:53 <mitr> AFAICS the real proposal here is 18UTC -> 17UTC
18:05:01 <t8m> but if the meeting time is defined in UTC it must change on every DST change
18:05:06 <t8m> mitr, yeah
18:05:26 <mitr> t8m: And if it is in CEST, it will change for the US on every DST change, ...
18:05:38 <mitr> and then back again
18:05:38 <pjones> t8m: but making it in any local time has the same problem, just to the other half of us
18:06:15 * mitr just realized he is being extraordinarily stupid and he'll shut up
18:06:22 <sgallagh> Proposal: We decide the meeting before US DST starts or ends which time we're going to meet thereafter
18:06:28 <pjones> Proposal: since whether this works or not always depends on who's actually on fesco at the time, let's just continue to handle this on an ad-hoc basis.  It makes no sense for us to discuss meeting times for a future, separate group of people.
18:06:39 <t8m> pjones, +1
18:06:50 <mmaslano> #proposal move the meeting time back to 17UTC
18:06:53 <sgallagh> pjones: I think that's a clearer way of saying what I just said, so +1
18:06:56 <t8m> mmaslano, +1
18:07:00 <nirik> t8m: would 18UTC forever work for you better?
18:07:00 <nirik> ok, counter proposal?
18:07:00 <nirik> I'd prefer sticking to one UTC time... whatever that might be.
18:07:14 <notting> 17UTC works much better for me
18:07:29 <mmaslano> I'm for my proposal +1
18:07:31 <t8m> nirik, the problem is not the 17 UTC but the "for now and ever" part
18:07:50 <nirik> sure, ok.
18:07:50 <nirik> +1
18:07:51 <notting> +1 to mmaslano
18:07:55 <pjones> right, and deciding forever when we know the next fesco is just going to set their own meeting time anyway is... absurd.
18:07:58 <limburgher> +1
18:08:02 <mitr> +0 - I don't care one way or the other
18:08:06 <nirik> ok, fine, lets deal with it moving forward then.
18:08:46 <t8m> I count +5 at least for changing to 17UTC
18:08:57 * mmaslano is not sure anymore
18:09:04 <nirik> I just find it easier to know if we move for dst or not... since we always have to waste time discussing. If we said 'we don't' it would be easier... but I don't care that much.
18:09:09 <mjg59> Has Europe changed time yet?
18:09:14 <mmaslano> yes
18:09:25 <mjg59> Did today's time cause anyone problems?
18:09:45 <sgallagh> mjg59: Only because I didn't read the note that we moved it back in time :)
18:09:53 <mjg59> Yeah
18:09:54 <sgallagh> (which is why I was late)
18:09:59 <mjg59> So I'm +1 to 17UTC
18:10:04 <sgallagh> As am I
18:10:14 <sgallagh> (+1 to 17 UTC, for clarity)
18:10:17 <pjones> wait, so that's... noon EST5EDT going forward?
18:10:33 <mmaslano> +7 for 17UTC
18:10:47 <t8m> pjones, 1pm
18:10:48 <sgallagh> pjones: That's 1EDT
18:10:56 <Southern_Gentlem> 1300
18:10:57 <pjones> that's fine, +1 to that on a one-off basis.
18:10:58 <notting> pjones: 17UTC seems more clear than any other represntation
18:11:29 <notting> and it will stay there until we decide to move it again. *shrug*
18:11:31 <pjones> notting: all representations are unclear until I type the right date command ;)
18:12:21 <mmaslano> #agreed meeting time 17UTC, 19CEST, 13EST (+7,0)
18:12:27 <pjones> nirik: the problem with saying "we move for dst" is that "dst" doesn't specify /one/ change, it specifies many different but /eventually/ equivalent changes.
18:12:38 <mmaslano> #topic Open floor
18:12:46 <notting> so, back to PP
18:12:55 <notting> #topic provenpackager/sponsor approval process
18:13:09 <notting> mjg59: you want to be able to see sponsor's feedback?
18:13:25 <notting> we can make sponsors enter feedback in the ticket itself?
18:13:33 <pjones> mmaslano: 13EDT fwiw ;)
18:13:57 <nirik> notting: we could. In the past tho some people wanted to provide anonymous feedback...
18:14:03 <mmaslano> pjones: you have strange time zones, I'm glad that I know New York is in EST
18:14:11 <mmaslano> I hope
18:14:27 <mjg59> notting: Yes
18:14:46 <t8m> mmaslano, S in EST is for Standard, S in CEST is for Summer
18:14:50 <mmaslano> notting: I'd like to see summary in ticket. Why sponsors rejected someone. I don't need acess into list
18:14:50 <pjones> mmaslano: it's in EST5EDT, which just happens to be EDT right now.  It's confusing to everybody.  *everybody*
18:14:54 <notting> nirik: what value is gained by anonymous feedback
18:15:11 <pjones> notting: it's feedback that we don't know we can't trust!
18:15:25 <t8m> didn't we discuss it a few months ago?
18:15:31 <pjones> yes
18:15:50 <t8m> notting, it is not anonymous it is just secret
18:15:55 <nirik> well, someone might not want to hurt feelings of the submittor, etc... also, some submitters may not want full feedback searchable by employers/etc down the road.
18:16:23 <pjones> nirik: I've written code I may not want them to see either ;)
18:16:47 * nirik doesn't know if he feels too strongly on it.
18:16:54 <mmaslano> yes, but we are saying why we rejected him/her
18:17:11 <mitr> pjones: code is not that personal (for most people)
18:17:51 <notting> mmaslano: right - restricting it means we either are forced to paraphrase ourselves (ick) or just not tell people. neither is good
18:18:51 <notting> proposal: move sponsor feedback on sponsor/provenpackager requests to tickets, not mail alias
18:19:01 <limburgher> +1
18:19:10 <mmaslano> notting: +1
18:19:23 <drago01> nirik: the feedback can be send in private mail ... invisible to employers etc.
18:19:25 <t8m> I do not care +0
18:19:35 <nirik> we could give it a try and adjust if it doesn't work. It may be difficult to get some people do to that tho... given we mail them asking for feedback and they are used to just replying to that.
18:19:45 <nirik> drago01: thats the way it is now.
18:20:10 <mitr> slightly -1
18:20:22 <drago01> nirik: I got the impression that it is just "sponsors said no, fesco said no"
18:20:37 <drago01> nirik: without telling the person why he was rejected
18:20:46 <drago01> nirik: which is just wrong
18:21:05 <mjg59> notting: +1
18:21:25 <nirik> drago01: you mean mail them as well privately with feedback?
18:21:33 <drago01> nirik: yes
18:21:57 <nirik> well, not sure how logistically to do that... we could cc them, but people could drop them from cc.
18:22:01 <drago01> nirik: this also helps them to work on the deficites for a second attempt
18:22:22 <nirik> also, it means they will likely reply and open up a discussion that mails all sponsors.
18:23:02 <drago01> well as said before you can have the discussion in private summarize it and just send the facts to them
18:23:09 * nirik is a slight +1 to asking for feedback in ticket. If it doesn't work out or offends, we can adjust
18:23:18 <mitr> notting: Would asking to preferably give feedback in ticket, or to reply to sender (who would anonymously repost) work?
18:23:40 <notting> mitr: the point of asking for feedback is to find out objections that can be referred to fesco for arbitration (like today)
18:23:42 <nirik> drago01: it's very hard to distill
18:23:48 <drago01> nirik: and if the feedback is like "foo is a moron" that is not valid anyway
18:23:48 <notting> responding to sender doesn't help with that
18:24:37 <mitr> notting: "sender" being you in most cases :)
18:24:55 <notting> sorry, thought you meant requestor
18:24:59 <mitr> notting: I don't think FESCo has used the identity of the person who gave feedback in the arbitration discussion
18:25:27 <notting> i did once, and got complained at
18:26:31 <nirik> so, where are we here?
18:27:03 <mmaslano> does anyone have new proposal?
18:27:05 <notting> +4
18:27:09 <nirik> I think we got +5 on nottings?
18:27:23 <notting> oh, yeah, saw nirik. i guess that's +5
18:28:15 <pjones> +1
18:28:15 <mmaslano> #agreed on move sponsor feedback on sponsor/provenpackager requests to tickets, not mail alias (+5,-1)
18:28:24 <notting> i'll send mail to the sponsors list
18:28:34 <mmaslano> #agreed on move sponsor feedback on sponsor/provenpackager requests to tickets, not mail alias (+6,-1)
18:29:01 <mmaslano> #topic Open floor
18:29:55 <mmaslano> I'll close meeting in 2 minutes
18:30:43 <drago01> well I have something but not sure it is fesco's call ...
18:30:54 <pjones> may as well ask
18:31:14 <drago01> can / should we enforce autoqa's dep check for updates (i.e not just being informative but block/unpush) ?
18:31:33 <notting> what's the false positive rate?
18:31:42 <nirik> are the qa folks comfortable with doing that?
18:31:47 <sgallagh> drago01: Well, one problem with that is that sometimes packages get karma-pushed for an older release before the newer one
18:32:01 <tflink> interesting, that came up on autoqa-devel on Friday
18:32:13 <pjones> sgallagh: which we want to discourage anyway
18:32:15 <drago01> adamw told me that it might produce false positives
18:32:15 <nirik> tflink: any conclusion?
18:32:20 <drago01> not sure about the rate though
18:32:23 <sgallagh> pjones: I disagree
18:32:38 <adamw> tflink: i think it came up because drago01 asked me about it :)
18:32:43 <pjones> sgallagh: how odd.
18:32:47 <sgallagh> If an F16 security update gets karma-acked, and F17 has to wait 3 days for a manual push
18:33:06 <tflink> nirik: we're not sure that it's time to do that - AFAIK, bodhi doesn't support it and we have little support for things like manually re-running tests and overriding fails
18:33:24 <adamw> well, i'd put it a little differently
18:33:26 <mmaslano> #proposal discuss it next week, because everything update related take hours
18:33:26 <sgallagh> I'd much rather that the F16 security update gets out there as fast as possible
18:33:45 <adamw> tflink: to me, those are the things that *constitute* 'enforcing autoqa tests'.
18:33:46 <mitr> sgallagh: It might be more important to not reintroduce a security vulnerability for users who thought that they have fixed it by upgrading, than to fix it quickly - I don't know.
18:33:59 <sgallagh> mitr: NVR would fail to upgrade
18:34:08 <sgallagh> the NVR on F17 would be lower than that of F16
18:34:08 <adamw> tflink: when we say we want to enforce autoqa tests that pretty much means 'let's build the appropriate mechanisms in bodhi and whatever'.
18:34:12 <tflink> adamw: true. the other part is that our logs aren't incredibly user friendly
18:34:13 <sgallagh> Unless they're distro-syncing I guess
18:34:33 <drago01> sgallagh: you are talking about a different issues
18:34:33 <mitr> sgallagh: right...
18:34:44 * nirik would prefer to have bodhi work in bodhi2.0 at this point.
18:34:46 <tflink> notting: we don't have any hard data on the number of false negatives
18:34:54 <lmacken> nirik: yes, me too :)
18:35:01 <drago01> sgallagh: my questions was more about in the same release ... i.e "yum update" should not explode with broken deps
18:35:02 <tflink> nirik: no argument from us, either
18:35:10 <drago01> we should catch that beforehand
18:35:17 <drago01> we have the tool to do that
18:35:23 <sgallagh> drago01: Ah that
18:35:24 <drago01> we are just not using it (yet)
18:35:35 <sgallagh> I've had an ignored ticket open in Bodhi about that for quite some time
18:35:50 <adamw> sgallagh: right, it's worth clarifying here that there are multiple autoqa tests, and we don't have to 'enforce' them all at once.
18:35:55 <adamw> sgallagh: the one you're concerned about is upgradepath
18:35:58 <adamw> but there is also depcheck
18:36:09 <sgallagh> Sorry for the confusion. We'll table upgradepath for now
18:36:18 <adamw> it could well be the case that we're ready to enforce depcheck before we enforce upgradepath.
18:36:32 <mmaslano> adamw: drago01: wouldn't be better to sum it up into ticket with some stats?
18:36:36 <sgallagh> As far as depcheck, part of the problem is that sometimes bodhi updates depend on other bodhi updates
18:36:49 <sgallagh> And there's no way (currently) to hold one pending a push of another
18:37:06 <sgallagh> The workaround so far has been for a provenpackager to combine the two updates into a single one
18:37:11 <adamw> mmaslano: yeah, i think tflink and I agreed that we'd want to have a definite implementation roadmap, some solid status on current accuracy of the test, and a way to generate ongoing stats on accuracy post-deployment in case of controversies.
18:37:23 <sgallagh> But that has other issues too, as it can sometimes cause an update to get rushed through (see the Xulrunner/moz-nss debacle)
18:37:28 <adamw> sgallagh: that's not a workaround, really. that's how updates should be done.
18:37:37 <sgallagh> adamw: No, it's not.
18:38:00 <sgallagh> adamw: In the example I mentioned, it caused a seriously-regressed mozilla-nss package to land in production that broke dozens of other packages
18:38:01 <adamw> well, not to open a nest of worms, but i'd say by policy any single update should be internally dependency-consistent.
18:38:06 <adamw> any other process is just too prone to failure.
18:38:16 <sgallagh> Because it was in teh same update as a Firefox update that instantly got karma-pushed
18:38:52 <adamw> so, obviously a case for improving the update feedback process (which involves a lot from the bodhi 2.0 pile too). but i don't think it's a valid reason for submitting incomplete updates
18:39:10 <sgallagh> adamw: And what of packages that depend on other packages?
18:39:20 <adamw> ...i am aware of this phenomenon. we call them 'packages'.
18:39:28 <limburgher> They're the happiest packages of all.
18:39:33 <sgallagh> Should they just have to wait to submit updates and get testing until a dependency lands in stable?
18:39:45 <adamw> erm, that's not what i'm saying.
18:39:55 <tflink> sgallagh: that seems a bit extreme
18:40:04 <adamw> in the case of X, Y and Z all depending on A, and A getting an ABI bump, an update should be submitted which contains A, X, Y and Z.
18:40:26 <sgallagh> tflink: Which is why I'm saying that it should be possible for them to both be in updates-testing, but the lower links on the chain should be held back for pushing until the upper links are also ready for it
18:40:28 <adamw> buildroot override can be used to build X, Y and Z before submitting the update.
18:40:43 <sgallagh> adamw: That works in ABI bumps, sure.
18:40:47 <adamw> sgallagh: buildroot override is the appropriate mechanism, not putting the depended-on package in updates-testing first.
18:41:02 <sgallagh> How about: New version of Transifex requires Django 1.4
18:41:06 <tflink> sgallagh: I wonder about taking that a step farther and not allowing stuff into updates-testing until all deps are resolvable
18:41:15 <sgallagh> adamw: Building is one thing. Releasing is another
18:41:27 <sgallagh> tflink: But they can be resolvable within updates-testing
18:41:39 <sgallagh> but shouldn't get pushed to stable if they would have unmet deps in stable
18:41:43 <adamw> sgallagh: then...you do a build of django 1.4, put it in buildroot override, then build transifex and any other deps of django 1.4, and submit them all as one update.
18:41:45 <tflink> sgallagh: sure, as long as everything is resolvable within the current repo
18:41:58 <tflink> or the repo that they are pending push to
18:42:03 <sgallagh> adamw: Then you have bigger problems
18:42:04 <adamw> i'm not seeing why you think it's ever necessary to push one thing to updates-testing in order to build other things against it. i'm not saying you're wrong, just that i don't quite understand your example yet.
18:42:17 <sgallagh> adamw: I never said "build"
18:42:21 <sgallagh> I said "depends on"
18:42:25 <sgallagh> Runtime deps, not build-time
18:42:39 <adamw> i still don't see how that changes much.
18:42:41 * nirik wonders if this is a fesco discussion anymore... perhaps have it in devel and revisit the question?
18:42:47 <adamw> nirik: reasonable
18:42:48 <pjones> nirik: +1
18:42:51 <sgallagh> adamw: It changes everything
18:42:52 <adamw> i think we're well into that nest of worms
18:42:58 <adamw> sorry for derailing
18:42:58 <sgallagh> nirik: -1, I'd like to try and clarify my position
18:43:23 <nirik> ok...
18:43:27 <adamw> sgallagh: we can do it in another channel?
18:43:41 <sgallagh> adamw: Consider that Firefox 15.0.1 has a dependency on a new feature in mozilla-nss
18:43:41 <nirik> this seems like implementation details of autoqa tho... ?
18:43:52 <sgallagh> nirik: No, I think it needs to be a decision about bodhi behavior
18:44:02 <sgallagh> When can something be pushed to stable
18:44:11 <tflink> nirik: autoqa/bodhi
18:44:20 <adamw> i'd agree there, this isn't an autoqa design issue as i understand it, we're talking updates policy.
18:44:24 <sgallagh> adamw: By your logic, you would have a provenpackager put the two packages into a single update.
18:44:37 <adamw> not necessarily a proven packager. but sure.
18:44:45 <drago01> nirik: yeah makes sense
18:44:46 <sgallagh> adamw: However, there are literally hundreds of packages besides Firefox that depend on mozilla-nss
18:45:09 <sgallagh> Let's say that three or four of those also decide to update to support the new feature.
18:45:18 <sgallagh> Do we now also have to have a PP pull those into the same update?
18:45:37 <sgallagh> Now we're testing too many high-level programs in the same bodhi update.
18:45:41 <mitr> Can we not have discussions involving complex dependency graphs and several stages of changes on IRC, please?  E-mail, wiki, anthing else that is possible to follow and reason about?
18:46:06 <sgallagh> This could easily lead to some of them being pushed because karma got high enough, even though the package had never been tested at all
18:46:46 <adamw> sgallagh: but if you separate them out, then whichever package is 'popular' will get pushed without mozilla-nss being pushed. which is worse.
18:46:59 <adamw> because then you have a broken package which is, by definition, a very popular one.
18:47:03 <sgallagh> adamw: And now you're beginning to see the problem I'm trying to solve :)
18:47:33 <adamw> sgallagh: i accept your contention that the 'all in one update' scenario has problems especially under the current bodhi setup.
18:47:33 <drago01> sgallagh: disable auto karma push for them; done
18:47:42 <pjones> so your example here is abi-breaking security updates?
18:47:47 <t8m> mitr, +1
18:47:51 <adamw> but i reject the suggestion that having each package in a separate update makes anything better.
18:47:55 <sgallagh> I think that the proper way for this to behave is for mozilla-nss to be a separate bodhi update, and for all those packages that depend on it to have a bodhi-level dependency.
18:47:59 <nirik> so perhaps bodhi sees when you submit the update that it depends on a override, offers to add it to existing override update?
18:48:13 <sgallagh> i.e. if you click "push" they won't actually get signed and pushed until the dep tree in stable would be correct
18:48:22 <adamw> sgallagh: unfortunately, right now there is no such thing as a 'bodhi level dependency', so you're arguing in anticipation of your tools...
18:48:27 <mitr> sgallagh: I think the proper way to handle the NSS breakage is to improve the test suite, but that's probably taboo here :)
18:48:38 <sgallagh> mitr: It's a single example
18:48:51 <mitr> sgallagh: doesn't change the right answer :)
18:48:53 <sgallagh> I've seen the same thing bite FreeIPA in the ass many times, because it has a lot of dependencies
18:49:04 <sgallagh> 389, krb5, python, etc.
18:49:10 <adamw> sgallagh: it's a nice idea and it seems definitely superior to either of the current options.
18:49:11 <mitr> Anyway, _please_ let's discuss this somewhere else than on 80-column instant messaging.
18:49:31 <mmaslano> sorry guys
18:49:31 <adamw> sgallagh: but given the tools currently available, all in one update is the less broken approach.
18:49:43 <sgallagh> adamw: Well, I filed that as a proposal for Bodhi months ago
18:49:44 <pjones> I still think it's a strawman
18:49:45 <mmaslano> adamw: could you or someone from QA write a proposal?
18:49:49 <adamw> sgallagh: we could always update the policy now to require dependent packages be in a single update, and then if you manage to implement your plan, update it *again*.
18:49:56 <adamw> mmaslano: i can, yep.
18:49:57 <sgallagh> I'd like to propose that we rule it mandatory and see if that gets it fixed
18:50:01 <mmaslano> adamw: we can discuss here for hours
18:50:03 <pjones> mitr: 80-column?  I get your objection, but the number of columns is your own choosing here ;)
18:50:05 <adamw> mmaslano: it's on my todo list, below everything that makes beta broken. =)
18:50:17 <mmaslano> adamw: sure, so it's wait after beta
18:50:31 <thunderbirdtr> fraggle_,
18:50:31 <mmaslano> sgallagh: or you can bring your counterproposal
18:50:42 <thunderbirdtr> sorry people ...
18:50:43 <sgallagh> mmaslano: https://fedorahosted.org/bodhi/ticket/663
18:50:47 <mitr> pjones: even worse, my fonts are proportional
18:50:51 <adamw> sgallagh: it seems like a better idea to write the tools then adjust the policy to suit, than to write policy which is impossible to implement as written and then demand the tools be changed.
18:50:58 <pjones> sgallagh: wait, you want to make it mandatory to *see* if it gets fixed?
18:51:24 <sgallagh> adamw: Historically, the only time bodhi has ever changed is when we demanded a change to the updates policy
18:51:31 <sgallagh> I don't see it flowing downhill to us
18:51:35 <pjones> also when we've asked lmacken to change it.
18:51:42 <nirik> I think we can ask for changes in 2.0...
18:51:44 <pjones> I think you're completely off-base here
18:51:46 <sgallagh> pjones: That amounts to the same thing
18:51:51 <pjones> it doesn't at all
18:51:55 <nirik> but I think we should have a seperate meeting for that. ;)
18:51:57 * mmaslano bangs 20 minutes on topic gong
18:52:09 <pjones> you're characterizing it as some difficult thing that's been problematic in the past.  it's no such thing.
18:52:18 <sgallagh> I think I've made my point clear. Is anyone still confused about the problem or the proposed solutions?
18:52:43 <sgallagh> pjones: Ok sorry. My tone may have come off wrong there. That was not my intent.
18:52:45 * nirik isn't.
18:52:46 <adamw> nope, as i said, i understand the scenario you suggested and i agree your proposed solution would be a superior approach if it existed.
18:52:49 <pjones> I think your point is 85% fiction, but it's pretty clear, yes.
18:53:02 <pjones> (just making up a nice round number there)
18:53:06 <adamw> i don't agree with you regarding the appropriate way to make it happen, but as pjones said, you made it clear.
18:53:12 <sgallagh> pjones: How is it fiction? I just cited several recent examples
18:53:42 <adamw> sgallagh: he was referring to your theory about how to get changes into bodhi.
18:54:08 <pjones> adamw: also to the idea that the way to fix an abi-breaking change being rolled out in f16 is to make sure everything blocks on it
18:54:24 <sgallagh> pjones: I didn't talk about ABI break at all
18:54:31 <sgallagh> I talked about regressions
18:54:32 <mmaslano> guys I'll close it in 5 minutes no matter what
18:54:37 <pjones> it's completely wrongheaded.  we shouldn't be making that kind of change, and the updates policy discourages it
18:54:38 <mmaslano> it's almost 2 hours
18:54:44 <pjones> sgallagh: but you did.  Why do all those packages need to be rebuilt?
18:54:54 <adamw> pjones: remember, we do enforce bodhi post-beta as well as for stable releases, where it's somewhat more reasonable to do such a change.
18:55:00 <adamw> er, post-alpha, rather.
18:55:03 <pjones> you know what, nevermind.  I agree with mitr, we should have this discussion on the mailing list instead of here.
18:55:11 <sgallagh> pjones: Because of a new feature they want to take advantage of
18:55:40 <sgallagh> And also the problem is that sometimes a popular superpackage can force the broken update of a dependency (see Firefox/NSS, yet again)
18:55:48 <pjones> sgallagh: they don't need rebuilt for api/abi they don't use.  you're talking about a separate thing from needing a rebuild now.
18:55:50 * notting catches up. the problem with turning on depchecking is updates that break their dependent packages w/o breaking RPM dependencies???
18:56:07 <sgallagh> No
18:56:10 * adamw goes to test beta blockers.
18:56:14 <tflink> notting: I don't think that this has to do with depcheck any more
18:56:15 <sgallagh> notting: Not without breaking RPM deps
18:56:23 <drago01> we seem to have moved away from what I am actually asked and opened another can of worms ...
18:56:38 <drago01> tflink: yeah
18:56:46 <adamw> as far as 'enforcing depcheck' goes, i think we broadly agreed on the approach i mentioned above. then i opened a hairy can of worms, for which i continue to apologize...
18:56:48 <sgallagh> notting: There are two closely-related problems.
18:57:21 <sgallagh> One exacerbated by the proposed solution to the other
18:57:49 <sgallagh> But I'm tired of banging my head against this particular wall today.
18:58:24 <notting> ok. proposal: move to list
18:58:37 <limburgher> notting: +1
18:59:00 <mitr> +1
18:59:04 <mmaslano> +1
18:59:39 <pjones> yes, please, +1
18:59:41 * sgallagh shrugs
19:00:00 * nirik nods, +1
19:01:06 <t8m> +1
19:01:24 <mmaslano> #agreed sgallagh will start another discussion about updates on devel list (+6,0)
19:01:34 <mmaslano> #endmeeting