From Fedora Project Wiki
< Extras | SteeringCommittee
Summary
Present from FESCo: thl, skvidal, warren, f13, mschwendt, scop
- kmod's (once again)
- Jon Masters (jcm) is working on integrating and enhancing the Fedora kmod-scheme for RHEL; more details will probably follow soon on fedora-packaging-list (there was a post there on Friday after the meeting)
- buildsys-build (reduced packageset in default mock buildroot)
- spot's was not around, but we wanted to solve this
- we agreed on the Exceptions list from the wiki and added "which" to it; with all deps rpms pulls in the minimal buildroot for FE5/devel will contain the packages in this list (and buildsys-macros).
- this list will be used for all targets (e.g. also for FE[345] )! That might break some packages on the next rebuild in stable releases! Be careful!
- skvidal will prepare a new mock with a default buildroot that contains only the packages from http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions , buildsys-macros (and rpm will pull all the deps in)
- Encourage Extras reviews
- tibbs> | No comments received yet on my proposals. I'm happy to just start working and let folks kick me if I'm going in the wrong direction.
- warren> | tibbs, that might just be a good idea.
- MIA/AWOL maintainers (mschwendt, jwb and Michael J Knox)
- mschwendt> | thl: topic on extras-list has come to a sudden halt -- but we've discovered another AWOL
- mschwendt> | would it be a start to track these maintainers in a list e.g. in CVS owners/mia.list?
- we'll try that for now and change it later if we need something better
- Some discussions if we can require that maintainers answer some sort of periodic ping; some liked the idea, other not, other liked the scheme where all maintainers had to rebuild their packages for FE5 (and thus show up), others simply want to ping those that were inactive for X (X=24 ?) weeks
- thl> | does anyone want to work out a solution?
- mschwendt> | I think we create a Wiki page which gives guidelines on how to take over packages and at the same time we add some information about AWOL/MIA maintainers
- Co-maintainership
- People seem to have different exception on this topic. The easy "Packager A) I would like to have Packager B help me. Packager B) Ok." is possible already. But others want more from it; see this mail for some of the other, more complicated ideas.
- thl> | let's continue this on the list
- CVS
- thl> | I know I'm paranoid ;-)
- tibbs> | We already have an ACL system for CVS; it seems relatively simple to just use it.
- tibbs> | s/relatively simple/simpler than solving the halting problem/ ?
- thl> | tibbs, yeah, especially if the scripts that manage the ACL could easily be adjusted to the new system later
- thl> | and the CTRL+C problem is still unfixed (that's really annoying me)
- thl> | warren, from last weeks meeting: "thomasvs> | it's easily doable - add an ampersand to the trigger, if it runs in the background it can't be interrupted"; warren, somebody would have to try that
- warren> | Okay, I'll look into that.
- mschwendt> | in the package build report it would be interesting to see who requested a build
- a request for a system that sends a mail to package owners if one of their packages was changed/build is on the FESCo-Schedule/Todo-List for a long time already, but nobody started to work on it yet. Any volunteers? BTW, sponsors should also get direct mails for all changes from people they sponsored.
- warren> | We must keep things as open as possible to keep down overhead, and add in safety automation elsewhere.
- warren> | Seems like package database would be a big step toward many of these goals. Would anyone like to work with me in designing the package database?
- warren> | Maybe we should put together a list of goals and prioritize which to do first.
- Please use this page for the goals; one of the goals is to that this DB replaces owners.list
== Full log
0:00 --- | thl has changed the topic to: FESCo meeting in progress 0:00 < thl> | hi all 0:00 < thl> | who's around? 0:00 --> | wart-cellphone (upIRC 3.8.3) has joined #fedora-extras 0:00 < skvidal> | i am 0:00 < tibbs> | Rabble, as usual. 0:00 < warren> | around 0:00 * | skvidal rouses the rabble 0:01 < skvidal> | yah, yah! riot, loot! overthrow the oppressive regime! 0:01 < thl> | okay, let's start slowly 0:01 < skvidal> | o 0:01 < skvidal> | k 0:01 --- | thl has changed the topic to: FESCo meeting in progress -- kmod's (once again) 0:01 < thl> | the following is more a FYI atm 0:01 --> | mschwendt (Michael Schwendt) has joined #fedora-extras 0:02 * | scop here 0:02 < thl> | Jon Masters (jcm) is working on integratingand enhacing the Fedora kmod-scheme for RHEL 0:02 < thl> | he contacted me privately 0:02 < thl> | and made some test-packages available at http://www.kerneldrivers.org/downloads/ 0:03 < thl> | the kernel package provices a sort of ABI 0:03 < thl> | and the kmod's can depend on that 0:03 < jwb> | thl, to be fair, spot and abadger1999 are working on it 0:03 < thl> | and don't need a rebuild on every new kernel 0:03 < jwb> | (the voting thing) 0:03 < thl> | more details will probably follow soon on fedora-packaging-list 0:04 < thl> | jwb, k, noted ;-) 0:04 < thl> | k, moving on 0:04 < warren> | thl, cool 0:04 --- | thl has changed the topic to: FESCo meeting in progress -- buildsys-build (reduced packageset in default mock buildroot) 0:04 < thl> | spot's not around :-/ 0:05 < f13> | he's in a talk 0:05 < thl> | in any case 0:05 < thl> | I'd like to get this mostly solved 0:05 < thl> | so what about which (again)? 0:05 < thl> | spot and mdomsch wanted to add it to the default buildroot 0:05 < thl> | and I more and more think that a good idea 0:06 < thl> | and removing it now will lead to much trouble 0:06 < thl> | and might delay FC6T1 0:06 < skvidal> | I'd like to get it mostly solved, too. 0:06 < tibbs> | We don't want to break every single package. 0:06 < skvidal> | b/c it'd be nice to make a mock release knowing what things will be where. :) 0:07 * | scop feels spot not being around too much is beginning to be a problem 0:07 < f13> | which I feel is acceptable 0:07 < f13> | scop: meetings during the week is a problem. 0:07 < f13> | spot has a day job. 0:07 < scop> | sure, but he also sits on quite a few things 0:07 < skvidal> | f13: I have a day job, too. :) 0:07 < scop> | that others would be capable of driving forward 0:07 < skvidal> | f13: in fact, I'd bet, we all do 0:08 < f13> | skvidal: yours doesn't involve flying across the country at any time. 0:08 < f13> | scop: what are we waiting on? 0:08 < skvidal> | f13: I flew to NZ for mine! :) 0:08 < skvidal> | f13: but point taken 0:08 < f13> | scop: we can make the package decision, he's just the gatekeeper to the guideline. 0:08 < thl> | let's get back to the topic ;-) 0:08 < thl> | so, shall we add which to the default buildroot? 0:08 < f13> | +1 from me 0:08 < thl> | adding which +1 0:08 < scop> | f13, incompatible package upgrade policy, various guideline fixes to name a few 0:08 < bpepple> | +1 0:08 < scop> | +0 0:08 < thl> | (we can still remove it for FC7 if we like to) 0:09 * | skvidal is all for it 0:09 < skvidal> | i just need to know what the total list will look like 0:09 < f13> | scop: guideline fixes actually need a broader set of folks to review, since it will effect Core packages too. 0:09 < skvidal> | b/c I'm a bit confused on what we agreed to add/remove/etc 0:09 * | f13 too 0:09 < mschwendt> | +1 (I see "which" and sh/bash in the same boat) 0:10 < thl> | skvidal, do you still have the mail titled "Re: packages used by mock not in Exceptions" from FESCo list 0:10 < thl> | the first reply from spot contains the list 0:10 < scop> | take the exceptions list from wiki, add which, and whatever (if anything) the build system imposes on build roots 0:10 < skvidal> | thl: and that's the definitive list? 0:11 < f13> | so of all the things that were extra, which is the only thing we want to allow in? 0:11 < thl> | skvidal, that's the "extrapolated" list 0:11 < thl> | skvidal, e.g. the exceptions and all their deps 0:11 < ixs> | nevening. 0:11 < skvidal> | the exceptions and all their deps? 0:11 --> | _wart_ (MichaelThomas) has joined #fedora-extras 0:11 < thl> | skvidal, but yes, "that's the definitive list" + which 0:11 * | skvidal is evidently still confused 0:11 < mschwendt> | you're not alone 0:11 < skvidal> | thl: you, clearly, understand what this list is supposed to be 0:11 < thl> | skvidal, the list of exceptions from the Packaging guidelines from the wiki and all their eps 0:11 < thl> | deps 0:11 < skvidal> | thl: please do this 0:12 < f13> | here we go 0:12 < skvidal> | thl: email me the list of things it has to be, the total list - and I'll get the resolution 0:12 < skvidal> | and get all the deps, okay? 0:12 < f13> | autoconf 0:12 < f13> | automake 0:12 < f13> | automake14 0:12 < f13> | automake15 0:12 < f13> | automake16 0:12 < skvidal> | that's it 0:12 < f13> | automake17 0:12 < f13> | bison 0:12 < skvidal> | f13: don't paste it in here 0:12 < f13> | buildsys-macros 0:12 < f13> | byacc 0:12 < f13> | createrepo 0:12 < f13> | ctags 0:12 < f13> | diffstat 0:12 < thl> | f13, that's the list of stuff that's going to be removed 0:12 < f13> | doxygen 0:12 <-- | wart-cellphone has quit () 0:12 < f13> | flex 0:12 < skvidal> | hahahah 0:12 < f13> | gdb 0:12 < f13> | gettext 0:12 < f13> | indent 0:12 < f13> | intltool 0:12 < f13> | libtool 0:12 < f13> | openssh-server 0:12 < f13> | patchutils 0:12 < f13> | perl-XML-Dumper 0:13 < f13> | perl-XML-Parser 0:13 < f13> | perl-XML-SAX 0:13 < tibbs> | Let's see who gets kicked for flooding. 0:13 < f13> | pkgconfig 0:13 < f13> | rpm-python 0:13 < f13> | strace 0:13 < thl> | btw, we of course also need buildsys-macros ;-) 0:13 < f13> | which 0:13 < f13> | shit 0:13 < f13> | that was supposed to be in /query 0:13 < ixs> | hehehehe 0:13 < jwb> | tibbs, seems auto-throttled 0:13 < f13> | well, other than 'which' do we need to keep anything else? 0:13 < skvidal> | rpm -q shit 0:13 < f13> | skvidal: shush 0:13 < warren> | What about my proposal from last week? there are really two lists. 0:13 < warren> | 1) The Exceptions list 0:13 < warren> | 2) The derived list = Exceptions + all deps it pulls in 0:13 < warren> | The derived list is our minimum buildroot 0:14 < f13> | warren: youre point? 0:14 < f13> | the packages I posted are those that aren't in the exceptions + deps 0:14 < warren> | That makes it easier to maintain and we can see how things change in the derived list over time with diff. 0:14 < f13> | thus should be removed from the buildroots 0:14 < warren> | f13, skvidal asked for a list of packages, not what we're removing. 0:14 < f13> | all except 'which', and we'll add that to hte exceptions. 0:14 < warren> | Did we ratify that? 0:15 < warren> | I'm +1 it 0:16 < warren> | I recall last week a few people here were opposed to adding which, and we deferred discussion on additions. 0:16 < thl> | okay, just fyi 0:16 < thl> | this is the list: 0:16 < thl> | http://pastebin.com/751683 0:17 < thl> | It's the list spot send around 0:17 < f13> | http://fedoraproject.org/wiki/Extras/FullExceptionList 0:17 < thl> | and I added which and buildsys-build 0:17 < f13> | warren: we just voted it in. 0:17 < f13> | thl: what is 'buildsys-build' ? 0:17 < scop> | buildsys-macros? 0:17 < skvidal> | you mean buildsys-macros 0:17 * | warren adds note to that wiki page 0:17 < thl> | sorry, yes, buildsys-macros 0:18 < f13> | ah ok. 0:18 < mschwendt> | thl: that's the minimal buildroot (extrapolated), isn't it? 0:18 < thl> | mschwendt, yes 0:18 < skvidal> | f13: and the page you linked to doesn't include 'which' 0:18 < f13> | mschwendt: thats the wiki page I put up yes, the extrapolated list. 0:18 < f13> | skvidal: excellent point. I'll add which and buildsys-macros 0:18 < warren> | f13, derived is a better word for it. 0:18 < warren> | Where is the URL with the original Exceptions list? 0:19 < warren> | We should link to/from the original list, and the derived list. 0:19 < thl> | warren, http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions 0:19 * | warren adds which 0:19 < f13> | warren: you take your half of the hair, and I'll take my half. 0:20 < thl> | so everyone: do we agree on that list? any open questions? 0:20 < f13> | I'm in agreement. 0:20 < f13> | I just want a list finalized so that we cna fix all the damn packages. 0:20 < thl> | k, just for the sake of it 0:21 < thl> | can I get some +1 for the list please? 0:21 < skvidal> | +1 0:21 < thl> | +1 0:21 < warren> | +1 0:21 < mschwendt> | +1 http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions plus "which" looks okay 0:21 < f13> | +1 0:21 < thl> | k, settled 0:21 < bpepple> | +1 0:22 < thl> | do we want to use thise list for FE5 and FE4, too? 0:22 < thl> | or only for devel? 0:22 < mschwendt> | same list for all targets 0:22 < f13> | indeed 0:23 < f13> | all targets 0:23 < thl> | mschwendt, bears a risk that stuff might break in stable releases 0:23 < f13> | skvidal: whats the timeline for a new mock package set that uses this new list? 0:23 < f13> | thl: If you're rebuilding, add a missing dep. 0:23 < f13> | thl: exceptions per release is confusing. 0:23 < skvidal> | f13: I'm fine with doing it whenever. I'll run a release suggestion by buildsys-list to see if folks are happy enough 0:23 < skvidal> | otherwise I'd be happy with this weekend 0:23 < scop> | all targets, then take diffs about what that expands to in different releases and see if there's anything in them that needs further action (such as explicit addition to the list) 0:24 < f13> | skvidal: awesome. 0:24 < thl> | okay, "this list for all target" settled (I think we can omit the +1 voting here) 0:24 < thl> | anything else on that topic? 0:24 < warren> | wait, question 0:24 < mschwendt> | thl: no, same list for all targets helps packagers in keeping their spec files in sync for all targets 0:25 < warren> | What if the derived deps in the full list don't exist in earlier distros? 0:25 < warren> | Shouldn't we use a derived list for each distro? 0:25 --> | manderss (Mikael Andersson) has joined #fedora-extras 0:25 < thl> | mschwendt, "no"? Earlier you said " < mschwendt> | same list for all targets" 0:25 * | thl confused? 0:25 < f13> | warren: the drived list is just to show what gets pulled in by deps. The Exceptions itself is what should be used. 0:25 < f13> | the Exceptoins is what should be pulled in, and what they depend on. 0:26 < warren> | f13, I can agree to that, but is that what we agreed upon? 0:26 < mschwendt> | thl: scroll back later, then you see what I replied to ;) 0:26 < mschwendt> | thl: same list for all targets 0:26 < thl> | mschwendt, k :)) 0:26 --> | has joined #fedora-extras 0:26 < skvidal> | okay wait 0:26 < warren> | To be clear, the minimum buildroot pulls in the Exceptions list, or the derived per-distro full list? 0:26 < skvidal> | 1. why would we have the full list, we can just let the depsolving dtrt 0:26 < > | hi 0:26 < warren> | skvidal, +1 0:26 < thl> | skvidal, +1 0:27 < f13> | sk +1 0:27 < f13> | use the Exceptoin list, and yes, dtrt w/ depsolver. 0:27 < warren> | That Exceptions list has worked fine for us ever since RH8 without any changes. which is the first change in years really. 0:27 < f13> | warren: the problem is the buildroots were getting MORE than what is in the exception and deps. 0:27 < f13> | warren: so 'working' is misleading. 0:28 < warren> | f13, the buildroots totally ignored the Exception list previously. 0:28 * | thl still wondes how that happend 0:28 * | thl will simply ignore that 0:28 * | jwb is getting dizzy 0:28 < warren> | I did complain about this during the early extras-buildsys 0:28 < f13> | thl: easy. skvidal was given a package let, he made it happen. Nobody noticed until recently 0:28 < warren> | I noticed but I didn't want to fight that battle. 0:28 < skvidal> | I think the list came from @core in comps + other devel stuff 0:28 < thl> | okay, the battle seems fought now 0:28 < warren> | only recently did we have more support to enforce buildreqs on even core. 0:28 < mschwendt> | f13: it didn't go unnoticed... 0:28 < skvidal> | but I honestly don't remember where that list came from 0:29 < warren> | maybe mach? 0:29 < skvidal> | I'm reasonably certain I didn't make it up b/c half of the stuff I wouldn't have thought of 0:29 < skvidal> | warren: maybe? 0:29 < skvidal> | I dunno 0:29 < skvidal> | :) 0:29 < warren> | yeah, I think so 0:29 < jwb> | who cares 0:29 < thl> | jwb, exactly 0:29 < warren> | anyway we fixed it now 0:29 < thl> | so just to be clear: 0:29 < thl> | skvidal, you prepare a new mock with a default buildroot that contains the pacakges from http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions 0:29 < thl> | and buildsys-macros 0:30 < thl> | that okay for everybody? 0:30 < warren> | +1 0:30 < skvidal> | that is the plan, yep. 0:30 < thl> | k, so I'm moving on 0:30 < scop> | just for the record, mach has always followed the exceptions list as far as I know 0:30 < warren> | scop, nope. 0:30 --- | thl has changed the topic to: FESCO meeting in progress -- Encourage Extras reviews 0:31 < mschwendt> | mach even excluded gcc-c++ 0:31 < thl> | tibbs, warren, any news? 0:31 < warren> | scop, the default mach config had its own list. mach on fedora.us had the Exceptoins list. 0:31 < tibbs> | No comments received yet on my proposals. 0:31 < warren> | tibbs, sorry 0:31 < warren> | I'm finally getting caught up in my mail 0:31 < tibbs> | I'm happy to just start working and let folks kick me if I'm going in the wrong direction. 0:31 < scop> | warren, the fedora.us/fedora-extras list is obviously what I'm referring to 0:32 --> | jpo (Jose Pedro Oliveira) has joined #fedora-extras 0:32 < warren> | tibbs, that might just be a good idea. 0:32 < thl> | warren, can you try to give tibbs some feedback in the next days 0:32 < tibbs> | It's a wiki; we can always revert. 0:32 < warren> | thl, yes, I can and will. 0:32 < thl> | tibbs, yeah, that's probably better 0:32 < thl> | we can look at it next week then and change things if we really thing that should be needed 0:33 < tibbs> | OK, I'll spend some time trying to put things in order. 0:33 < thl> | tibbs, tia 0:33 < f13> | hrm, so we're asking people to BuildRequire: kernel-dev ? 0:33 < tibbs> | The latest fun thing is people without fedorabugs access thinking they can't add anything to bugzilla. 0:33 < thl> | f13, ??? 0:34 < f13> | thl: the drived list doesn't bring in 'kernel' or 'kernel-dev' or anything like that. 0:34 < cweyl> | the review guidelines are rather vague on that point. what do people actually need fedorabugs for? to assign them to self? 0:34 < thl> | tibbs, new contributors also don't get edit access to the wiki during the process 0:34 < thl> | f13, sure 0:34 < f13> | @core is what brings that in, there is no real dep chain to get to kernel. 0:34 < warren> | f13, it shouldn't. 0:34 < thl> | f13, the kmod standard handles the BR for kernel-dev 0:34 < f13> | thl: k. 0:34 < tibbs> | thl: they can do the cla, though, and then get added to the editgroup. 0:34 < thl> | and kernel should normally uneeded 0:34 < thl> | (afaik) 0:34 < tibbs> | I'd hope that everyone who wants to review would at least try to get the CLA done. 0:35 < thl> | tibbs, yeah, sure, but that not written down probably in the stpe-by-step guide howto become a contrinbutor 0:35 < thl> | k, moving on 0:35 --- | thl has changed the topic to: FESCO meeting in progress -- Incompatible package upgrade policy 0:35 < thl> | on the schedule, still assigned to "nobody" 0:36 < thl> | any takers? 0:36 < scop> | spot said he'd work on it 0:36 < thl> | k 0:36 --- | thl has changed the topic to: FESCO meeting in progress -- MIA/AWOL maintainers 0:36 < thl> | mschwendt, jwb and Michael J Knox 0:36 < scop> | by the way we got another of those incompatible upgrades this week 0:36 < thl> | scop, huh? what package? 0:36 < scop> | libpqxx 0:37 < tibbs> | And there's still fallout from amarok. 0:37 < thl> | and directfb still old, too (iirc) 0:37 < thl> | anyway, back to MIA/AWOL maintainers 0:38 < mschwendt> | thl: topic on extras-list has come to a sudden halt -- but we've discovered another AWOL maintainer 0:38 < thl> | mschwendt, yeah, saw that 0:38 < mschwendt> | would it be a start to track these maintainers in a list 0:38 < mschwendt> | e.g. in CVS owners/mia.list? 0:38 < thl> | mschwendt, did we remove Kevin Gray from cvsextras in the accounts system? 0:38 * | warren checks. 0:39 < mschwendt> | only admins and his sponsor can do that 0:39 < thl> | mschwendt, unsure; what would be the benefit of such a list? 0:39 < mschwendt> | do you want to remove access right away? 0:40 < thl> | mschwendt, I don't know; probably not 0:40 < warren> | what is Kevin's username? 0:40 < thl> | but for this case where the maintainer is AWOL for such a long time: maybe 0:40 < mschwendt> | iprone 0:41 < thl> | mschwendt, so you want owners/mia.list to track such maintainers? yeah, why not 0:41 < thl> | +1 0:42 < warren> | I'll just remove the priv from iprone. If he reappears we'll deal with it later. 0:42 < warren> | ? 0:42 < thl> | mschwendt, even as we don#t get any more +1 (as it looks like) please create that page with a format to your likeing 0:42 < jwb> | gnome-yum has an AWOL maintainer too 0:42 < thl> | and freenx probably, too (see the list) 0:43 < jwb> | i plan on yanking gnome-yum soon 0:43 < mschwendt> | that's the problem -- we need to track such maintainers before we know how long they are missing 0:44 < thl> | jwb, just do it like we did for hula and freenx did for now 0:44 < mschwendt> | hence a list -- either wiki, cvs or account system 0:44 < thl> | mschwendt, and we can have a better solution for the future 0:44 < warren> | one possible thing we could track in a package database 0:44 < jwb> | thl, which was how exactly? 0:44 <-- | roozbeh has quit (Read error: 110 (Connection timed out)) 0:44 * | jwb has been lax in readin f-e-l for the past week, sorry 0:44 < thl> | jwb, https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00007.html 0:44 < tibbs> | Can we require that maintainers answer some sort of periodic ping? 0:45 < thl> | tibbs, that would be a good thing imho 0:45 < ixs> | tibbs: please don't 0:45 < tibbs> | ixs: please don't what? Come up with ideas? 0:45 < thl> | ixs, we need some periodic pong 0:45 < thl> | look at the time shortly before FC5 was released 0:45 < ixs> | tibbs: don't require them to pong periodicaly. 0:45 < jwb> | thl, i did that with the gnome-yum maintainer already 0:45 < jwb> | thl, no reply 0:46 < thl> | and how many orphaned packages we found 0:46 < skvidal> | here's an idea 0:46 < mschwendt> | jwb: is there a bugzilla ticket about that? 0:46 < jwb> | mschwendt, one sec 0:46 < skvidal> | what if we just use the data in the rpms for this 0:46 < cweyl> | maybe, if it looks like someone has gone AWOL, file a "ping" bug against a package of theirs? 0:46 < skvidal> | if the pkg hasn't been built in > than N weeks we send the owner an email 0:46 < thl> | jwb, then send a mail to the list, wait some days and then proceed with "yanking gnome-yum" 0:46 < f13> | skvidal: that would suck for stable packages. 0:46 < ixs> | skvidal: sounds much better. no package build or nothing from the maintainer in the cvs for X weeks, mail. 0:47 < skvidal> | f13: make the number of weeks 24 0:47 < skvidal> | f13: so if you don't have a package rebuilt w/i 6 months 0:47 < skvidal> | something is WRONG 0:47 < ixs> | f13: but being pinged all the time sucks even more. 0:47 < skvidal> | b/c there will most likely be a release 0:47 < jwb> | thl, will do 0:47 < skvidal> | f13: just do it against devel :) 0:47 < f13> | skvidal: haha 0:47 < ixs> | skvidal: please please please do aggregate that. I do not want to have to answer pings against barcode jsut because barcode hasn't had a new releasesind 2003. 0:47 < jwb> | mschwendt, bugzilla is being slow, but it's bug 191614 0:47 * | f13 wonders how long ago he build his package in Extras.... 0:48 * | thl liked the FE5 scheme where all packages were rebuild 0:48 < thl> | but that'S PROBABLY TO COMPLICATED FOR EVERY RELEASE 0:48 < thl> | sorry 0:48 < thl> | hit caps-lock accidetelly 0:48 < f13> | I thought you felt really strong about that (: 0:48 * | skvidal shudders while thl yells 0:49 < mschwendt> | thl: really? your recent security related messages on extras-list give a different impression 0:49 < f13> | thl: we could just make GCC changes often enough to require full rebuilds. 0:49 < thl> | mschwendt, yours too ;-) 0:49 < f13> | usually every other FC release. 0:49 < thl> | f13, there are still the noarch packages 0:50 < thl> | so some sort of ping seems to be needed 0:50 < f13> | we'll make changes to bash, python, perl (: 0:50 < thl> | does anyone want to work out a solution? 0:51 < mschwendt> | I think we create a Wiki page which gives guidelines on how to take over packages 0:51 < mschwendt> | and at the same time we add some information about AWOL/MIA maintainers 0:51 < thl> | mschwendt, that would be a start 0:51 < skvidal> | mschwendt: mmm package takeover - can it be a hostile package takeover? 0:52 < mschwendt> | skvidal: no 0:52 < skvidal> | mschwendt: aaaaaaaaaaaw, fooey 0:52 < mschwendt> | that has been covered on extras-list in the thread about this 0:52 < skvidal> | mschwendt: I was joking :) 0:53 < mschwendt> | doesn't matter ;) 0:53 < thl> | mschwendt, can you add this informations to the wiki please? 0:53 < thl> | it not urgent 0:53 < mschwendt> | k 0:53 < thl> | just do it when you find time for it 0:53 < thl> | mschwendt, thx 0:54 --- | thl has changed the topic to: FESCO meeting in progress -- Co-maintainership 0:54 < thl> | some discussion on the list currently 0:54 < f13> | this shouldn't be so hard. 0:54 < thl> | I think we proceed there for now? 0:54 < f13> | Packager A) I would lke to have Packager B help me. Packager B) Ok. 0:54 < thl> | f13, yeah, the easy things are possible already 0:54 < f13> | problem solved. 0:54 < mschwendt> | exactly 0:55 --> | che (Che Guevara) has joined #fedora-extras 0:55 < f13> | what is left for FESCO? 0:55 < thl> | f13, see https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00040.html 0:55 < che> | evening. 0:55 < thl> | f13, I'd really like to get https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00506.html running 0:55 < thl> | f13, and having different maintainers for different releases would be nice, too 0:56 < thl> | but that's all a nice to have 0:56 < thl> | and not urgent 0:56 < skvidal> | brb 0:56 < thl> | we can do that when we find time for it 0:56 < mschwendt> | proxying packages into CVS before somebody gets sponsor bears the risk of ending in fire'n'forget packages, however 0:57 < mschwendt> | it's better to give new contributors access and take the access away if need be 0:57 < thl> | seems people didn#t like the proxy idea to much 0:57 < thl> | that would mean a lot of work 0:57 < warren> | mschwendt, that works, if the sponsor keeps an eye on who they sponsored 0:57 < thl> | that's why the idea with cvs access, but no access to plague came up 0:57 --> | mmcgrath (http://naim.n.ml.org/ user) has joined #fedora-extras 0:58 < thl> | warren, we're lacking sponsors already 0:58 < thl> | warren, that would make things even more worse 0:58 < thl> | and increase their load 0:59 < thl> | anyway, it's getting late 0:59 < thl> | let's continue this on the list 0:59 < f13> | food calls 0:59 --- | thl has changed the topic to: FESCO meeting in progress -- Weekly sponsorship nomination 1:00 < thl> | so, what about mdomsch? 1:00 < thl> | I understand the concerns that were raised 1:00 < thl> | but he gets a +1 from me 1:01 < thl> | spot gave a +1, too 1:01 < mschwendt> | I stick to my -1 1:02 < jwb> | i would say +1 but i haven't seen the concerns 1:03 < mschwendt> | my concerns are that I haven't seen more than a single very brief package approval from him 1:03 < warren> | It is true that he hasn't been a leader in Extras specifically 1:03 < warren> | but he does things in Extras, Core and mock 1:03 < warren> | and he agreed to be responsible for anybody he sponsors 1:03 < warren> | I think that's good enough. 1:03 < tibbs> | Is sponsorship about contributions to extras, or about the package review process specifically? 1:03 < thl> | warren, mostly agreed 1:04 < jwb> | right. in my utopian view of the world, there is not Core or Extras. only Fedora. and he's doing a lot to help Fedora 1:04 < thl> | warren, but we should talk about this issue mschwendt raised 1:04 < warren> | sponsorship is about a judgement that they understand the packaging guidelines and process and they can supervise new members in education of that. 1:04 < thl> | single line approvals are not the best way to approve a package 1:04 < warren> | that is true... 1:04 < thl> | I suppose he'll be more verbose in the future then 1:05 < mschwendt> | there's also the period of monitoring sponsored contributors at least a bit 1:05 < thl> | < warren> | and he agreed to be responsible for anybody he sponsors 1:05 < thl> | mschwendt, that enough for you? 1:06 < warren> | I withdraw my +1. I'm +0 and will go with whatever the group decides on tihs. 1:06 < warren> | this* 1:06 < mschwendt> | thl: do we have quorum? 1:07 < thl> | warren, okay, then let's get back to this next week 1:07 < thl> | and talk to mdomsch about it 1:07 < thl> | that's okay for everybody? 1:07 < mschwendt> | there are more FESCO members, just vote 1:07 < mschwendt> | -1 is easily compensated ;) 1:07 * | skvidal abstains. I know matt and I like him as a person so I'm biased in that direction 1:08 < thl> | I think talking with him and getting back to this next week is the best solution for everyone 1:08 < warren> | mschwendt, I have had trouble with Luya ever since I made the mistake of sponsoring him. He requires too much hand holding. 1:08 < skvidal> | <nod> 1:08 < thl> | we can still vote then if we like 1:08 < thl> | k, moving on 1:09 --- | thl has changed the topic to: FESCO meeting in progress -- Free discussion 1:09 < thl> | or does anyone talk about the CVS thing? 1:09 < thl> | I know I'm paranoid ;-) 1:09 < warren> | I haven't been able to read that thread yet 1:09 < warren> | are there any concrete implementation proposals? 1:09 < thl> | warren, nope 1:09 < thl> | warren, the biggest question probably is 1:10 < thl> | it is worth the trouble if we get a new scm system after FC6? 1:10 < tibbs> | We already have an ACL system for CVS; it seems simple to just use it. 1:10 < tibbs> | s/simple/relatively simple/ 1:10 < thl> | tibbs, yeah, especially if the scripts that manage the ACL could easily be adjusted to the new system later 1:11 < thl> | and the CTRL+C problem is still unfixed (that's really annoying me) 1:11 < tibbs> | s/relatively simple/simpler than solving the halting problem/ ? 1:12 < thl> | warren, how could work on fixing that? 1:12 < warren> | That's what I was referring to 1:12 < thl> | warren, or at least lower the chances that the commit-diff is not send? 1:12 < warren> | *how* would we fix that? 1:12 < warren> | the mail is sent from the cvs server right? 1:12 < tibbs> | Would it be reasonable to send a weekly CVS activity report to each maintainer? 1:13 < _wart_> | tibbs: +1 1:13 < tibbs> | The problem with running syncmail is that the CVS server will abort the process if the client exits. 1:13 < thl> | warren, from last weeks meeting: "thomasvs> | it's easily doable - add an ampersand to the trigger, if it runs in the background it can't be interrupted" 1:13 < thl> | warren, somebody would have to try that 1:13 < warren> | Okay, I'll look into that. 1:13 * | warren adds to list... 1:13 < thl> | warren, thx 1:14 < mschwendt> | in the package build report it would be interesting to see who requested a build 1:14 < thl> | k, anything else that needs to be discussed? 1:15 < thl> | mschwendt, that would be nice 1:15 < thl> | mschwendt, even nicer if there could a sign if the one that requested the build is listed as maintainer in owners.list 1:15 < cweyl> | mschwendt: especially if that person is not the owner in the owners list.. 1:15 < warren> | mschwendt, wouldn't that be another thing only possible with a databaes? 1:16 < mschwendt> | I'm not familiar with plague at all. Dunno. 1:16 < cweyl> | I believe it would require additional coding for plague to check it directly. 1:17 < tibbs> | I have pushed several builds for other people; I hope it doesn't get restricted too tightly. 1:17 < mschwendt> | plague sends a mail about successful/failed build attempts. It could mail a copy to the owner and Cc from owners.list 1:17 < warren> | I don't suggest that we restrict things to owners 1:17 < tibbs> | Then again, I can see the converse; I don't want just anyone pushing builds for my packages. 1:17 < thl> | warren, +1 1:18 < cweyl> | warren: nor I. but I'd like to know if someone requested a build of one of my packages 1:18 < warren> | We must keep things as open as possible to keep down overhead, and add in safety automation elsewhere. 1:18 < thl> | cweyl, that's on the schedule for some time already 1:18 < warren> | Seems like package database would be a big step toward many of these goals. 1:18 < warren> | Would anyone like to work with me in designing the package database? 1:18 < cweyl> | thl: oh, well then, +1 :) 1:19 < thl> | cweyl, somebody jsut has to write the code and some scripts ;-) 1:19 < tibbs> | warren: Not sure I speak enough of the same languages as you to help much. 1:19 < warren> | It's been years since I've done any SQL, but this is very necessary so I'm going for it. 1:19 < cweyl> | thl: if python didn't make my head hurt ;) 1:20 < tibbs> | Will discussion about this thing happen in any particular place? I'm happy to hang out and contribute what I can. 1:20 < cweyl> | ditto. 1:20 < thl> | well, "this thing" probably won't even start afaics until we have somebody that actually plans to do the work 1:21 < warren> | extras-list probably 1:21 < tibbs> | Ah, good; my mailing list count gets to stay at 137. 1:21 < thl> | warren, I can add it to the schedule -- that okay for you? 1:21 < warren> | <gulp> 1:21 < thl> | I just want to make sure it doesn't get forgotten 1:21 < thl> | :-) 1:21 < warren> | we can't escape the need for this 1:22 < warren> | I can't do it alone 1:22 < thl> | warren, btw, would this package database replace owners.list? 1:22 < warren> | but I'll work on it 1:22 < tibbs> | Honestly, I'll help out in any way I can. 1:22 < warren> | thl, one of the thousand goals, yes. 1:22 < thl> | warren, just wanted to make sure 1:22 < mschwendt> | "thousand goals" hits the nail on its head 1:22 < thl> | warren, we probably should get the infrastructure tema more involved 1:22 < tibbs> | Are perhaps ten of these goals written down anywhere? 1:22 < thl> | team 1:22 < warren> | Maybe we should put together a list of goals and prioritize which to do first. 1:22 < mschwendt> | such a database could turn out to become quite complex in what data are tracked 1:23 < thl> | warren, I'll create a sub-page in the wiki for tracking 1:23 < thl> | k, quite late 1:23 < warren> | I'll start the mail thread for goals and priorities 1:23 < thl> | anything else? 1:23 < warren> | I move that we end this meeting. 1:23 * | thl will close the meeting in 60 1:24 * | thl will close the meeting in 30 1:24 < mschwendt> | WHAT? 30 minutes left? 1:24 * | thl will close the meeting in 15 1:25 < thl> | -- Mark meeting end -- 1:25 < thl> | mschwendt, ;-)) 1:25 < thl> | thx everyone!