=================================== #fedora-meeting: FESCO (2010-05-11) ===================================
Meeting started by nirik at 19:00:00 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-05-11/fesco.2010-05-11-19.00.log.html Meeting summary --------------- * init process (nirik, 19:00:01) * #351 Create a policy for updates - status report on implementation (nirik, 19:02:19) * #370 allow bundling libiberty (nirik, 19:07:43) * AGREED: ajax will see what packages are currently bundling this and we will revisit next week. (nirik, 19:47:06) * #373: erlang provides/requires explosion (nirik, 19:47:20) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=564018 (nirik, 19:48:12) * AGREED: Automatically generated provides/requires must be kept to a reasonable level. Per-library function provides/requires are not reasonable. If you have questions about what is, contact FESCo and/or FPC (nirik, 19:53:40) * #374 Modify Cloture rule (nirik, 19:57:39) * AGREED: proposal is accepted. (nirik, 20:01:00) * ACTION: nirik will writeup change. (nirik, 20:01:08) * #375: Bundled library exception for Zikula (nirik, 20:01:21) * AGREED: a temporary exception is granted. Will revisit and make sure 1.3.0 happens without the bundled lib. (nirik, 20:04:59) * #376 change provenpackager, sponsor acceptance procedure (nirik, 20:05:10) * AGREED: nottings proposal is approved. (nirik, 20:14:42) * ACTION: nirik will try and update wiki and sponsors and announce to devel-announce. (nirik, 20:17:19) * Fedora Engineering Services tickets (nirik, 20:17:24) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 20:17:30) * LINK: https://fedorahosted.org/fedora-engineering-services/ticket/24 (nirik, 20:18:29) * Open Floor (nirik, 20:21:54) * everyone should read https://fedoraproject.org/wiki/F14_elections_questionnaire and attend town halls, and VOTE. (nirik, 20:28:33) Meeting ended at 20:29:08 UTC. -- 19:00:00 <nirik> #startmeeting FESCO (2010-05-11) 19:00:00 <zodbot> Meeting started Tue May 11 19:00:00 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:01 <nirik> #meetingname fesco 19:00:01 <zodbot> The meeting name has been set to 'fesco' 19:00:01 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 19:00:01 <nirik> #topic init process 19:00:01 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 19:00:19 <pjones> I AM HERE. 19:00:21 <pjones> honest. 19:00:21 <nirik> skvidal: yes. ;) 19:00:48 <Kevin_Kofler> Present. 19:00:48 * cwickert is here 19:00:56 <ajax> curiously enough, the only thing that went through the bowl of petunias' mind as it fell was "oh no, not again". 19:01:00 <mjg59> Hi 19:01:30 <nirik> notting / dgilmore: you guys around? 19:01:35 <notting> yes, sorry. 19:01:50 * skvidal is here 19:02:14 * dgilmore is here 19:02:14 <nirik> ok, I guess we can go ahead and start in. 19:02:19 <nirik> #topic #351 Create a policy for updates - status report on implementation 19:02:19 <nirik> .fesco 351 19:02:21 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:02:28 <nirik> notting / cwickert: any news on the comps changes? 19:02:43 <notting> they're live in f-14. haven't wired up the critpath generation to them yet. 19:02:45 <nirik> also, stickster has asked us to note whats waiting and a schedule if possible. 19:03:09 <notting> there's a bit of an issue as to how to fix the tools to have per-release critpath, and where to automatically create and inject the list 19:03:15 <notting> (there's an open rel-eng ticket on this) 19:03:35 <nirik> ok. Could we gather the list of things we are waiting for on the wiki page/ticket? 19:03:56 <cwickert> I am fine with the Xfce and LXDE critpath packages. however the KDE critical path seems to be too little 19:04:26 <mjg59> cwickert: Given what we discussed last week, it's difficult to add more to the KDE critpath 19:04:30 <notting> *shrug* ... it's what they asked for 19:04:39 <mjg59> Since so many binaries come from one huge source package 19:04:42 <nirik> we can adjust it I think moving forward if need be. 19:04:42 <cwickert> mjg59: ok, sorry then, I was busy last week 19:04:49 <Kevin_Kofler> cwickert: Do you really want kdebase-workspace and all its dependencies on the critical path? 19:04:59 <mjg59> I don't think it's ideal, but there's no straightforward alternative 19:05:00 <Kevin_Kofler> mjg59: Even the binary packages are only minimally split. 19:05:01 <nirik> notting: would you be able to add info to the wiki page/ticket? 19:05:14 <nirik> I can ping about where autoqa and bodhi changes are. 19:05:16 <Kevin_Kofler> All of kdebase-workspace's dependencies include things like qzion, qedje and eet. 19:05:32 <notting> nirik: sure. 19:05:48 <Kevin_Kofler> kdelibs already has tons of deps like soprano etc. 19:05:48 <nirik> notting: thanks. 19:05:54 <cwickert> Kevin_Kofler: yes, because I think these are critical parts of KDE. the deps are not an excuse IMO, then you need more fine grained packaging 19:06:07 * dgilmore thinks that kdebase-workspace and its deps should be in critpath if they are required to get a basic kde shell 19:06:09 <cwickert> anyway, let's not dicuss this now given it was already discussed 19:06:10 <Kevin_Kofler> IMHO that's already way too much to scale, but of course a KDE critpath without kdelibs makes no sense in the first place. 19:06:50 <nirik> shall we move along? or discuss more? 19:07:31 <cwickert> move on please 19:07:43 <nirik> #topic #370 allow bundling libiberty 19:07:43 <nirik> .fesco 370 19:07:44 <zodbot> nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370 19:07:46 <Kevin_Kofler> kdm being on the critical path, we can't push a kdebase-workspace update without critpath scrutiny anyway as it's the same SRPM. 19:08:04 <nirik> This is an issue coming back from last week... 19:08:20 <nirik> abadger1999 wanted us to revisit this. 19:08:27 <dgilmore> i think ajax summed it up nicely 19:08:37 <Kevin_Kofler> There are some poins in ajax's reply which are just wrong. 19:08:46 <nirik> ajax's reasoning was for a static lib... this is for bundling though. 19:08:57 <dgilmore> We need to put heads with gnu project to get it fixed. and i dont think its a fight we need right now 19:09:05 <Kevin_Kofler> Re b, if we pick a soname major such as fedora14, that's not likely to conflic with upstream, ever. 19:09:08 <dgilmore> s/put/butt/ 19:09:13 <Kevin_Kofler> Soname major numbers don't HAVE to be numeric. 19:09:24 <pjones> Kevin_Kofler: but what's the point? that just means we're maintaining a fork. 19:09:30 <nirik> the issue here is BUNDLING. Not static lib. 19:09:32 <ajax> nirik: if you ignore d), no, it's not. 19:09:34 <Kevin_Kofler> Re c, it'd be the reviewer's job to scrutinize new packages for bundling libiberty. 19:09:44 <mjg59> Has libiberty's APi ever been well documented? 19:09:49 <ajax> mjg59: no. 19:09:49 <Kevin_Kofler> ajax: d is not even true! 19:09:53 <mjg59> The non-Linux aspects of it, that is 19:09:57 <Kevin_Kofler> kdesdk BRs binutils-devel for the C++ demangler. 19:09:59 <pjones> mjg59: sure. it's the union of what non-linux has that linux doesn't. 19:10:00 <ajax> Kevin_Kofler: okay. 19:10:02 <pjones> (hahahaha) 19:10:03 * nirik goes to look at how many packages bundle this. 19:10:09 <ajax> Kevin_Kofler: i didn't see that in a repoquery. 19:10:17 <Kevin_Kofler> It's because it's a static lib only. 19:10:24 <Kevin_Kofler> So there's no runtime dep. 19:10:29 <Kevin_Kofler> There would be if it were properly shared. 19:10:54 <Kevin_Kofler> And I think it's actually binutils-static for Rawhide/F13. 19:11:02 <pjones> so once we fork it, make a dso of it, and fudge a soname for it, we have to go audit the entire repo for its use. 19:11:29 <Kevin_Kofler> But it's only static, so we don't need to apply for a static lib linking exception. 19:11:34 <Kevin_Kofler> # for libiberty (used by kmtrace for cp_demangle) 19:11:34 <Kevin_Kofler> BuildRequires: binutils-devel 19:11:34 <Kevin_Kofler> %if 0%{?fedora} > 12 19:11:34 <Kevin_Kofler> # libiberty is only static, in F13+ it's only in -static 19:11:34 <Kevin_Kofler> BuildRequires: binutils-static 19:11:34 <Kevin_Kofler> %endif 19:11:39 <mjg59> Ok. So this isn't a problem in F13. 19:12:04 <mjg59> And doing anything about it in F12 doesn't really make life better for anyone 19:12:09 <abadger1999> pjones: That's irrelevant -- this is about bundling, not static 19:12:10 <Kevin_Kofler> Well, I'm not sure whether it moved back or not. 19:12:29 <Kevin_Kofler> It's a guidelines interpretation problem: if a package provides both shared/static and static-only libs, where do the static-only libs go. 19:12:42 <pjones> abadger1999: maybe for you it is, but Kevin_Kofler keeps mentioning "if it were properly shared"... 19:12:44 <Kevin_Kofler> Some people read it as that they should go to -devel, others think it's -static. 19:12:49 <ajax> abadger1999: it's not irrelevant if you consider "not bundling" to be solved by "shared library" 19:12:59 <abadger1999> mjg59, Kevin_Kofler: Also irrelevant stuff... you're talking about static exceptions, not about bundling exceptions. 19:13:38 <mjg59> abadger1999: So you mean that rather than coming from binutils, it should be its own package? 19:13:41 <mjg59> abadger1999: I don't see what that buys us 19:13:51 * nirik wishes we had info on what other packages bundle this. It's not going to be super easy to find out tho. 19:14:06 <abadger1999> ajax: They're completely separate -- a month ago I talked to a maintainer about unbundling a shared library that came from a different package --- it was in a private dir in the package therefore it wasn't found before. 19:14:20 <abadger1999> mjg59: I think there's two aspects: 19:14:25 <skvidal> nirik: look for binutils BR then look throug hthe build process of each of those? 19:14:28 <skvidal> nirik: not fun 19:14:34 <ajax> skvidal: not even that. 19:14:38 <nirik> skvidal: no, if they are bundling, they would not BR anything. 19:14:41 <ajax> skvidal: make prep everythign in the OS 19:14:41 <notting> skvidal: no, if they're *bundling*, they wouldn't be using binutils-devel at all 19:14:41 <pjones> skvidal: won't help; stuff copy-and-pastes it 19:14:45 <mjg59> skvidal: That's not really adequate. Most libibrty consumers have it bundled. 19:14:59 <abadger1999> mjg59: 1) Till opened the bug because he thinks there's a different upstream tarball for libiberty -- I'm not sure if that's true or not. 19:15:03 <skvidal> I was just talking about finding the folks who snatch it from binutils 19:15:04 <skvidal> sorry 19:15:11 <pjones> basically you have to grep an exploded tree to find it. 19:15:11 <mjg59> abadger1999: Not meaningfully 19:15:20 <nirik> so far I see 5 packages 19:15:34 <abadger1999> mjg59: 2) Several packages are bundling libiberty (binutils, gcc, and gdb are listed on wikipedia but I haven't checked the tarballs yet.) 19:15:50 <abadger1999> mjg59: So those both can be addressed. 19:15:51 <pjones> well, we *know* those three do, they're why it exists. 19:15:55 <nirik> avr-gcc, msp430-binutils, avr-gdb, ghdl, mingw32-binutils 19:16:05 <pjones> and upstream is unlikely to consider fixing those three. 19:16:29 <mjg59> abadger1999: So, like I said, it's in binutils-static in F13 and rawhide 19:16:36 <mjg59> abadger1999: Which means this isn't an issue 19:16:55 <Kevin_Kofler> One problem is, they're all different versions of libiberty, and they might not support whatever version we unbundle. :-( 19:16:56 <mjg59> binutils is simply our canonical source of libiberty 19:17:06 <nirik> mjg59: it is for the packages that don't BR and link to that .a and instead include their own private copy of it. 19:17:10 <abadger1999> mjg59: Why do you continue to talk about shared-vs-static? 19:17:15 <mjg59> nirik: That's an issue with those packages, not with binutils 19:17:22 <mjg59> abadger1999: Please indicate where I made that distinction 19:17:28 <abadger1999> mjg59: Okay -- that's fine for me me. But then that means, you are not granting an excpetion here. 19:17:42 <mjg59> abadger1999: The library is bundled with binutils, and binutils provides it for anyone else 19:17:48 <abadger1999> mjg59: Sorry -- you just took too long between your first and second line. 19:17:52 <nirik> or an exception is granted for binutils, and nothing else. 19:18:13 <abadger1999> mjg59: I typed my response to your first line before your second line came through. 19:18:34 <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically. 19:18:37 <pjones> well, so far we've only granted the (bundling) exception for binutils. 19:18:44 <mjg59> Frankly, I see libiberty as being an equivalent of libegg 19:18:48 <pjones> or rather, what notting said. 19:19:11 <mjg59> It's a pile of code with poor API and ABI guarantees that's explicitly intended to be cut and paste into code 19:19:15 <mjg59> It's ugly, but that's what it is 19:19:32 <mjg59> If people want to make use of the binutils version then that's fine, but otherwise it's reasonable for this to be bundled 19:19:40 <abadger1999> mjg59: We don't allow that anywhere else. 19:19:48 <mjg59> abadger1999: libegg 19:20:00 <abadger1999> mjg59: Not true -- propose it if you want. 19:20:04 <mjg59> If you'd like to pretend that we don't allow it, that's fine 19:20:07 <mjg59> But reality disagrees 19:20:20 <abadger1999> mjg59: it jsut means that no one has discovered it and brought it up yet. 19:20:20 * notting wonders if libiberty is older than various fesco members 19:20:23 <pjones> we haven't agreed upon an exception for it, but back in the real world it's being done. 19:20:37 <mjg59> There's simply no benefit to the projec tin being religious about this 19:20:42 <abadger1999> mjg59: If you use those criteria I have plenty of other libraries to bring up. 19:20:43 <mjg59> What benefit would refusing an exception give us? 19:21:05 <skvidal> quick question 19:21:11 <mjg59> Weigh that against the effort to ensure that every app that currently uses it works correctly with a shared static library 19:21:22 <skvidal> from the exception it seems like we don';t want any MORE bundled copies of this, if we can avoid it, correct? 19:21:27 <ajax> mjg59: s/shared/common/ 19:21:40 <mjg59> ajax: Yes, that's clearer 19:21:45 <Kevin_Kofler> pjones: That means that all the packages bundling that crap are broken and should have release blocker bugs filed against them. 19:22:01 <ajax> skvidal: it would be pleasant to avoid more, i suppose. 19:22:01 <Kevin_Kofler> (F14Blocker, it's too late for F13) 19:22:02 <abadger1999> mjg59: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries 19:22:05 <pjones> Kevin_Kofler: yes, that's what not granting other packages the exception means 19:22:10 <nirik> abadger1999: so we don't know if there is a seperate upstream release/tar of this? 19:22:11 <skvidal> okay 19:22:24 <skvidal> so - could we make it a review criteria check? 19:22:34 <pjones> Kevin_Kofler: it means we want the others to do what they can to link against the binutils-static copy in the future. 19:22:39 <abadger1999> nirik: I don't -- which is one reason I don't know if I want to say it must be separate from everything including binutils. 19:22:51 <mjg59> nirik: It's not available as a separate release 19:22:52 <skvidal> so grant the exceptions for current pkgs as per notting's proposal and add a review criteria to grep for it 19:22:55 <Kevin_Kofler> This applies to libiberty, gnulib, libegg etc. all alike. 19:22:59 <abadger1999> nirik: The other being that this is so far down in the tool chain that I don't know if it really is "special' in some way. 19:23:15 <skvidal> it won't necessarily keep it out but it might help 19:23:18 <nirik> mjg59: if it's not, then I think the exception here is ok. 19:23:22 <mjg59> I'm still asking this question 19:23:25 <mjg59> What's the benefit? 19:23:38 <pjones> skvidal: yeah, adding it to the review criteria does have some merit 19:23:42 <nirik> mjg59: being able to fix stuff in one place? 19:23:50 <mjg59> nirik: Fix what things? 19:24:02 <ajax> i'm not super thrilled with moving code duplication check into review criteria in general 19:24:06 <nirik> security / serious bugs? 19:24:07 <abadger1999> mjg59: [12:22:02] <abadger1999> mjg59: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries 19:24:16 <abadger1999> ajax: It's already in the guidelines: 19:24:31 <nirik> so, we are at 15min here. ;) 19:24:32 <mjg59> nirik: If we have a system-wide version then we fix it, rebuild everything that depends on it and then find that three packages are now subtly broken because there's no API or ABI guarantees 19:24:39 <abadger1999> ajax: MUST: Packages must NOT bundle copies of system libraries.[11] 19:24:40 <ajax> abadger1999: okay, then i feel the guidelines overprescribe 19:24:49 <nirik> who wants to continue? 19:24:51 <pjones> abadger1999: it's not a system library. 19:24:55 <halfline> it would never make sense to package libegg fwiw 19:25:01 <pjones> it's almost exactly the opposite of a system library. 19:25:02 <halfline> it's designed to be cut-and-paste 19:25:03 <mjg59> Except we only find that out months later 19:25:06 <halfline> that's the whole point of it 19:25:12 <pjones> halfline: yes. 19:25:16 <abadger1999> pjones: It is according to the definition being used by the guidelines. 19:25:19 * nirik bangs a gavel. We need to decide if we keep going or not. 19:25:23 <ajax> nirik: continue 19:25:36 <nirik> I'd like to keep going for a few more minutes myself. 19:25:36 <pjones> nirik: I'm for continuing 19:25:38 * notting is ok to continue 19:25:41 <mjg59> Ok 19:25:43 <mjg59> Proposal: 19:25:54 <abadger1999> pjones: I mean, we had this same discussion over php libraries. 19:25:57 <mjg59> libiberty is not a system library and therefore the packaging guidelines restricting the bundling do not apply 19:26:17 * nirik doesn't like that at all. 19:26:20 <Kevin_Kofler> halfline: JARs, Mono DLLs etc. are also often designed to be pasted into apps. 19:26:22 <pjones> abadger1999: the php libraries you discussed weren't designed to be cut-and-pasted, right? 19:26:32 <abadger1999> mjg59: That doesn't work. That would have to go to the FPC to decide. 19:26:40 <pjones> Kevin_Kofler: you mean bundled, which is subtly different, right? 19:26:42 <Kevin_Kofler> There's also minizip which is designed to be pasted into apps, but we're building it as a subpackage of zlib and requiring stuff to link the system copy. 19:26:51 <halfline> Kevin_Kofler: libegg is a staging area for apis to eventually be brought into a real library 19:26:58 <Kevin_Kofler> Minizip is often outright pasted and linked as regular source files. 19:27:03 <Kevin_Kofler> We still require it unbundled. 19:27:10 <halfline> Kevin_Kofler: nothing goes in libegg that isn't slated for e.g. glib or gtk eventually 19:27:25 <Kevin_Kofler> Oh, librandomcrap? Joy! 19:27:30 <abadger1999> pjones: I didn't audit them all so I don't know -- some were and some weren't ... and other people would argue that all php libraries are made to be cut and pasted. 19:27:31 <halfline> yes that's exactly what is 19:27:36 <halfline> librandomcrap 19:27:38 <nirik> I think if there's no seperate upstream release, and this comes with binutils, we should grant the exception for binutils. Other packages should be on a case by case basis, usually on the side of 'no, use binutils-static' 19:27:40 <mjg59> abadger1999: I don't believe that the reasons provided in the no bundled libraries page are usefully relevant to this issue 19:28:01 <halfline> "we need code, we haven't figured out the interface yet, we put it here for real world usage before dumping it into a supported library" 19:29:00 * notting isn't sure about mjg59's proposal. 19:29:28 <notting> 'system library' is so vague that i'd rather not try and redefine it in terms of each request that comes to fesco 19:29:37 * nirik is +1 to nottings proposal, unless the library is available as a seperate tar/project, which it doesn't sound like. 19:29:38 <Kevin_Kofler> halfline: Interestingly, KDE does fine without something like that… 19:29:39 <pjones> yeah, it's very vague 19:29:53 <pjones> OTOH, a naive conception of it doesn't really fit with what libiberty does 19:29:59 <Kevin_Kofler> We've had a kdelibs-experimental in 4.3, but it was a shlib, just with an ABI guaranteed only for 4.3.x. 19:30:07 <abadger1999> nirik: I like that -- if there's a rationale for gcc gdb, etc, I'm still willing to write the rationale for those in as well. 19:30:11 <halfline> Kevin_Kofler: *shrug* it is what is. i didn't invent it or anything 19:30:14 <Kevin_Kofler> 4.4 no longer has that, that API got finalized into kdelibs. 19:30:40 <halfline> but from its inception was designed to be cut-and-paste and explicitly never installed 19:30:47 <Oxf13> lets not let this devolve into a gnome vs kde thing. that's not helpful. 19:30:53 <pjones> Kevin_Kofler: the rationale for those is probably along the lines of "gcc isn't supposed to have to depend on gnu binutils" 19:31:01 <pjones> er 19:31:04 <nirik> yeah, how about we vote on notting or mjg59's proposals? or add another ? 19:31:06 <pjones> that was supposed to be at abadger1999 19:31:40 <nirik> pjones: it could do something different on some other platform, surely we can have it do the right thing in fedora? ;) 19:31:58 <pjones> nirik: kindof ignoring what libiberty is for there, don't you think? 19:32:10 <pjones> the whole point of it is that it won't really do much on this platform, but it's part of the code anyway 19:32:21 <Kevin_Kofler> There's stuff which is still uses. 19:32:22 <Kevin_Kofler> *used 19:32:42 <nirik> pjones: well, if gcc had some compelling need they could get an exception? 19:32:53 <Kevin_Kofler> It's part of the problem, this is a big messy mix of portability junk for broken systems and generic utility functions such as the C++ demangler. 19:32:58 <abadger1999> pjones: I can write that in but it's kind of silly as it's a build time dep and we're building a Linux distro that currently doesn't have a non-binutils provided linker. 19:32:58 <pjones> but their "need" is "this is why we wrote it" 19:33:11 <Kevin_Kofler> The C++ demangler is not in any other system library. 19:33:20 <pjones> abadger1999: sure, but the question is about the code, not the result 19:33:24 <Kevin_Kofler> kmtrace wouldn't require libiberty if it weren't the only place this code is in. 19:33:28 <mjg59> In the real world, convincing GNU to sort out libiberty properly isn't going to happen 19:33:34 <Kevin_Kofler> Well, it could copy it too, but ugh! 19:33:50 <nirik> I thought the question was the fedora package... ;) 19:34:02 <dgilmore> notting: what is your proposal? 19:34:06 <pjones> nirik: you want us to fork gcc over libiberty? 19:34:11 <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically. 19:34:13 <nirik> nope. 19:34:18 <abadger1999> mjg59: That's not a good argument -- FESCo has denied zsync and wordpress even though they've used that same upstream won't fix it argument. 19:34:22 <notting> (those are glob wildcards) 19:34:41 <pjones> notting: I'm generally in favor of that, though that's fairly close to what we decided last week IIRC. 19:34:44 <nirik> oh, I misread nottings proposal. 19:35:30 <dgilmore> notting: I think thats probably the sanest, we can start to work with gnu to try get them to release it propperly 19:35:32 <mjg59> abadger1999: We can ship a distribution without zsync and wordpress. We can't ship a distribution without gcc and binutils. 19:35:33 <pjones> abadger1999: I hate to put it this way, but we need wordpress's cooperation to build the distro just a *tad* less than gcc's. 19:35:42 <abadger1999> mjg59: We also denied rsync. 19:35:47 <pjones> and again 19:35:51 <notting> abadger1999: not in any meaningful way. 19:35:56 <pjones> we've shipped a distro without rsync before. 19:36:08 <pjones> also forking rsync to get rid of a static lib isn't nearly the same kind of pain. 19:36:23 <Oxf13> nor the same potential damage if we do it wrong 19:36:28 <nirik> s/static/bundled and forked/ 19:36:44 <ajax> i've been biting my tongue about something here, which is that we're only noticing the duplication because it happens to be named libsomething 19:37:06 <pjones> ajax: freetype is a really nice software package, isn't it? 19:37:06 <mjg59> abadger1999: If FPC want us to insist that the entire toolchain be forked from upstream, we can 19:37:09 <ajax> getting all righteous about that while ignoring all the other copypasta in the world is... inconsistent. 19:37:22 <mjg59> abadger1999: But I don't think that's a useful position for fesco to take. I don't think it benefits the distribution. I don't think it saves anyone time. 19:37:57 <pjones> also there are very rarely security implications from gcc using a library that's got a bug in it. 19:38:02 <Kevin_Kofler> So one question is: how much work would it be to unbundle libiberty from e.g. GCC? 19:38:08 <skvidal> ajax: isn't that just an issue of dealing with what you know about 19:38:12 <pjones> not that it can't happen, but the theoretical position against that is a bit of a strawman here 19:38:17 <Kevin_Kofler> I must say I'm not sure. 19:38:29 <abadger1999> mjg59: I'm wanting 1) a vote on whether bundling of libiberty is allowed and 2) the rationale for that exception that I can write into the guidelines and it won't be so silly that everyone else comes running up to say their software should fit in under the same exception. 19:38:31 <nirik> ok, we are at another 15min I think... 19:38:32 <pjones> Kevin_Kofler: you're really talking about forking gcc. 19:38:53 <Kevin_Kofler> But in principle, GCC and Binutils can be built from combined trees, doesn't that also mean building GCC against the libiberty from Binutils? 19:39:03 * cwickert got distracted by the telephone and tries to catch up... 19:39:06 <Kevin_Kofler> Or are there 2 copies of libiberty in such a combined tree? 19:39:17 <nirik> votes to continue? shall we vote? or table and gather more info? or continue? 19:39:21 <Kevin_Kofler> pjones: Patching, not forking. 19:39:32 <pjones> perpetually maintaining a patchset is called "forking". 19:39:34 <Oxf13> one in the same. 19:39:36 <ajax> right, because those are different things. 19:39:40 <Kevin_Kofler> If it has to be forked outright (or patched with a multi-MB patch or so), of course it doesn't make sense. 19:39:49 <cwickert> nirik: are there already proposals to vote on? 19:39:56 <nirik> cwickert: two so far: 19:39:58 <pjones> Kevin_Kofler: and... I think yes, you get 2 libiberty builds if you build them the way you're talking about 19:40:09 <abadger1999> cwickert: [12:34:12] <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically. 19:40:19 <nirik> <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically. 19:40:35 <notting> (or binutils-static. wherever it is.) 19:40:42 <pjones> notting: frankly, I like your proposal, but I can see the benefit to a slightly weaker "must". 19:40:46 <notting> 'the static binutils copy.' 19:40:47 <Kevin_Kofler> I think that doesn't make sense. 19:40:55 <Kevin_Kofler> If we allow those packages to bundle it, we should allow all. 19:41:16 <cwickert> nirik: thanks, and the second one? same as 1. plus grep during review? 19:41:24 * nirik is looking for the other one. 19:41:24 <ajax> i'm fine with allowing it bundled in general, sure. 19:41:32 <Kevin_Kofler> Either it's hard to unbundle or it's not. 19:41:40 <ajax> i mean, to the extent i'm okay with libiberty at all 19:41:53 <ajax> but i'm trying not to let my simmering gnu resentment bubble through here 19:42:07 <pjones> Kevin_Kofler: and that's why I see the benefit of a weaker "must". 19:42:12 <nirik> <mjg59> libiberty is not a system library and therefore the packaging guidelines restricting the bundling do not apply 19:42:43 <mjg59> I support my proposal on the grounds that libiberty is obviously not a system library 19:42:52 <abadger1999> nirik: that one isn't a proposal to me -- that's a Guidelines change that would need to go to FPC. 19:43:06 <notting> mjg59: you support your proposal on the grounds of the first clause of your proposal? 19:43:27 <cwickert> thanks nirik 19:43:30 <mjg59> notting: Yup 19:43:46 <Kevin_Kofler> abadger1999: It's a statement of fact (which may or may not be true), not a guideline. 19:43:51 <nirik> proposal: exception is granted for binutils because there is no seperate upstream release. Other packages should use binutils-static, or ask for an exception. 19:43:57 <Kevin_Kofler> Now who is entitled to make such statements is the question. 19:44:30 <nirik> The fact that there is a binutils-static package makes me think it should be usable for other packages. 19:44:31 <cwickert> nirik: what about gcc and gdb then? 19:44:46 <notting> not to stifle discussion, but should we actually vote on the various proposals to see if any pass? 19:44:52 <pjones> nirik: and it probably is - especially for new packages that decide they need libiberty 19:44:57 <nirik> cwickert: they would need to ask us for an exception. Perhaps they can use binutils static? perhaps they have a good reason not to. I don't know off hand. 19:45:04 <pjones> nirik: for packages already using it, that's not necessarily so useful. 19:45:08 <ajax> notting: i'd kind of like a repo sweep to see who else is bundling it 19:45:14 <Kevin_Kofler> Proposal: somebody should look into how much work it is to get GCC and/or GDB to build against binutils-static's libiberty. 19:45:17 <ajax> notting: which would take rather more time than i'm willing to wait. 19:45:19 <nirik> ajax: +1 19:45:29 <ajax> (which i will happily do) 19:45:30 <nirik> anyhow, I am +1 for my own proposal. 19:45:33 <Kevin_Kofler> And next week or whenever we have the data, we can make a sane decision. 19:45:36 <cwickert> nirik: I doubt maintainting a forked gcc is realistic 19:45:50 <nirik> cwickert: I don't think it is either. I didn't say we should. 19:45:52 <notting> so, table for next week; ajax will perform some investigation? 19:46:12 <ajax> +1 table 19:46:12 <mjg59> Ok 19:46:12 <skvidal> notting: +1 to that 19:46:15 <pjones> okay 19:46:23 <nirik> The question before us is binutils, and I think its ok to bundle... I don't know about gcc or gdb or whatever off hand. 19:46:29 <Kevin_Kofler> +1 to tabling for next week after investigation (notting's latest proposal). 19:46:35 <nirik> ok, thats fine too. 19:46:37 <cwickert> I'm happy with the three exceptions, but I would like to see what else is affected. so +1 for the table 19:47:06 <nirik> #agreed ajax will see what packages are currently bundling this and we will revisit next week. 19:47:20 <nirik> #topic #373: erlang provides/requires explosion 19:47:21 <nirik> .fesco 373 19:47:22 <zodbot> nirik: #373 (erlang provides/requires explosion) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/373 19:47:26 <nirik> skvidal: any news on this? 19:47:31 <skvidal> yah 19:47:32 <skvidal> in the bug 19:47:33 <notting> didn't this sort itself out? 19:47:37 <skvidal> sorta 19:47:46 <dgilmore> cwickert: really our gcc is forked now. its not the same as gnu's gcc 19:48:07 * nirik looks at the bug 19:48:08 <skvidal> 1. the erlang pkger peter lemenkov reduced the prov/reqs down to what is required and to point to the right pkg - rather than the giant function-list 19:48:12 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=564018 19:48:13 <skvidal> 2. but read his last comment 19:48:34 <skvidal> comment #50 19:48:44 * nirik tries to parse it. 19:48:44 <Oxf13> looks like they still want FESCo to make a decision here 19:49:12 <notting> proposal: what they were doing? don't do that. 19:49:21 <skvidal> notting: no kidding 19:49:43 <notting> that should probably be phrased better/nicer 19:49:45 <nirik> function level provides/requires info in repo data seems way overboard to me. 19:50:13 <skvidal> esp when they're STILL incomplete 19:50:22 <pjones> yeah. 19:50:22 <skvidal> since they don't talk about arguments to the functions 19:50:30 <nirik> automatic generation is fine, but not at a function level. 19:50:43 <nirik> so, do we need to vote on something here? 19:50:44 <pjones> skvidal: for the love of god, don't tell them that, they might get ideas. 19:50:52 <skvidal> pjones: it's already come up 19:52:01 <notting> Proposal: Automatically generated provides/requires must be kept to a reasonable level. Per-library function provides/requires are not reasonable. If you have questions about what is, contact FESCo and/or FPC. ? 19:52:24 <skvidal> notting: I tink that sounds fine 19:52:26 <nirik> +1 sounds fine to me. 19:52:31 <skvidal> +1 19:52:32 <cwickert> +1 19:52:40 <Kevin_Kofler> The problem is, the Erlang dependency generator still doesn't support being sane. 19:52:42 <mjg59> +1 19:52:46 <Kevin_Kofler> The packages they fixed, they fixed manually. 19:52:55 <cebbert> they do put the number of args to the function in the deps 19:52:57 <Kevin_Kofler> And they're saying they can't do that for all packages, only for the worst offenders. 19:53:05 <pjones> +1 19:53:06 <notting> Kevin_Kofler: it's "require the packages that contain the libraries you use". it's... essentially what we do for python, no? 19:53:07 <ajax> notting: +1 19:53:33 <pjones> cebbert: void * is your friend, eh? 19:53:40 <nirik> #agreed Automatically generated provides/requires must be kept to a reasonable level. Per-library function provides/requires are not reasonable. If you have questions about what is, contact FESCo and/or FPC 19:53:53 <nirik> so, we need to fix the Erland autoprovides/requires as well? 19:53:54 <skvidal> notting: maybe we could augment a bit with: if the number of provides you create is more than 2 orders of magnitude beyond the number of pkgs you create then you're doing it wrong 19:53:55 <notting> oof. that should be 'Per library function' 19:53:58 <nirik> Erlang. 19:54:01 <Kevin_Kofler> FWIW, I vote -1, IMHO it's the Erlang maintainers' decision what to do with their packages. 19:54:02 <Oxf13> Kevin_Kofler: sounds like they need to work more on the generator before turning it live. 19:54:22 <pjones> Kevin_Kofler: that'd be true if it didn't impact other things, but it does. 19:54:25 <Oxf13> Kevin_Kofler: by that argument, FESCo shoudln't exist at all. 19:54:38 <notting> Oxf13: that may be his next suggestion ;) 19:54:38 <Kevin_Kofler> That wouldn't necessarily be a bad thing. ;-) 19:54:40 <mjg59> Kevin_Kofler: When a maintainer's packages interfere with the rest of the distribution, it's a problem 19:54:45 <pjones> Oxf13: overgeneralizing a bit there ;) 19:54:49 <nirik> so, do we need to task someone with fixing this? or ask the maintainer to? 19:55:07 <skvidal> nirik: right now - there's nothing to fix 19:55:17 <skvidal> the pkgs in updates-testing only have a handful of provides/requires 19:55:20 <skvidal> so - it's FINE 19:55:29 <nirik> skvidal: the autoprov/autoreq generator still does the wrong thing. 19:55:32 <ajax> i sure do wish i could do req/prov filtering without breaking rpm color 19:55:34 <skvidal> but it doesn't RUN 19:55:34 <nirik> they just manually fixed the package. 19:55:38 <Kevin_Kofler> skvidal: Well, those are done manually and by disabling the dep generator. 19:55:49 <pjones> disabling it is a fine fix. 19:55:54 <notting> skvidal: so we might want to inform them to disable it/not ship it 19:55:54 <skvidal> nirik: if I disable a section of code b/c it doesn't work I've still fixed it 19:55:56 <dgilmore> +1 TO NOTTING 19:55:59 <dgilmore> gahh 19:56:00 <nirik> sure, we are fine now, until someone turns it on, or a new erlang package lands with it? 19:56:01 <skvidal> no problem informing them 19:56:12 <skvidal> nirik: which is true of EVERY pkg 19:56:15 <skvidal> not just erlang 19:56:16 <Kevin_Kofler> nirik: Right, so it shouldn't be there in the first place. 19:56:21 <skvidal> nirik: hey 19:56:31 <skvidal> nirik: how about a proposed rpmguard/autoqa test 19:56:33 <nirik> ok. If folks are happy with leaving it at that, then thats ok I guess. 19:56:39 <skvidal> if the number of provides is, say, more than 200 19:56:42 <skvidal> we throw a flag? 19:56:50 <nirik> skvidal: that sounds like a great idea. In fact I think there is one already... for changes in provides/requires. 19:56:54 <skvidal> I'll check 19:56:55 <Oxf13> Kevin_Kofler: so first, we should allow them to do whatever they want with the package, and now we should force them to remove the code instead of just turning it off? 19:57:16 <nirik> ok, shall we move on then? or anything further on this topic? 19:57:39 <nirik> #topic #374 Modify Cloture rule 19:57:39 <nirik> .fesco 374 19:57:40 <zodbot> nirik: #374 (Modify Cloture rule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/374 19:57:40 <Kevin_Kofler> skvidal: Um, kdebase-workspace has 199 Provides. 19:57:46 <Kevin_Kofler> And 30 in kdebase-workspace-libs. 19:57:51 <nirik> Kevin_Kofler: just under the line. ;) 19:57:52 <Kevin_Kofler> kdelibs has 150. 19:58:07 <nirik> anyhow, I got the idea for this from abadger1999. It would in fact have saved us time today... 19:58:15 <notting> Kevin_Kofler: but that's roughly one-per-shared-lib, no? 19:58:23 <Kevin_Kofler> nirik: 4.5 might push it over 200. :-) 19:58:24 <nirik> (well, if we had stopped sooner) 19:58:40 <mjg59> I'm happy enough with this proposal 19:58:43 <dgilmore> skvidal: i think a better chack is did the number of provides increase by more than 5 or 10 19:58:47 <dgilmore> check 19:58:47 <Kevin_Kofler> notting: Yeah, plus some mimehandler(foo) stuff. 19:58:50 <ajax> i'm now no longer sure how this rule counts as cloture at all, but the proposal sounds fine 19:58:56 <skvidal> dgilmore: well, you'd need to avoid the first import, obviously 19:59:00 <nirik> yeah, sorry... probibly doesn't. 19:59:07 <pjones> ajax: it wasn't ever cloture, but that's sortof beside the point 19:59:07 <skvidal> dgilmore: but 200 was just a random number - call it 300 or 500 19:59:44 <notting> i'm fine with this proposal. +1 19:59:56 <skvidal> +1, too 19:59:58 <ajax> +1 19:59:59 <pjones> I think this is worth being an optional thing - we vote continue/writeup/stop 19:59:59 <Kevin_Kofler> +1 to the changed cloture rule. 20:00:02 <dgilmore> im ok with it +1 20:00:16 <pjones> (but I'm basically okay with it as written) 20:00:19 <ajax> pjones: it does say "then ask" 20:00:22 <Kevin_Kofler> It makes sense to give people time to write things up rather than forcing a rushed decison. 20:00:24 <Kevin_Kofler> *decision 20:00:32 <pjones> ajax: it says "instead". 20:01:00 <nirik> #agreed proposal is accepted. 20:01:07 <cwickert> +1 20:01:08 <nirik> #action nirik will writeup change. 20:01:21 <nirik> #topic #375: Bundled library exception for Zikula 20:01:21 <nirik> .fesco 375 20:01:21 <Kevin_Kofler> Either things are important and so they should be discussed fully in the meeting, or they are not, then they can wait a week. 20:01:23 <zodbot> nirik: #375 (Bundled library exception for Zikula) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/375 20:01:29 <ajax> pjones: check notting and kevin's comments. 20:01:41 <pjones> ajax: ah, indeed. 20:01:44 <nirik> pjones: yeah, it should be if we decide not to keep going. 20:02:46 <Kevin_Kofler> +1 to this exception because 1. the library is modified and can't be built against as is and 2. this will be fixed very soon anyway (but the update needs to go out ASAP due to security fixes). 20:03:00 <nirik> I'm ok with this exception... but I would like to make sure we revisit it and make sure it goes away at some point. 20:03:18 <notting> given that upstream is 1) aware of the bundling and 2) working on using stock upstream ... i'm fine with letting them bundle it in this release 20:03:26 <ajax> yeah, fine with me too 20:03:29 <dgilmore> notting: same 20:03:31 <pjones> I think a temporary exception is fine 20:03:38 <dgilmore> as a temporary thing i think its ok 20:03:40 <Kevin_Kofler> I wonder whether they'll really use stock upstream or reinvent their own translation system. 20:03:44 <nirik> how can we properly track revisiting this ? 20:03:56 <pjones> Kevin_Kofler: hard to say, but let's not penalize them for their future actions. 20:03:59 <dgilmore> nirik: leave the ticket open 20:04:03 <cwickert> I think this is different from the wordpress case as upstream wants to fix it. +1 for a timely limited exception 20:04:06 <dgilmore> and revist until fixed 20:04:26 <nirik> dgilmore: yeah, might work. 20:04:59 <nirik> #agreed a temporary exception is granted. Will revisit and make sure 1.3.0 happens without the bundled lib. 20:05:10 <nirik> #topic #376 change provenpackager, sponsor acceptance procedure 20:05:10 <nirik> .fesco 376 20:05:11 <zodbot> nirik: #376 (change provenpackager, sponsor acceptance procedure) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/376 20:05:17 <nirik> notting: this was yours I think. 20:05:34 <notting> technically, it was kevin's original proposal. i modified it some and tossed it in trac 20:05:49 <nirik> ah, true. 20:06:19 <notting> the idea is that sponsors can manage provenpackager and/or sponsor more directly themselves, and objections are escalated to fesco 20:06:44 <nirik> notting: how would we track things? 20:07:17 <Oxf13> as the driving person behind provenpackager, I don't necessarily have a problem with this. 20:07:23 <nirik> at least it would require an admin in the packager group to make sure there were sufficent votes and no objections and changing the user. 20:07:25 <Oxf13> with the second version that is 20:07:28 <notting> we could use the same fesco tickets as a first step. 20:07:44 <nirik> just not make them meeting items unless there is an issue? 20:07:51 <notting> if someone in sponsors wants to make something different, more power to them. 20:07:53 <notting> nirik: yeah 20:08:12 <Kevin_Kofler> notting: Your changes are to make it harder to become provenpackager, as hard as sponsor. 20:08:30 <Kevin_Kofler> I don't see why it's needed to have more than just one sponsor approving somebody for provenpackager. 20:08:40 <notting> how so? the requirements are now 'a fesco vote' 20:08:45 <cwickert> Kevin_Kofler: I think a single +1 is not enough, no matter if proven packager or sponsor 20:08:50 <Kevin_Kofler> Harder compared to my original proposal. 20:08:56 <notting> oh, yes. 20:09:09 <nirik> I also don't think ignoring objections is a good idea. 20:09:49 <cwickert> who says they should be ignored? did I miss something? 20:09:50 <Kevin_Kofler> It'd reduce the number of FESCo votes compared to having one vote for each provenpackager application which is being objected to. 20:09:59 <nirik> cwickert: in Kevin_Kofler's orig proposal. 20:10:21 <nirik> " provenpackager should take 1 sponsor to approve and no possibility to object or veto" 20:10:22 <Kevin_Kofler> (In what I proposed on the ML, this would be only the case for sponsor applications, not provenpackager.) 20:10:32 <nirik> I think thats a bad idea. 20:10:50 <Kevin_Kofler> My proposal was: provenpackagers are sponsored like packagers, 1 sponsor approves and then it's done. 20:11:00 <nirik> I'm +1 to nottings proposal. 20:11:00 <notting> i don't think 3 acks is too much to ask for 20:11:05 <Kevin_Kofler> Sponsors take 3 sponsors and no objections or a FESCo vote. 20:11:19 <cwickert> nirik: ah, for proven packagers... this is a bad idea and I don't see a rationale to treat sponsor and +packager differently 20:11:26 <cwickert> so +1 to notting 20:11:47 <Kevin_Kofler> IIUC, notting's proposal is basically the same as mine for sponsors, but also to apply the same for provenpackagers. 20:11:54 * nirik nods. yep. 20:12:05 <nirik> further votes? comments? 20:12:20 <Kevin_Kofler> Well, I vote +1 for notting because it's a step in the right direction. 20:12:34 <Kevin_Kofler> Though IMHO still too weak and will lead to FESCo having to vote too often. 20:13:00 <ajax> +1 to notting's amended proposal 20:13:05 <Kevin_Kofler> (also because it's not a given that we'll get 3 ACKs for every provenpackager application) 20:13:13 <cwickert> we have 4 +1 atm 20:13:19 <Kevin_Kofler> Still, it's better than the current status quo where FESCo ALWAYS has to vote. 20:13:45 * skvidal reads backscroll 20:13:46 <skvidal> one moment 20:14:36 <skvidal> I can agree with this 20:14:36 <skvidal> +1 20:14:42 <nirik> #agreed nottings proposal is approved. 20:14:48 <mjg59> Yeah, I'm +1 20:15:03 <nirik> notting: you want to mail sponsors on the new procedure and update the wiki? or would you like me to do so? 20:15:43 * pjones +1 as well, for the record 20:16:20 <nirik> I suppose we need: wiki updated, sponsors notified, and a devel-announce to notify maintainers about the change. 20:16:27 <notting> if you're offering... :) 20:16:29 <ardchoille> nirik: I'm free and can update the wiki if someone tells what to add/remove to which page. 20:16:43 <nirik> ok, I can try and do so... 20:16:55 <nirik> ardchoille: thanks. Can I talk with you after the meeting or later today? 20:17:01 <ardchoille> Sure 20:17:19 <nirik> #action nirik will try and update wiki and sponsors and announce to devel-announce. 20:17:21 <dgilmore> +! for notting 20:17:24 <nirik> #topic Fedora Engineering Services tickets 20:17:30 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6 20:17:35 <nirik> mmcgrath: you have any updates? 20:17:53 * nirik notes mmcgrath is off on site, and probibly not available. 20:18:11 <nirik> more work on broken deps and cleaning up things. 20:18:29 <nirik> https://fedorahosted.org/fedora-engineering-services/ticket/24 20:18:42 <nirik> This is the ticket to do a 'most active bugs' roundup. 20:18:56 <nirik> Looks like the bugzilla XMLRPC can't handle this query. 20:19:09 <nirik> so, it's back to scraping a query, or just forgetting it. ;( 20:19:40 <nirik> if anyone has ideas on that, post them to the bug. 20:20:53 <nirik> Also, additional ideas on https://fedorahosted.org/fedora-engineering-services/ticket/17 would be welcome. 20:21:24 <nirik> This is the ticket to add support links to our desktops... I think it's going to need coordination with some package like fedora-release-notes, or be a seperate fedora-support-links or something. 20:21:47 <nirik> anyhow, ideas, new tickets, etc welcome. 20:21:54 <nirik> #topic Open Floor 20:22:02 <Kevin_Kofler> The support links idea has come up quite often. 20:22:14 <Kevin_Kofler> One problem is that #fedora requires registration. :-/ 20:22:15 <nirik> I have one item for open floor: I will not be around next week. If someone would step up to run the meeting, that would be great. ;) 20:22:25 <Kevin_Kofler> This sucks for being able to provide a quick IRC support link. 20:22:28 <Oxf13> it's just needed time and code to complete it 20:22:29 <nirik> Kevin_Kofler: yeah, of course so does the forum or mailing list to post. 20:22:46 <Kevin_Kofler> They had it turned off at some point, then it got enabled again due to the spam attack and then it got left on. 20:22:51 * notting was noticing complaints about #fedora via the interwebs yesterday 20:22:59 <Kevin_Kofler> nirik: But a forum has obvious registration links. 20:23:04 <nirik> yeah, we decided to leave it on... 20:23:07 <Kevin_Kofler> On IRC registration is very much non-obvious. 20:23:15 <nirik> notting: oh? do tell... here or in private. 20:23:15 <Kevin_Kofler> IMHO registration should not be required on #fedora. 20:23:26 <Kevin_Kofler> #fedora-kde doesn't require registration and it's not a problem at all. 20:23:29 <Oxf13> Kevin_Kofler: those that run #fedora really have the say on that. 20:23:45 <Oxf13> the #fedora-* channels are far less of a target than #fedora itself. 20:23:48 <nirik> Kevin_Kofler: it redirects you to #fedora-unregistered. A entry message, bot and topic all show you how to register. Also, some people stay active there and help people who can't register. 20:24:12 <nirik> it has VASTLY cut down on drive by junk. 20:24:34 <nirik> when people see they have to register to join they are less tempted to troll. 20:25:28 <Kevin_Kofler> The registration requirements for MLs are also a PITA, FWIW, IMHO there ought to be a better way to filter spam than this whitelisting system. :-/ 20:25:32 <nirik> anyhow, for anyone who would like it to change, come to the irc-support-sig meeting thursday mornings in this very channel to provide your view. ;) 20:26:03 <nirik> anyone willing to run the meeting next week, let me know. Any other open floor items? 20:26:31 <skvidal> i do not think I can do it next week 20:26:43 <skvidal> I may not be able to make the meeting due to drs appt 20:27:19 <notting> looks like i can 20:27:43 <nirik> notting: thanks very much. There's a slight chance I might be back in time, but I don't think I will. 20:28:06 <nirik> ok, will close out the meeting in a minute if nothing else comes up. 20:28:12 <nirik> oh. 20:28:33 <nirik> #info everyone should read https://fedoraproject.org/wiki/F14_elections_questionnaire and attend town halls, and VOTE. 20:29:08 <nirik> #endmeeting
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
