3:46 p.m.
===================================
#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-...
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(a)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