19:30:02 #startmeeting FESCO (2010-08-17) 19:30:02 Meeting started Tue Aug 17 19:30:02 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:02 #meetingname fesco 19:30:02 The meeting name has been set to 'fesco' 19:30:02 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:02 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:03 #topic init process 19:30:20 Afternoon 19:30:43 * nirik waves 19:31:03 * notting is here 19:31:03 run! 19:31:09 * jsmith is here 19:31:12 * mclasen too 19:31:49 SMParrish / kylem / pjones: you guys around? 19:32:51 yo. 19:33:13 ok, I guess lets go ahead and get started in... 19:33:16 #topic #351 Create a policy for updates - status report on implementation 19:33:16 .fesco 351 19:33:20 nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:33:28 so, all of this has landed now I think except for autoqa. 19:33:52 * mclasen has already had bodhi reject some updates because of 'criteria violations' :-) 19:33:52 jlaska: you guys are still hoping to have some autoqa enabled for f14 beta? or am I misremembering? 19:34:52 so, I think we should all be looking for positive and negative feedback on the new setup... see if we need to adjust/modify things down the road. 19:36:02 is it clearly defined what's supposed to happen when an update is edited and the builds are changed? 19:36:08 anyone have anything to add on this? should we keep this ticket open for tracking autoqa? 19:36:29 notting: I don't think it is... we will need to find out from lmacken 19:36:33 notting: I don't think it is 19:36:57 I have been able to edit a critpath update, and then immediately afterwards use the previous karma to push it to stable 19:37:05 that seems... wrong. 19:37:08 personally I would prefer if editing an update to just add/remove bugs, or change notes would just leave it otherwise alone... but if you added/removed builds it should reset karma/timeouts. 19:37:09 which was good for me, but probably not intended... 19:37:26 nirik: I agree with that 19:37:43 nirik: that would be logical. +1 from me for that as a policy 19:37:52 i suspect that will upset more people 19:37:59 nirik, yeah, that sounds sensible on that as a policy. 19:38:00 which will? 19:38:07 resetting karma? 19:38:18 Yeah 19:38:31 well, it's new builds, so it should be retested I would think. 19:38:33 I think it's the right thing 19:38:44 But mailing list discussion suggests that it's not unanimous 19:39:25 mjg59: you always have the alternative to try and get your update enough karma as-is and then file anew one for the new build 19:39:36 mclasen: Right, and I think that's the correct approach 19:39:43 assuming the new build isn't necessary to 'eliminate' negative karma 19:39:44 * pjones is here 19:39:52 in which case the resetting is what you want, anyway 19:40:02 so, a) we need to find out what it currently does, and b) we should document this policy and make it do this? 19:41:08 any other votes on this as a policy? or should we ask for more feedback and revisit next week? 19:41:31 This policy matches my interpretation of the intention 19:42:43 well, I count that as 5... 19:42:58 #agreed editing an update to just add/remove bugs, or change notes would just leave it otherwise alone... but if you added/removed builds it should reset karma/timeouts. 19:43:10 #info need to document and see what current setup is. 19:43:57 so, any further updates thoughts or adjustments in this topic? 19:44:04 or shall we move on to the next related ticket? 19:44:19 next. 19:44:35 #topic #382 Implementing Stable Release Vision 19:44:35 .fesco 382 19:44:36 nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:44:44 anyone make any progress here from last week? 19:45:02 i have some additional docs written but not committed yet, got pulled to rhel nonsense again 19:45:07 sadly no due to vacationing. 19:45:16 i'll post those by the end of the day or be very ashamed. 19:45:20 I talked with QA, and they would prefer we track updates issues and then task them/notify them of things that qa could do to prevent issues from re-occuring. 19:45:55 also, they are going to work on updating the updates_lessons page with more stuff like recomendations and actions taken. 19:46:00 ajax: cool. 19:46:09 #info ajax has docs to commit hopefully today. 19:46:31 #info nirik talked with QA and they want FESCo to track new updates issues and then get feedback from them where needed. 19:46:40 anyone else have anything on this? 19:47:41 ok, we will keep muddling along... 19:47:43 next ? 19:47:44 #topic #448 Disallow packages whose primary owner is group. 19:47:44 .fesco 448 19:47:45 nirik: #448 (Disallow packages whose primary owner is group.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/448 19:47:52 This was discussed last week. 19:48:06 I'd like to revisit and see what people think about merge reviews and provenpackager. 19:48:32 there was some confusion over what we wanted to allow here. 19:49:03 if we don't trust the combination of a pp's expertise and the package owner's change review to catch problems with merge review changes, then who exactly _do_ we think will catch them? 19:49:36 I think the case we want to disallow is: provenpackager reviewer, no response from maintainer, pp just commits. Or do we wish to allow that as well? 19:49:44 i wish to allow that. 19:49:52 nirik: I want to allow that, for sure. 19:50:03 otherwise, what's the point of having pp's _at all_ 19:50:17 well, no one is reviewing their changes... pp make mistakes too. 19:50:33 maintainer will get the email 19:50:34 most of the changes that go in our packages don't get a '4 eyes' review... 19:50:35 but sure, they should be able to make the changes sanely. 19:50:35 sure, but that could be true of the normal maintainer case as well. 19:50:47 we can't stop mistakes from happening 100% through review, and that's not really the goal 19:51:36 in the beginning another goal of merge reviews was to teach owners of those packages about the guidelines... but I suppose if they don't understand now, there's not much hope. 19:51:55 I don't really think that was a very realistic goal. 19:52:00 nirik: as the owner of more than one of the open merge reviews... 19:52:05 as in, the package owner. 19:52:12 I think we'll be in a much better position to ever get merge reviews done if we frame them more as 'here's a patch, ok to commit' then 'hey, overworked maintainer, here's a bunch of changes I am going to force you to make' 19:52:22 i understand the guidelines, and it's pretty clear to me that some of them just don't matter as much as others. 19:52:39 mclasen: agreed. 19:52:41 proposal: provenpackagers can commit changes to allow merge reviews to progress/be closed, as a courtesy they should post the diff to the merge review and wait a short time for maintainer to ack/commit it. 19:52:50 mclasen: sure. 19:52:54 nirik: ack I _guess_ 19:53:00 so i tend to ignore the boring changes 19:53:15 well, feel free to propose something else? ;) 19:53:49 nirik: sounds good to me 19:54:01 +1 to nirik's proposal 19:54:09 sure, i'm convinced. +1 19:54:10 I guess I'm +1 to that 19:54:10 nirik, +1. 19:54:37 +1 19:54:41 #agreed provenpackagers can commit changes to allow merge reviews to progress/be closed, as a courtesy they should post the diff to the merge review and wait a short time for maintainer to ack/commit it. 19:54:51 ok, will update the bug and the wiki after the meeting. 19:55:02 #topic #370 allow bundling libiberty 19:55:03 .fesco 370 19:55:04 nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370 19:55:06 ajax: news here? 19:55:25 so, in F13, there are 22 bundlers of libiberty 19:55:38 2 down from last week :-) 19:55:49 that was a miscount on my part, CVS/ isn't a package 19:56:07 among them there are anywhere from 1 to 13 copies of any given file 19:56:23 s/copies/versions/ 19:56:29 summarized here: http://fpaste.org/cZKT/raw/ 19:57:02 of those, 11 files have potentially significant ABI or functionality differences 19:57:12 the worst offender by far being the c++ demangler 19:57:35 (files with a * are these significant ones) 19:57:48 ajax, yeah that's what i would have figured. :\ 19:58:19 pretty scary, but we suspected it could be. 19:58:19 given that this is a copylib, i'm going to go out on a limb and assume that if the file exists in a package it's because the package needs it to build 19:58:36 i'll note here that literally _every_ copy of cp-demangle.c is unique 19:58:46 (9 packages don't include it) 19:59:09 so, asking all of them to converge on one seems pretty pie in the sky. 19:59:25 yeah, that still seems completely unrealistic. 19:59:35 /manual/windows 19:59:47 so, it's the functional equivalent of expecting all libegg users to converge? 20:00:01 notting: kindof worse, but yeah. 20:00:13 this is just not going to happen. 20:00:47 now, the ABI changes aren't necessarily a problem, in the sense that if we only ever install it as a static library, and the dependent package builds and links against the system copy, it'll work. 20:01:00 * mclasen starts to juggle a second meeting, so somewhat distracted from on... 20:01:36 one sec, pasting something else... 20:01:38 we could perhaps allow the bundling, and then add a libiberty package and ask folks to see if they could over time converge to the one implementation. I don't know if that would just lead to fighting over whats in the package tho. 20:02:06 nirik: hard to make that fly with upstreams though, especially with upstream libiberty saying to do it the other way 20:02:14 (otherwise, sounds like a great plan ;) 20:02:40 hm, i seem to have been wrong again. 24 packages. http://fpaste.org/bzct/raw/ 20:02:43 yeah, some will just never be able to use that... but some could. Ie, it could lower it from 22 to fewer. 20:03:06 anyway. note that basically all of these are toolchain packages, one way or another. 20:03:25 and 8 of them are gcc... 20:03:32 things that would probably depend pretty strongly on the version of the c++ demangler they're using. 20:04:13 wait, which of those isn't toolchain? insight? 20:05:00 heh. all i guess. i was heding on gputils and sdcc. 20:05:03 hedging even, 20:05:28 we still ship spu-binutils? 20:05:33 F13. 20:05:41 i have no idea if it's in F14. 20:06:03 anyway, what we'd floated before was "gcc and binutils can bundle but nobody else can" 20:06:11 this seems like a pretty arbitrary restriction now. 20:06:44 yeah, since basically all of it is toolchain 20:06:50 seems to allow 12 of the 24 20:07:18 mclasen: so gcc because... it's the compiler and not say, sdcc? because... it's the compiler? 20:07:45 it seems arbitrary, indeed 20:07:46 an 8051 compiler i have a little trouble considering on equal footing with gcc 20:07:51 but, still. 20:08:05 wow, insight got a release last year. 20:08:16 "some projects are 'copylibs'. They are meant to be bundled and modified by the including project heavily. Fedora should ship a 'reference version' of these packages and upstreams asked if they can use that reference version, if not, the bundling would be allowed on a case by case basis according to how much local modification they have made" 20:08:29 * nirik takes a stab at a rationale. 20:09:01 nirik: that sounds good enough to me, with the caveat that we may as well just auto approve everything already on the list now. 20:09:26 personally my preference is to stick my fingers in my ears and ignore the whole thing. 20:09:34 that being said, that just means we're going to get compat-gcc-45 and it'll be defaulting to violating our rule. 20:09:45 ajax: yeah, I think I'm really leaning towards +1 to that 20:10:01 if you choose not to decide, you still have made a choice. ;) 20:10:15 so, a modified version of nirik's: 20:10:21 I think we should decide that this isn't a real issue and close the ticket ;) 20:10:34 short of someone tilting at the windmill of making an actual libiberty release, i don't suspect we're going to see any change in this, ever. 20:10:56 wait, there's *never* been an actual release? 20:11:00 never once. 20:11:08 notting: no, of course not. 20:11:08 woah. 20:11:15 upstream doesn't believe it's necessary 20:11:18 in fact they believe the opposite 20:11:22 in that case, i'm not sure we should do anything until someone does so. people are free to do that 20:11:43 notting: my theory for a while has been that the only reason this got any attention was that it was named lib-something. 20:11:45 "To date, libiberty is generally not installed on its own. It has evolved over years but does not have its own version number nor release schedule." 20:11:57 ajax: I'm sure that's the case. 20:12:16 if they'd just called it portability/ and copied _that_ into every project, no one would have blinked. 20:12:28 I propose that this isn't a real issue and close the ticket. 20:12:36 i want something stronger 20:12:52 you want us to _declare_ that it isn't an issue? 20:13:13 Proposal: things named libiberty, gnulib, or libegg are not libraries. they are exempt from the library bundling clause, forever. 20:13:20 well, I still think we should decide something... even if it's 'libiberty is ok to bundle anytime" 20:13:35 ajax: okay, fine. 20:13:42 ajax: +1 20:13:46 ajax: +1 20:13:59 does libiberty have an actual use in most programs? is the demangler exposed in better places? 20:14:10 not so much because i approve of the practice, but because i don't want anyone else wasting time on this again. 20:14:10 no, but who needs the demangler? 20:14:31 I would be ok with that if we s/things named/ 20:14:38 ajax: +1 20:14:47 nirik: amendment accepted. 20:14:57 * nirik doesn't want some loophole lawyer saying "oh, but I renamed by lib..." :) 20:15:00 +1. 20:15:03 Taking this to its logical extent: 20:15:05 nirik: fair enough 20:15:08 notting, sadly no. 20:15:11 Macros in #includes shouldn't be allowed 20:15:25 mjg59: wth? 20:15:26 notting, and other paths to the same thing are encumbered by gplv3 in binutils. :/ 20:15:28 Because if someone fixes a bug we need to rebuild everything 20:15:29 mjg59: quit that. 20:15:46 mjg59: they can certainly cause compat pain 20:15:54 so, #agreed libiberty, gnulib, or libegg are not libraries. They are exempt from the library bundling clause. ? 20:16:00 nirik: yes 20:16:01 nirik: yes. 20:16:04 mclasen: Yeah, but I think trying to enforce a policy against them would be... awkward 20:16:08 nirik: +1 20:16:13 s/or/and/ 20:16:17 I agree 20:16:22 mjg59: unrealistic at very best. 20:16:41 So we should just reimplement libiberty as a set of .hs 20:16:50 And some linker magic 20:16:52 * spot is tempted to submit a list of "things bundled in chromium" 20:16:59 any other votes? I'm +1 for this 20:16:59 spot, don't you dar. :P 20:17:14 There's already a chrome bug open for that anyway. ;) 20:17:16 nirik: i count five them (me pjones mjg59 mclasen you) 20:17:23 * notting was +1 20:17:35 #agreed libiberty, gnulib, or libegg are not libraries. They are exempt from the library bundling clause. 20:17:46 nirik: You might want to s/or/and/ 20:17:48 I will see about asking packaging folks to document this. 20:17:55 #undor 20:17:56 #undo 20:17:56 Removing item from minutes: 20:18:02 #agreed libiberty, gnulib, and libegg are not libraries. They are exempt from the library bundling clause. 20:18:07 spot: completely off topic ;) 20:18:21 ok, moving on? or anything else on this? 20:18:27 no, let it die ;) 20:18:29 move on 20:18:31 please nothing else. 20:18:49 #topic #450 provenpackager request - supercyper 20:18:49 .fesco 450 20:18:53 nirik: #450 (provenpackager request - supercyper) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/450 20:19:09 So, this was sent to us due to several -1's from sponsors. 20:20:04 I'd just like to say that this ticket turning into a referendum on specific packaging changes/methods is something we should try to avoid replicating in the future. 20:20:52 well, I think it turned into that due to people trying to note the issues that prevented them from voting +1... but yeah. 20:21:47 so, any votes here? thoughts? 20:22:12 i'm tempted to defer to the sponsors judgement... 20:22:32 zodbot: fasinfo supercyper 20:22:33 ajax: User: supercyper, Name: None, email: supercyper1@gmail.com, Creation: 2009-11-21, IRC Nick: , Timezone: None, Locale: None, Extension: 5140916, GPG key ID: None, Status: active 20:22:36 ajax: Approved Groups: @packager-zh fedorabugs packager cla_fedora cla_done 20:22:49 lord, Name: None is the goofiest thing in the world. 20:22:56 I think I would personally like to say -1 now, but encourage them to keep working with fedora and reapply at some later date. Experence should hopefully smooth over issues and have them ready for provenpackager powers. 20:23:02 ajax: privacy setting 20:23:20 i'm aware, it's just dumb 20:23:30 nirik: I'm leaning that way as wel 20:23:31 l 20:23:58 googling for that email address tells me real name is Chen Lei, which confirmed what i was trying to discover: i don't know who this person is 20:24:00 Yeah, I'd lean towards thinking that someone who's provenpackager should be able to convince sponsors that they're improving 20:24:23 As a guideline rather than a rule 20:24:31 ajax: sure, and I have a similar reservation, but we also need to try to consciously avoid making this a "I know him and therefore he's okay" thing 20:24:42 we've got to assume there will be PPs we've never met/interacted with. 20:24:47 I mean, unless you want to start using kde. 20:24:48 pjones: certainly. 20:25:26 that being said, there appear to be some fairly serious reservations about choices he makes in packages. 20:25:53 yeah, i'm with nirik's reapply suggestion. 20:26:00 * notting is +1 to nirik's reapply suggestion 20:26:17 I guess I'll +1 that as well. 20:26:19 +1 20:26:57 #agreed Request not approved at this time, but please keep working with fedora and reapply at a later date. 20:26:58 i kinda want a %{_bedatadir} and a %{_eldatadir} now though 20:27:18 #topic FES tickets 20:27:21 ajax: and a %{_pdpdatadir} ? 20:27:26 I think mmcgrath is not around currently... 20:27:38 but he got a number of new folks applying from his plea on the devel list the other day. 20:27:46 and got some assigned to tickets. 20:27:47 pjones: i think we'll wait for the linux/pdp port first. 20:28:02 ajax: %{_el}? funny. 20:28:03 If anyone has any items they would want FES to work on, please do file new tickets. 20:28:14 https://fedorahosted.org/fedora-engineering-services/report/6 lists the current bunch 20:28:31 #info a number of new folks applied in the last week. 20:28:53 I expect we will have some progress to report next week... 20:29:02 #topic Open Floor 20:29:08 Anyone have items for open floor? 20:29:49 nirik: Just clarification; what's the rationale to write down in the pakcaging guidelines for libiberty, egg, gnulib? 20:30:11 they're not libraries because _____ . 20:30:23 Because they're not 20:30:26 abadger1999: 1) upstream defines them as copy libraries, not to be shared 2) no actual released versions to standardize on 20:30:28 hehe :-) 20:30:32 abadger1999: I think: "These are not libraries, they are reusable code snippets that will be heavily modified by projects. Also, there is no upstream stable release of this code" 20:31:31 they're a definition of "library" that made sense on ultrix in 1990 but doesn't really fit the definition of what we call libraries now. 20:31:32 Okay. I'll try and work on a guideline update that makes that distinction.... Do you guys think of this more of an and or as an or for those two? 20:31:52 and. 20:31:54 (or, you know, more like on univac in 1951) 20:32:09 Thanks. 20:32:11 yeah, and. 20:32:23 * abadger1999 opens a wiki page to start a draft 20:32:41 Have any folks been following the discussion on the advisory board list about the role's of fesco/board? 20:32:59 * nirik doesn't know that we have any action right now from that, but might be worth adding your input if you like. 20:33:20 not even a little. that thread hit my tl;dr detector almost immediately. 20:33:59 nirik: i have 20:34:02 Just wanted to bring it to people's attention... 20:34:33 ok, anything else for open floor? 20:34:41 * nirik will close the meeting in a minute if not. 20:34:59 i'd love some resolution on ticket #449 20:35:20 (in which i was chastised for a driveby fix) 20:35:34 but i feel like it's inappropriate for me to close it myself for exactly that reason. 20:35:59 also we don't need to resolve that here and now. 20:36:30 well, we could... 20:36:56 #topic #ticket 449 - I don't want anyone to commit my packages 20:37:01 so, first: 20:37:08 .fesco 449 20:37:12 gholms|work: #449 (I don't want anyone to commit my packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/449 20:37:17 can we vote on providing a provenpackager exception for all of those packages? 20:37:21 I'm -1 20:38:04 and second part, I think we answered eariler with the provenpackager and merge reviews thing. 20:38:11 yeah, I'm definitely -1 on that. 20:38:14 is the difference between a drive-by fix to a bug and a merge review change not obvious? 20:38:48 (recusing myself from voting for all the normal reasons) 20:39:01 i'm obviously -1 on the provenpackager exception request 20:39:08 -1. 20:39:24 Yeah, I'm -1 20:39:35 #agreed no exception to provenpackager commits here. 20:40:03 So, I think we answered the rest of the request with the merge review stuff eariler? Or is there other items we should address here? 20:40:53 I think it's all covered... 20:41:11 indeed. 20:41:12 #topic Open Floor (redux) 20:41:14 i think it's covered. 20:41:15 anything else? 20:41:37 nothing from me. 20:41:41 peanut gallery here, but it seems we're missing one more item in the list of when provenpackagers are allowed to edit a package 20:41:49 and it'd be the scenario that ajax used in this case. 20:42:27 or at least the item that leads to "Minor, general, or cleanup changes" should be reworded. 20:42:50 Oxf13: i was assuming " * there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package" would include EVR inversions from one release to the next. 20:42:52 right now it reads to me that it should only be done if it's part of a greater cleanup effort, not just an isolated item. 20:43:09 ajax: ah, yeah that could cover it 20:43:19 yeah, I was reading it that way as well ajax 20:43:22 * Oxf13 goes back to his peanut gallary. 20:43:39 you could spell it problem(s) i guess. 20:44:31 ok, will close the meeting if nothing else? 20:44:58 Thanks for coming everyone. 20:45:02 #endmeeting