=================================== #fedora-meeting: FESCO (2010-08-17) =================================== Meeting started by nirik at 19:30:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-08-17/fesco.2010-08-17-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:03) * #351 Create a policy for updates - status report on implementation (nirik, 19:33:16) * 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. (nirik, 19:42:58) * need to document and see what current setup is. (nirik, 19:43:10) * #382 Implementing Stable Release Vision (nirik, 19:44:35) * ajax has docs to commit hopefully today. (nirik, 19:46:09) * nirik talked with QA and they want FESCo to track new updates issues and then get feedback from them where needed. (nirik, 19:46:31) * #448 Disallow packages whose primary owner is group. (nirik, 19:47:44) * 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. (nirik, 19:54:41) * #370 allow bundling libiberty (nirik, 19:55:02) * AGREED: libiberty, gnulib, and libegg are not libraries. They are exempt from the library bundling clause. (nirik, 20:18:02) * #450 provenpackager request - supercyper (nirik, 20:18:49) * AGREED: Request not approved at this time, but please keep working with fedora and reapply at a later date. (nirik, 20:26:57) * FES tickets (nirik, 20:27:18) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 lists the current bunch (nirik, 20:28:14) * a number of new folks applied in the last week. (nirik, 20:28:31) * Open Floor (nirik, 20:29:02) * #ticket 449 - I don't want anyone to commit my packages (nirik, 20:36:56) * AGREED: no exception to provenpackager commits here. (nirik, 20:39:35) * Open Floor (redux) (nirik, 20:41:12) Meeting ended at 20:45:02 UTC. -- 19:30:02 <nirik> #startmeeting FESCO (2010-08-17) 19:30:02 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:02 <nirik> #meetingname fesco 19:30:02 <zodbot> The meeting name has been set to 'fesco' 19:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:03 <nirik> #topic init process 19:30:20 <mjg59> Afternoon 19:30:43 * nirik waves 19:31:03 * notting is here 19:31:03 <ajax> run! 19:31:09 * jsmith is here 19:31:12 * mclasen too 19:31:49 <nirik> SMParrish / kylem / pjones: you guys around? 19:32:51 <kylem> yo. 19:33:13 <nirik> ok, I guess lets go ahead and get started in... 19:33:16 <nirik> #topic #351 Create a policy for updates - status report on implementation 19:33:16 <nirik> .fesco 351 19:33:20 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:33:28 <nirik> 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 <nirik> jlaska: you guys are still hoping to have some autoqa enabled for f14 beta? or am I misremembering? 19:34:52 <nirik> 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 <notting> is it clearly defined what's supposed to happen when an update is edited and the builds are changed? 19:36:08 <nirik> anyone have anything to add on this? should we keep this ticket open for tracking autoqa? 19:36:29 <nirik> notting: I don't think it is... we will need to find out from lmacken 19:36:33 <mclasen> notting: I don't think it is 19:36:57 <mclasen> 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 <notting> that seems... wrong. 19:37:08 <nirik> 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 <mclasen> which was good for me, but probably not intended... 19:37:26 <mclasen> nirik: I agree with that 19:37:43 <notting> nirik: that would be logical. +1 from me for that as a policy 19:37:52 <notting> i suspect that will upset more people 19:37:59 <kylem> nirik, yeah, that sounds sensible on that as a policy. 19:38:00 <nirik> which will? 19:38:07 <nirik> resetting karma? 19:38:18 <mjg59> Yeah 19:38:31 <nirik> well, it's new builds, so it should be retested I would think. 19:38:33 <mjg59> I think it's the right thing 19:38:44 <mjg59> But mailing list discussion suggests that it's not unanimous 19:39:25 <mclasen> 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 <mjg59> mclasen: Right, and I think that's the correct approach 19:39:43 <mclasen> assuming the new build isn't necessary to 'eliminate' negative karma 19:39:44 * pjones is here 19:39:52 <mclasen> in which case the resetting is what you want, anyway 19:40:02 <nirik> 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 <nirik> any other votes on this as a policy? or should we ask for more feedback and revisit next week? 19:41:31 <mjg59> This policy matches my interpretation of the intention 19:42:43 <nirik> well, I count that as 5... 19:42:58 <nirik> #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 <nirik> #info need to document and see what current setup is. 19:43:57 <nirik> so, any further updates thoughts or adjustments in this topic? 19:44:04 <nirik> or shall we move on to the next related ticket? 19:44:19 <ajax> next. 19:44:35 <nirik> #topic #382 Implementing Stable Release Vision 19:44:35 <nirik> .fesco 382 19:44:36 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:44:44 <nirik> anyone make any progress here from last week? 19:45:02 <ajax> i have some additional docs written but not committed yet, got pulled to rhel nonsense again 19:45:07 <kylem> sadly no due to vacationing. 19:45:16 <ajax> i'll post those by the end of the day or be very ashamed. 19:45:20 <nirik> 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 <nirik> also, they are going to work on updating the updates_lessons page with more stuff like recomendations and actions taken. 19:46:00 <nirik> ajax: cool. 19:46:09 <nirik> #info ajax has docs to commit hopefully today. 19:46:31 <nirik> #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 <nirik> anyone else have anything on this? 19:47:41 <nirik> ok, we will keep muddling along... 19:47:43 <mclasen> next ? 19:47:44 <nirik> #topic #448 Disallow packages whose primary owner is group. 19:47:44 <nirik> .fesco 448 19:47:45 <zodbot> nirik: #448 (Disallow packages whose primary owner is group.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/448 19:47:52 <nirik> This was discussed last week. 19:48:06 <nirik> I'd like to revisit and see what people think about merge reviews and provenpackager. 19:48:32 <nirik> there was some confusion over what we wanted to allow here. 19:49:03 <ajax> 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 <nirik> 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 <ajax> i wish to allow that. 19:49:52 <pjones> nirik: I want to allow that, for sure. 19:50:03 <pjones> otherwise, what's the point of having pp's _at all_ 19:50:17 <nirik> well, no one is reviewing their changes... pp make mistakes too. 19:50:33 <Oxf13> maintainer will get the email 19:50:34 <mclasen> most of the changes that go in our packages don't get a '4 eyes' review... 19:50:35 <nirik> but sure, they should be able to make the changes sanely. 19:50:35 <pjones> sure, but that could be true of the normal maintainer case as well. 19:50:47 <pjones> we can't stop mistakes from happening 100% through review, and that's not really the goal 19:51:36 <nirik> 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 <pjones> I don't really think that was a very realistic goal. 19:52:00 <ajax> nirik: as the owner of more than one of the open merge reviews... 19:52:05 <ajax> as in, the package owner. 19:52:12 <mclasen> 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 <ajax> 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 <pjones> mclasen: agreed. 19:52:41 <nirik> 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 <nirik> mclasen: sure. 19:52:54 <pjones> nirik: ack I _guess_ 19:53:00 <ajax> so i tend to ignore the boring changes 19:53:15 <nirik> well, feel free to propose something else? ;) 19:53:49 <mclasen> nirik: sounds good to me 19:54:01 <ajax> +1 to nirik's proposal 19:54:09 <notting> sure, i'm convinced. +1 19:54:10 <pjones> I guess I'm +1 to that 19:54:10 <kylem> nirik, +1. 19:54:37 <mjg59> +1 19:54:41 <nirik> #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 <nirik> ok, will update the bug and the wiki after the meeting. 19:55:02 <nirik> #topic #370 allow bundling libiberty 19:55:03 <nirik> .fesco 370 19:55:04 <zodbot> nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370 19:55:06 <nirik> ajax: news here? 19:55:25 <ajax> so, in F13, there are 22 bundlers of libiberty 19:55:38 <mclasen> 2 down from last week :-) 19:55:49 <ajax> that was a miscount on my part, CVS/ isn't a package 19:56:07 <ajax> among them there are anywhere from 1 to 13 copies of any given file 19:56:23 <ajax> s/copies/versions/ 19:56:29 <ajax> summarized here: http://fpaste.org/cZKT/raw/ 19:57:02 <ajax> of those, 11 files have potentially significant ABI or functionality differences 19:57:12 <ajax> the worst offender by far being the c++ demangler 19:57:35 <ajax> (files with a * are these significant ones) 19:57:48 <kylem> ajax, yeah that's what i would have figured. :\ 19:58:19 <nirik> pretty scary, but we suspected it could be. 19:58:19 <ajax> 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 <ajax> i'll note here that literally _every_ copy of cp-demangle.c is unique 19:58:46 <ajax> (9 packages don't include it) 19:59:09 <nirik> so, asking all of them to converge on one seems pretty pie in the sky. 19:59:25 <pjones> yeah, that still seems completely unrealistic. 19:59:35 <frostbite> /manual/windows 19:59:47 <notting> so, it's the functional equivalent of expecting all libegg users to converge? 20:00:01 <pjones> notting: kindof worse, but yeah. 20:00:13 <pjones> this is just not going to happen. 20:00:47 <ajax> 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 <ajax> one sec, pasting something else... 20:01:38 <nirik> 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 <pjones> nirik: hard to make that fly with upstreams though, especially with upstream libiberty saying to do it the other way 20:02:14 <pjones> (otherwise, sounds like a great plan ;) 20:02:40 <ajax> hm, i seem to have been wrong again. 24 packages. http://fpaste.org/bzct/raw/ 20:02:43 <nirik> 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 <ajax> anyway. note that basically all of these are toolchain packages, one way or another. 20:03:25 <mclasen> and 8 of them are gcc... 20:03:32 <ajax> things that would probably depend pretty strongly on the version of the c++ demangler they're using. 20:04:13 <pjones> wait, which of those isn't toolchain? insight? 20:05:00 <ajax> heh. all i guess. i was heding on gputils and sdcc. 20:05:03 <ajax> hedging even, 20:05:28 <notting> we still ship spu-binutils? 20:05:33 <ajax> F13. 20:05:41 <ajax> i have no idea if it's in F14. 20:06:03 <ajax> anyway, what we'd floated before was "gcc and binutils can bundle but nobody else can" 20:06:11 <ajax> this seems like a pretty arbitrary restriction now. 20:06:44 <pjones> yeah, since basically all of it is toolchain 20:06:50 <mclasen> seems to allow 12 of the 24 20:07:18 <pjones> mclasen: so gcc because... it's the compiler and not say, sdcc? because... it's the compiler? 20:07:45 <mclasen> it seems arbitrary, indeed 20:07:46 <ajax> an 8051 compiler i have a little trouble considering on equal footing with gcc 20:07:51 <ajax> but, still. 20:08:05 <notting> wow, insight got a release last year. 20:08:16 <nirik> "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 <pjones> 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 <ajax> personally my preference is to stick my fingers in my ears and ignore the whole thing. 20:09:34 <pjones> 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 <pjones> ajax: yeah, I think I'm really leaning towards +1 to that 20:10:01 <nirik> if you choose not to decide, you still have made a choice. ;) 20:10:15 <notting> so, a modified version of nirik's: 20:10:21 <pjones> I think we should decide that this isn't a real issue and close the ticket ;) 20:10:34 <ajax> 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 <notting> wait, there's *never* been an actual release? 20:11:00 <ajax> never once. 20:11:08 <pjones> notting: no, of course not. 20:11:08 <nirik> woah. 20:11:15 <pjones> upstream doesn't believe it's necessary 20:11:18 <pjones> in fact they believe the opposite 20:11:22 <notting> in that case, i'm not sure we should do anything until someone does so. people are free to do that 20:11:43 <ajax> 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 <nirik> "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 <pjones> ajax: I'm sure that's the case. 20:12:16 <ajax> if they'd just called it portability/ and copied _that_ into every project, no one would have blinked. 20:12:28 <pjones> I propose that this isn't a real issue and close the ticket. 20:12:36 <ajax> i want something stronger 20:12:52 <pjones> you want us to _declare_ that it isn't an issue? 20:13:13 <ajax> Proposal: things named libiberty, gnulib, or libegg are not libraries. they are exempt from the library bundling clause, forever. 20:13:20 <nirik> well, I still think we should decide something... even if it's 'libiberty is ok to bundle anytime" 20:13:35 <pjones> ajax: okay, fine. 20:13:42 <notting> ajax: +1 20:13:46 <pjones> ajax: +1 20:13:59 <notting> does libiberty have an actual use in most programs? is the demangler exposed in better places? 20:14:10 <ajax> 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 <pjones> no, but who needs the demangler? 20:14:31 <nirik> I would be ok with that if we s/things named/ 20:14:38 <mjg59> ajax: +1 20:14:47 <ajax> nirik: amendment accepted. 20:14:57 * nirik doesn't want some loophole lawyer saying "oh, but I renamed by lib..." :) 20:15:00 <kylem> +1. 20:15:03 <mjg59> Taking this to its logical extent: 20:15:05 <pjones> nirik: fair enough 20:15:08 <kylem> notting, sadly no. 20:15:11 <mjg59> Macros in #includes shouldn't be allowed 20:15:25 <pjones> mjg59: wth? 20:15:26 <kylem> notting, and other paths to the same thing are encumbered by gplv3 in binutils. :/ 20:15:28 <mjg59> Because if someone fixes a bug we need to rebuild everything 20:15:29 <pjones> mjg59: quit that. 20:15:46 <mclasen> mjg59: they can certainly cause compat pain 20:15:54 <nirik> so, #agreed libiberty, gnulib, or libegg are not libraries. They are exempt from the library bundling clause. ? 20:16:00 <pjones> nirik: yes 20:16:01 <ajax> nirik: yes. 20:16:04 <mjg59> mclasen: Yeah, but I think trying to enforce a policy against them would be... awkward 20:16:08 <mjg59> nirik: +1 20:16:13 <gholms|work> s/or/and/ 20:16:17 <mclasen> I agree 20:16:22 <pjones> mjg59: unrealistic at very best. 20:16:41 <mjg59> So we should just reimplement libiberty as a set of .hs 20:16:50 <mjg59> And some linker magic 20:16:52 * spot is tempted to submit a list of "things bundled in chromium" 20:16:59 <nirik> any other votes? I'm +1 for this 20:16:59 <kylem> spot, don't you dar. :P 20:17:14 <gholms|work> There's already a chrome bug open for that anyway. ;) 20:17:16 <ajax> nirik: i count five them (me pjones mjg59 mclasen you) 20:17:23 * notting was +1 20:17:35 <nirik> #agreed libiberty, gnulib, or libegg are not libraries. They are exempt from the library bundling clause. 20:17:46 <gholms|work> nirik: You might want to s/or/and/ 20:17:48 <nirik> I will see about asking packaging folks to document this. 20:17:55 <nirik> #undor 20:17:56 <nirik> #undo 20:17:56 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x8c4f7d0> 20:18:02 <nirik> #agreed libiberty, gnulib, and libegg are not libraries. They are exempt from the library bundling clause. 20:18:07 <pjones> spot: completely off topic ;) 20:18:21 <nirik> ok, moving on? or anything else on this? 20:18:27 <pjones> no, let it die ;) 20:18:29 <pjones> move on 20:18:31 <ajax> please nothing else. 20:18:49 <nirik> #topic #450 provenpackager request - supercyper 20:18:49 <nirik> .fesco 450 20:18:53 <zodbot> nirik: #450 (provenpackager request - supercyper) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/450 20:19:09 <nirik> So, this was sent to us due to several -1's from sponsors. 20:20:04 <pjones> 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 <nirik> 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 <nirik> so, any votes here? thoughts? 20:22:12 <kylem> i'm tempted to defer to the sponsors judgement... 20:22:32 <ajax> zodbot: fasinfo supercyper 20:22:33 <zodbot> ajax: User: supercyper, Name: None, email: supercyper1@xxxxxxxxx, Creation: 2009-11-21, IRC Nick: , Timezone: None, Locale: None, Extension: 5140916, GPG key ID: None, Status: active 20:22:36 <zodbot> ajax: Approved Groups: @packager-zh fedorabugs packager cla_fedora cla_done 20:22:49 <ajax> lord, Name: None is the goofiest thing in the world. 20:22:56 <nirik> 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 <nirik> ajax: privacy setting 20:23:20 <ajax> i'm aware, it's just dumb 20:23:30 <pjones> nirik: I'm leaning that way as wel 20:23:31 <pjones> l 20:23:58 <ajax> 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 <mjg59> Yeah, I'd lean towards thinking that someone who's provenpackager should be able to convince sponsors that they're improving 20:24:23 <mjg59> As a guideline rather than a rule 20:24:31 <pjones> 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 <pjones> we've got to assume there will be PPs we've never met/interacted with. 20:24:47 <pjones> I mean, unless you want to start using kde. 20:24:48 <ajax> pjones: certainly. 20:25:26 <pjones> that being said, there appear to be some fairly serious reservations about choices he makes in packages. 20:25:53 <ajax> yeah, i'm with nirik's reapply suggestion. 20:26:00 * notting is +1 to nirik's reapply suggestion 20:26:17 <pjones> I guess I'll +1 that as well. 20:26:19 <mjg59> +1 20:26:57 <nirik> #agreed Request not approved at this time, but please keep working with fedora and reapply at a later date. 20:26:58 <ajax> i kinda want a %{_bedatadir} and a %{_eldatadir} now though 20:27:18 <nirik> #topic FES tickets 20:27:21 <pjones> ajax: and a %{_pdpdatadir} ? 20:27:26 <nirik> I think mmcgrath is not around currently... 20:27:38 <nirik> but he got a number of new folks applying from his plea on the devel list the other day. 20:27:46 <nirik> and got some assigned to tickets. 20:27:47 <ajax> pjones: i think we'll wait for the linux/pdp port first. 20:28:02 <notting> ajax: %{_el}? funny. 20:28:03 <nirik> If anyone has any items they would want FES to work on, please do file new tickets. 20:28:14 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6 lists the current bunch 20:28:31 <nirik> #info a number of new folks applied in the last week. 20:28:53 <nirik> I expect we will have some progress to report next week... 20:29:02 <nirik> #topic Open Floor 20:29:08 <nirik> Anyone have items for open floor? 20:29:49 <abadger1999> nirik: Just clarification; what's the rationale to write down in the pakcaging guidelines for libiberty, egg, gnulib? 20:30:11 <abadger1999> they're not libraries because _____ . 20:30:23 <mjg59> Because they're not 20:30:26 <notting> abadger1999: 1) upstream defines them as copy libraries, not to be shared 2) no actual released versions to standardize on 20:30:28 <abadger1999> hehe :-) 20:30:32 <nirik> 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 <pjones> 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 <abadger1999> 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 <ajax> and. 20:31:54 <pjones> (or, you know, more like on univac in 1951) 20:32:09 <abadger1999> Thanks. 20:32:11 <nirik> yeah, and. 20:32:23 * abadger1999 opens a wiki page to start a draft 20:32:41 <nirik> 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 <ajax> not even a little. that thread hit my tl;dr detector almost immediately. 20:33:59 <notting> nirik: i have 20:34:02 <nirik> Just wanted to bring it to people's attention... 20:34:33 <nirik> ok, anything else for open floor? 20:34:41 * nirik will close the meeting in a minute if not. 20:34:59 <ajax> i'd love some resolution on ticket #449 20:35:20 <ajax> (in which i was chastised for a driveby fix) 20:35:34 <ajax> but i feel like it's inappropriate for me to close it myself for exactly that reason. 20:35:59 <ajax> also we don't need to resolve that here and now. 20:36:30 <nirik> well, we could... 20:36:56 <nirik> #topic #ticket 449 - I don't want anyone to commit my packages 20:37:01 <nirik> so, first: 20:37:08 <gholms|work> .fesco 449 20:37:12 <zodbot> gholms|work: #449 (I don't want anyone to commit my packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/449 20:37:17 <nirik> can we vote on providing a provenpackager exception for all of those packages? 20:37:21 <nirik> I'm -1 20:38:04 <nirik> and second part, I think we answered eariler with the provenpackager and merge reviews thing. 20:38:11 <pjones> yeah, I'm definitely -1 on that. 20:38:14 <kylem> is the difference between a drive-by fix to a bug and a merge review change not obvious? 20:38:48 <ajax> (recusing myself from voting for all the normal reasons) 20:39:01 <notting> i'm obviously -1 on the provenpackager exception request 20:39:08 <kylem> -1. 20:39:24 <mjg59> Yeah, I'm -1 20:39:35 <nirik> #agreed no exception to provenpackager commits here. 20:40:03 <nirik> 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 <pjones> I think it's all covered... 20:41:11 <kylem> indeed. 20:41:12 <nirik> #topic Open Floor (redux) 20:41:14 <notting> i think it's covered. 20:41:15 <nirik> anything else? 20:41:37 <ajax> nothing from me. 20:41:41 <Oxf13> 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 <Oxf13> and it'd be the scenario that ajax used in this case. 20:42:27 <Oxf13> or at least the item that leads to "Minor, general, or cleanup changes" should be reworded. 20:42:50 <ajax> 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 <Oxf13> 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 <Oxf13> ajax: ah, yeah that could cover it 20:43:19 <nirik> yeah, I was reading it that way as well ajax 20:43:22 * Oxf13 goes back to his peanut gallary. 20:43:39 <ajax> you could spell it problem(s) i guess. 20:44:31 <nirik> ok, will close the meeting if nothing else? 20:44:58 <nirik> Thanks for coming everyone. 20:45:02 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
