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@gmail.com, 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