= 2006 August 31 FESCo = Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings == Attending == * c4chris * scop * thl * rdieter * bpepple * abadger1999 * dgilmore * tibbs * warren * jwb == Summary == === Mass Rebuild === * Seems to be going okay other than the buildsystem being down for maintenance. === Comps.xml === * SIG is getting organized. * Remove the non-.ini files from the comps module in CVS which would remove a source of confusion. c4chris will ask jeremy about doing this. * Discussion of comps location to take place in the package review. Will go before the package committee. * Comps SIG would have the final say. * Automated regenerating the comps file hasn't been worked on yet but is on the todo list. === Packaging Committee === * No decisions today. === Sponsorship Nominations === * Patrice Dumas was suggested at last week's meeting but was not discussed on the lists. Will be discussed this week. === KMods === * Still waiting for guidance from FPB. === Misc -- Enhance AWOL === * Want to efficiently orphan and reallocate all a maintainers packages if they are AWOL. * Want to avoid doing this if the maintainer is just ignoring one package (although they should orphan that package if so.) * tibbs will talk to mjk about enhancing the policy to take these into account. === Coverity's Offer to Scan Packages for Vulnerabilities === * 1) "Do we want this at all?" was voted yes. * 2) "How to implement?" seemed to favor Warren's plan. * c4chris to let Max know what we decided. === MISC -- Creating RHEL (and other vendor) Branches in CVS === * https://extras.108.redhat.com/servlets/BrowseList?listName=discuss&count=43 * Infrastructure sharing is good. * Several FESCo members want RHEL branches for their packages. * Want to make sure the current maintainers aren't required to maintain the RHEL branches. * Need to talk with z00dax and centos Extras people about what they think. * RHELX branch would be like the FCX branches we currently have. * "Packages should not branch for RHEL automatically; it would have to be an on-request thing. And many packages wouldn't ever branch there." was generally agreed upon. * RHEL Extras won't be the responsibility of FESCo or Fedora Legacy. * But they shuld follow the same Packaging Guidelines and policies. * thl will arrange an IRC meeting with quaid, z00dax and other interested parties. === MISC -- PackageDB === * c4chris, dgilmore, warren, and abadger1999 are working on this. * Plans are on http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase * Separate meeting took place. IRC Log is: http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/Meeting20060831 === "If there's something to be fixed and someone wants to fix it, then fix it" === * Ties in with comaintainership and Maintainer Responsibilities as well. * Want to give people who know what they're doing leeway to make fixes. * Want to prevent people who don't know what they're doing from causing problems for others. * Approved something along the lines of "Sponsors can change other people's packages if there is a good reason"; thl to write it up. === Free Discussion === * Openmotif is being removed from Core. * Motif consuming packages largely work with lesstif. * Licensing in Extras is worrisome from the perspective of many licenses look like other OSI licenses but haven't explicitly been approved by OSI or FSF. These may all need to be submitted. * FE-LEGAL and other legal inquiries seem stalled. == Log == {{{ (09:58:54) c4chris__ is now known as c4chris (09:59:34) scop [n=scop] entered the room. (10:01:12) thl has changed the topic to: FESCo meeting in progress -- init (10:01:18) thl: hi everybody! (10:01:26) thl: who's around? (10:01:26) bpepple: hey. (10:01:29) abadger1999: Greetings (10:01:31) ***dgilmore is here (10:01:35) ***bpepple is here. (10:01:36) tibbs: Howdy. (10:01:42) ***rdieter is here (10:02:15) thl has changed the topic to: FESCo meeting in progress -- M{ae}ss-Rebuild (10:02:34) thl: well, seems to work mostly afaics (10:02:46) thl: hopefully cvs is up again soon (10:03:00) thl: scop, do you have any report or do we need to discuss anything? (10:03:19) scop: not really, I think it's proceeding ok (10:03:19) ***c4chris is here (10:03:37) thl: k, so let's leave it on the schedule and move on (10:03:47) rdieter: thl: cvs worked for me ~45 minutes ago. (10:03:55) thl has changed the topic to: FESCo meeting in progress -- Use comps.xml properly (10:04:01) thl: rdieter, ohh, nice :) (10:04:14) thl: c4chris, any news? (10:04:21) c4chris: seems teh comps thing is proceeding (10:04:36) abadger1999: cvs is still up and down, though. (10:04:43) c4chris: need to get a bit more organized in the SIG (10:04:53) thl: c4chris, k (10:04:55) thl: dgilmore: automate comps file during push or via cron? (10:05:02) c4chris: but I think we are doing ok up to now (10:05:13) dgilmore: thl: nothings been done on it yet (10:05:42) c4chris: someone asked if we could remoce the non .in files from CVS (10:05:46) thl: dgilmore, k, any rough ETA? (10:05:50) c4chris: remove, too (10:06:00) tibbs: An idea: should discussion of the comps location be part of the package review? (10:06:07) c4chris: would avoid confusion by users... (10:06:12) thl: c4chris, would probably be a good idea to remove them ;-) (10:06:12) dgilmore: thl: a week or so as soon as i get the time (10:06:23) thl: dgilmore, k (10:06:24) scop: remove++ (10:06:35) rdieter: tibbs++, discussing comps during review would be a plus. (10:06:36) ***nirik thinks tibbs has a good idea there... (10:06:40) c4chris: dgilmore, what do you say ? Can we rm them ? (10:06:57) dgilmore: c4chris: jeremy would know best (10:07:07) c4chris: k, I'll try to ping him (10:07:22) c4chris: tibbs, good idea (10:07:38) thl: tibbs, yeah, good iea, but the comps SIG should have the last word normally (10:08:08) tibbs: Maybe we could get the bugzilla template updated to include the proposed location(s). (10:08:25) thl: tibbs, but this topic probably should be handled by the packaging committee (10:08:28) tibbs: Since there's no place in the srpm or spec where this information can live. (10:08:34) finalzone: speaking about cvs, I still got time out >_< (10:08:56) thl: tibbs, yeah, why not (10:09:04) c4chris: tibbs, willing to poke teh PM staff ? (10:09:04) tibbs: thl: I'm happy to take it to the committee if folks think it's a good idea. (10:09:19) c4chris: tibbs, yup (10:09:24) thl: tibbs, "take it to the committee" +1 (10:09:24) tibbs: c4chris: not sure what "PM" means. (10:09:53) c4chris: PM = almost packaging committee ... doh, sorry (10:10:16) tibbs: thl says +1, therefore it shall be done. (10:10:22) ***thl hides (10:10:31) thl: k, anything else regarding this topic? (10:10:36) thl: otherwise I'll move on (10:10:45) ***scop still doesn't see why everyone should be involved with comps stuff (10:11:10) scop: but nevermind (10:11:20) thl: scop, everyone = all contributors? (10:11:21) c4chris: don't *need* to, but are offered a say in the matter (10:12:08) thl: scop, you probably have a point there; maybe the task of adding pacakges to the comps-files should be handled by the sig (10:12:20) scop: thl, exactly (10:12:21) thl: but that's probably a boing job (10:12:29) scop: interested in it? join the sig. (10:12:42) thl: boring (10:12:53) c4chris: scop, WORKSFORME (10:12:53) thl: scop, well, let's proceed with the current scheme for now (10:13:08) thl: and revisit this idea after FC6 (10:13:31) c4chris: k (10:13:42) thl: c4chris, do you really want to handle it? (10:14:01) c4chris: thl, that's fine with me (but I'll need help) (10:14:01) thl: most packages are probably in by now? (10:14:21) ***c4chris needs to update the status page... (10:14:39) thl: c4chris, well, maybe we can bring these ideas together: (10:14:39) ***nirik has slacked and not added his yet. ;( (10:14:50) bpepple: c4chris: I'll be able to help you. (10:14:59) c4chris: bpepple, thanks :-) (10:15:19) scop: by the way, perhaps the usability sig would have some kind of interest towards having useful comps too? (10:15:20) c4chris: nirik, bad... no cooky (10:15:26) thl: the packager suggests a group during review and the SIG checks if that's the proper one and updates the comps-file? (10:15:31) thl: c4chris, how about that? (10:15:45) c4chris: thl, WORKSFORME (10:15:49) bpepple: sounds good. (10:15:51) thl: other opinions? (10:16:28) tibbs: Seems fine, but that means they'll need to watch a bunch of bugzilla traffic. (10:16:35) scop: well, that's basically back to "everyone's involved", but *shrug* (10:16:55) nirik: or watch owners.list and add when you see one get added there? (10:17:05) thl: scop, then let's make it a "packagers should suggest ..." (10:17:05) c4chris: s/packager suggests/packager may suggest/ ? (10:17:13) thl: :) (10:17:15) scop: c4chris++ (10:17:21) c4chris: scop, k (10:17:42) thl: anything else? (10:17:51) thl has changed the topic to: FESCo meeting in progress -- Activate legacy in buildroots (10:17:55) thl: dgilmore ? (10:18:25) dgilmore: thl: i havent had a chance to setup legacy for the buildsys. ill have time this weekend (10:18:31) thl: dgilmore, k, thx (10:18:40) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report (10:18:48) thl: scop, spot, tibbs, abadger1999 ? (10:19:18) rdieter: don't think we decided anything today. ): (10:19:31) thl: btw, I noticed this "fc.6.89/6.90" stuff (10:19:49) tibbs: Yes, it was voted down, but it was close to passing. (10:19:49) rdieter: ah, that, yes. (10:20:06) thl: that would mean that we would have to rebuild everything for each beta? (10:20:21) scop: no (10:20:41) thl: I didn't follow the discussion closely (10:20:49) tibbs: It would have passed on to FESCo to implement or not, but it didn't make it out of committee. (10:21:09) thl: wthen let's stop wasting time on it (10:21:23) thl has changed the topic to: FESCo meeting in progress -- Sponsorship nominations (10:21:32) thl: there was one nomintation last week iirc (10:21:42) thl: but it wasn#t discussed on the list iirc (10:22:11) rdieter: who? (10:22:12) tibbs: I thought I took it to the list. I must have never sent the message. (I keep doing that.) (10:22:16) thl: "Patrice Dumas" (10:22:17) ***c4chris is still catching up on a few things... (10:22:52) tibbs: Patrice is the unsponsored reviewer with the most reviews. (10:23:06) BobJensen-Away is now known as BobJensen (10:23:08) tibbs: Sorry, s/unsponsored/non-sponsor/ (10:23:23) thl: tibbs, yeah, I think he's fine, but let's discuss it on the list first and get back to it next week please (10:23:24) Foolish left the room (quit: Connection timed out). (10:23:32) bpepple: thl: +1 (10:23:32) rdieter: afaik, +1, he's really stepped up to the plate in this whole *motif thing. (10:23:33) thl: any other nominations? (10:23:48) tibbs: This was the criterion used to select Orion, which is why I brought up Patrice. (10:24:02) ***nirik is just rabble, but he's been very helpfull testing Xfce beta packages and does good reviews. ;) (10:24:16) finalzone left the room. (10:24:42) Foolish [n=foolish] entered the room. (10:24:54) c4chris: thl, fine (10:24:58) thl: nirik, on-topic comments like that from the rabble are always appreciated (10:25:10) thl: k, so no new nominations afaics (10:25:10) jwb_gone: +1 from me (10:25:29) thl has changed the topic to: FESCo meeting in progress -- approve kmod's (10:25:35) jwb_gone is now known as jwb (10:25:44) thl: warren, rdieter, any sign when the board will discuss this further? (10:26:01) rdieter: at the next meeting (next Tue I believe) (10:26:11) jwb: is the board a monthly meeting? (10:26:13) thl: rdieter, k, thx (10:26:24) abadger1999: twice monthly I think. (10:26:29) jwb: k (10:26:35) rdieter: http://fedoraproject.org/wiki/Board/Meetings (10:26:39) thl has changed the topic to: FESCo meeting in progress -- MISC -- enhance AWOL? [WWW] https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00567.html (10:27:03) thl: who wrote the current AWOL stuff? (10:27:18) thl: we really should enhance it like sligtly as suggested in that mail (10:27:28) jwb: yeah (10:27:33) tibbs: mjk-, I believe, wrote the AWOL policy. (10:27:47) jwb: however, we have to be slightly careful (10:28:06) jwb: a single package may be AWOL, but the maintainer is still active (10:28:23) jwb: in that case, the maintainer should orphan it (10:28:49) jwb: if they don't... we don't want interpretation of the AWOL policy to really orphan all their packages (10:29:41) c4chris: jwb, agreed (10:29:45) thl: jwb, well, the maintainer should at least respond in bugs even if he isn't interested in a particular package any more (10:29:50) thl: otherwise agreed (10:30:09) jwb: thl, yes they should. but i can see that not happening (10:31:05) rdieter: let's just stick to a per-package awol policy then (for now). (10:31:06) thl: wanyone interested in wkring out a "patch" for the current AWOL policy that realizes the things we are doing about (10:31:22) thl: or shall we ask mjk for help? (10:31:53) tibbs: I think the policy is fine as is; it might just need a note that indicates that after one package has made it through the policy, the committee can become involved to deal with the other packages. (10:31:53) thl: rdieter, yes, for now, but we should work out something better (but that's not urgent) (10:32:11) bpepple: tibbs: agreed. (10:32:30) c4chris: tibbs, sounds fine (10:32:48) nim-nim [n=nim-nim] entered the room. (10:33:00) tibbs: Shall I try to talk to mjk and propose a patch to the list? Or next week? (10:33:01) thl: okay, but that needs to be integrated in the AWOL policy as well (10:33:16) thl: tibbs, talk to mjk please (10:33:26) thl: and a patch to the public list would be the best (10:33:27) c4chris: tibbs, can you propose a patch to the list ? (10:34:00) tibbs: Yep. (10:34:05) thl: tibbs, tia (10:34:18) thl has changed the topic to: FESCo meeting in progress -- MISC -- coverity's offer to scan FE packages [WWW] https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00815.html (10:34:32) finalzone [n=luya] entered the room. (10:34:33) thl: sorry, I didn't find time to reply to the list is time (10:34:41) tibbs: We really need details of just how they plan to do this. (10:34:51) jwb: tibbs, that's what they're asking us for (10:35:02) c4chris: jwb, +1 (10:35:08) jwb: tibbs, 1) whether we want this at all, and 2) how we're going to do it if we're interested (10:35:19) bpepple: Sounds like a good thing. (10:35:23) rdieter: 1) +1, yes (10:35:25) tibbs: They want us to tell them how they're going to do it? (10:35:41) nirik: another rabble comment: Warren's idea that they just use publicly available src.rpms to do it sounds the the best path to me. (10:35:43) rdieter: I don't think any implementation details have been mentioned at all yet. (10:35:46) abadger1999: 1) +1 (10:35:50) c4chris: tibbs, no they first want to know if we are interested. (10:35:56) jwb: 1) +1 (10:35:58) bpepple: 1) +1 (10:36:08) scop: 1) +1 (10:36:14) abadger1999: 2) I'm even okay with running it on our buildsys. (10:36:15) thl: 1) +0.75 (10:36:24) jwb: heh (10:36:30) c4chris: 1) +1 (10:36:37) tibbs: Interested +1. I mean, why wouldn't you be interested? (10:36:38) warren: I'm in favor of Warren's idea too. (10:36:46) abadger1999: warren: :-) (10:36:47) jwb: lol (10:36:49) c4chris: warren, :-) (10:36:53) jwb: warren, i like your 2nd iteration (10:37:18) devrimgunduz [n=Devrim] entered the room. (10:37:23) thl: okay, so we need someone that looks closer at the whole idea (10:37:25) tibbs: Do they check any other distros in this manner? (10:37:32) thl: any volunteers? (10:37:47) xris [n=xris] entered the room. (10:38:06) thl: warren, or can you handle that for both core and extras? (10:38:12) jwb: would be good to have someone with access to the infrastructure (10:38:16) warren: If it is implemented as I recommended, it doesn't require any access to buildsys at all. (10:38:35) c4chris: warren, sure, but it'll need to run *somewhere*... (10:38:40) warren: thl, our people had the idea of seeing how well it goes for Extras before Core, not sure why. (10:38:48) thl: warren, we probably should know first what Coverity expects from us (10:38:54) ***c4chris can back to Max (10:39:05) warren: yeah, best we talk with Max (10:39:20) c4chris: thl, yes (10:39:56) thl: so, let's agree for now that we like the idea in general and that we'll investigate further (10:40:07) c4chris: thl, k. (10:40:18) c4chris: shall I take that msg to Max? (10:40:24) thl: c4chris, yes please (10:40:33) c4chris: thl, k, will do (10:40:36) thl: tia (10:40:53) thl has changed the topic to: FESCo meeting in progress -- MISC -- acceptability of creating RHEL (and maybe other vendor) branches in extras CVS [WWW] https://extras.108.redhat.com/servlets/BrowseList?listName=discuss&count=43 (10:41:09) thl: another topic where I did not find time to reply to :-/ (10:41:09) c4chris: ah, the 108 stuff (10:41:37) c4chris: opinions ? (10:41:41) tibbs: I don't see what it would hurt, but then I don't think it should be allowed to add to the maintainer burden if they don't want it. (10:41:44) thl: I think we need to agree on a general direction here, too (10:41:48) abadger1999: I am for infrastructure being shared. (10:41:49) warren: Are the centos people currently doing Extras willing to cooperate? (10:41:56) warren: and centralize on our infrastructure (10:42:05) abadger1999: I'm not for increasing maintainer workload. (10:42:07) thl: infrastructure being shared +1 (10:42:23) ***c4chris would like the possibility to request RHEL branches for my packages... (10:42:30) bpepple: infrastructure being shared +1 (10:42:42) f13: how would this fit into the release EOL policy? (10:42:45) thl: abadger1999, yeah, we really need proper co-maintainership when in a longer term for this stuff (10:42:47) abadger1999: warren: mmcgrath and z00dax know more about centos. (10:42:51) c4chris: infrastructure being shared +1 (10:42:54) thl: f13, good question (10:43:05) rdieter: +1 RHEL branches/infrastructure (10:43:07) f13: a release (say FC3) will be EOL long before the the RHEL release would. (10:43:09) thl: f13, we need to talk to z00dax and other centos guys about it (10:43:21) f13: thl: would these be completely different branches then? (10:43:33) warren: if a longer term RHEL plan is made, this is doable (10:43:35) thl: f13, I think there should be completely different branches (10:43:37) ***nirik suggests that bringing up the topic on maintainers or extras list would be better than 108... (10:43:49) tibbs: Is our buildsys capable of handling builds for two extra branches? (10:43:49) c4chris: f13, different, yes (10:43:50) jwb: +1 on infrastructer (10:44:09) thl: nirik, let's agree on the general direction first (10:44:09) warren: tibbs, easily enough (10:44:20) jwb: wait... why branch?? (10:44:22) thl: otherwise it's be a long discussion without results :-/ (10:44:32) thl: s/it's/it'll/ (10:44:43) jwb: what's wrong with a RHEL5 "branch" like a "FC5" branch? (10:44:43) c4chris: jwb, --verbose ? (10:44:45) nirik: thl: agreed. I can't read the 108 proposal tho... since I don't have an account there. ;) (10:44:57) ***mmcgrath is here if needed. (10:44:58) thl: jwb, there might be small differences (10:45:01) tibbs: jwb: I think pepole say "branch" when they mean another directory like FC-5, devel, RHEL-5. (10:45:03) f13: jwb: because you most likely need to build in the RHEL environment, not the FC env, and it needs to be clear that the FC branch is EOL, while the RHEL branch could be going strong. (10:45:08) thl: jwb, and one might want to build a pacakge for FC5 (10:45:11) c4chris: jwb, I thinks that's what we want (10:45:11) thl: see if it works (10:45:19) thl: and release it for RHEL5 much later (10:45:40) abadger1999: mmcgrath: Just wondering if z00dax and the centos people like the idea of doing RHEL Extras within Fedora Extras infrastructure. (10:45:42) c4chris: tibbs, yes (10:45:44) jwb: for what it's worth, i know this already works (10:45:54) jwb: we have a plauge server setup with RHEL dirs internally (10:45:57) tibbs: Packages should not branch for RHEL automatically; it would have to be an on-request thing. And many packages wouldn't ever branch there. (10:46:12) rdieter: tibbs++ (10:46:13) tibbs: I'd happily branch denyhosts, but not something like a game. (10:46:18) jwb: tibbs++ (10:46:26) thl: tibbs +1 (10:46:28) ***f13 doesn't even want to begin to touch the subject of lifespan expectancy of RHEL branches, security issues, and stability issues. (10:46:38) bpepple: tibbs: +1 (10:46:38) c4chris: tibbs, +1 (10:46:47) abadger1999: tibbs: +1 (10:47:24) mmcgrath: abadger1999: I think in general they want extras but they find the current extras policies/rules to be inhibitive. (10:47:40) mmcgrath: And I can appreciate that, it isn't super easy to get stuff into extras. (10:47:53) tibbs: Folks using RHEL-Extras packages shouldn't get the impression that they're getting more than usual Extras stability guarantees. (10:48:06) thl: maybe we should have special IRC meeting to discuss this topic in detail (10:48:24) thl: e.g. with z00dax, quaid and others (10:48:26) abadger1999: Ah. So one question would be would the packaging guidelines for RHEL Extras be the same as for Fedora Extras. (10:48:28) dgilmore: f13: we would need to add a yum package for RHEL and have access to binaries and we could build extras for RHEL in the extras buildsys (10:48:53) rdieter: mmcgrath: It shouldn't ever be "super easy". Reviews and Packaging Guidelines are important! (10:48:58) c4chris: thl, or on f-e-l ? (10:49:04) bpepple: rdieter: +1 (10:49:23) c4chris: rdieter, +1 (10:49:31) thl: c4chris, I'd prefer IRC (10:49:47) c4chris: thl, k (10:50:00) c4chris: then we need to arrange for such a meeting (10:50:11) thl: c4chris, I'll handle that (10:50:19) c4chris: thl, k, thanks (10:50:35) warren: RHEL Extras should not be the responsibility of FESCo or Legacy. (10:50:58) bpepple: warren: agreed. (10:50:59) warren: a separate team (probably comprising similar members but also centos) should be responsible for it. (10:51:04) abadger1999: warren: +1 (10:51:08) c4chris: warren, +1 (10:51:12) rdieter: warren: agreed (10:51:13) thl: warren, well yes, but it should be close to FESCo (10:51:18) warren: of course (10:51:21) thl: and Extras (10:51:33) tibbs: warren: I'm not sure about that. The policies can't differ or there will be pain. (10:51:39) thl: we probabl need an EESCo ;-) (10:51:50) warren: It would be a sub-set of Extras, just with a different team responsible for what is allowed in and long term maintenance. (10:51:56) c4chris: RESCo ? (10:52:04) thl: c4chris, :-)) (10:52:18) thl: k, so let's move on (10:52:32) thl: abadger1999, Future FESCo elections sill on the schedule (10:52:36) thl: abadger1999, can it be removed? (10:52:36) abadger1999: tibbs: There's FESCo policy and Packaging Policy... Will differences in FESCo/RHEL-E be problematic. (10:52:41) abadger1999: thl: Yes. (10:52:55) thl: abadger1999, I'll do that (10:53:01) mmcgrath: rdieter: I'd agree but, for example - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180092 (10:53:04) abadger1999: thl: Sorry. Yes. Thank you. (10:53:09) thl: abadger1999, np (10:53:35) abadger1999: Err.. Will differences in FESCo/RHEL-E _policy_ (as opposed to Packaging Policy) be problematic (10:53:36) thl: k, Package Database and Comaintainership are also on the schedule (10:53:45) dgilmore: policies should be the same what is needed is co-maintainers for RHEL branches (10:53:53) thl: does anyone want to discuss one of those two= (10:53:54) thl: ? (10:53:57) rdieter: mmcgrath: your point being? (10:54:11) thl: ohh, and there is also "If there's something to be fixed and someone wants to fix it, then fix, it. " (10:54:14) abadger1999: thl: I started looking into the Package Database this week. (10:54:27) bpepple: dgilmore: +1 (10:54:39) jwb: thl, that needs tiered VCS acls (10:54:53) mmcgrath: rdieter: It was submitted in Feb. Its not very encouraging for those that aren't involved in the process especially if they have the means to create their own like at centos.karan.org (10:54:54) thl has changed the topic to: FESCo meeting in progress -- Package Database (10:55:04) abadger1999: Elliot's schema seems a little too complex but I'm still staring at it to figure out if I'm being too simplistic. (10:55:06) dgilmore: thl: co-maintaners and package database are closely tied together (10:55:13) thl: dgilmore, sure (10:55:33) abadger1999: jwb: We can implement policy and it just might not be easily enforcable without tiered ACLs. (10:55:40) thl: dgilmore, but we need to break up comaintainer into smaller parts to get it done in the long term (10:55:46) jwb: abadger1999, true (10:56:04) devrimgunduz left the room (quit: "Leaving"). (10:56:18) dgilmore: thl: yeah there is a few different paths for co-maintainership (10:56:35) abadger1999: I've been posting my ideas with both Package Database and VCS to the infrastructure list. Is f-e-l a better venue? (10:56:42) dgilmore: and if we had sya rHEL support different upgrade paths (10:57:13) c4chris: abadger1999, both are fine for me (10:57:14) jwb: how high is the traffic on that list? (10:57:28) c4chris: jwb, pretty low (10:57:38) jwb: as in < 10 mails per day? (10:57:40) rdieter: mmcgrath: reviews are *hard* sometimes, and take time. (And not all reviewers are created equal). (10:57:49) c4chris: jwb, yup, mostly (10:58:02) jwb: c4chris, ok thanks. sounds like yaml time for me (10:58:37) thl: c4chris, warren, abadger1999 -- seem you three are interested most in the package database (10:58:47) c4chris: thl, yup (10:58:47) abadger1999: And dgilmore, yes. (10:58:51) thl: can you work out the details in a private IRC meeting? (10:59:03) thl: and we only say "heh, good qork, make it so"? (10:59:17) thl: s/qork/work/ (10:59:20) c4chris: thl, for the time being, I think the infrastructure list is fine (10:59:25) tibbs: mmcgrath: Start the stalled review process on that bug and get a new reviewer. (10:59:32) thl: c4chris, agreed (11:00:07) abadger1999: thl: Pretty much more explanation on http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase (11:00:15) abadger1999: would be nice for some things though. (11:00:39) thl: abadger1999, I'll try to take a look ; please poke me if you don't get feedback from me (11:00:40) abadger1999: And additions if you think of something else as well :-) (11:00:59) c4chris: abadger1999, we can setup a meeting if you like (11:01:00) thl: k, so let's move on (11:01:06) ***thl waits (11:01:14) thl: meeting +1 (11:01:34) abadger1999: c4chris: Sounds good. Arrange it after FESCo or do you have to run? (11:01:57) c4chris: abadger1999, should be ok (11:01:58) dgilmore: thl: the package dB is on my list of things to do for inrastructure (11:02:17) c4chris: if not, I plan to attend the infra meeting later tonight (11:02:27) abadger1999: I'll be there too. (11:02:27) thl: dgilmore, okay, then we have four people interested in this topic -- that should hopefully speed things up ;-) (11:02:46) c4chris: abadger1999, ok, let's talk then (11:02:56) thl has changed the topic to: FESCo meeting in progress -- If there's something to be fixed and someone wants to fix it, then fix, it. (11:03:10) thl: the discussion on the list worked nicely (11:03:19) thl: but we need to work out a proper proposal (11:03:23) thl: any volunteers? (11:03:31) dgilmore: thl: just need to make sure people are careful (11:04:13) tibbs: My plate is a bit full. (11:04:20) thl: dgilmore, well, that's why I wanted to allow the "slightly wiki-style approach" only for sponsors (11:04:28) ***rdieter is tempted too, but also has an overflowing plate as-is (11:04:28) thl: those should know what they are doing (11:04:31) jwb: i think co-maintainership needs to be worked out first to really work (11:04:41) bpepple: jwb: +1 (11:04:45) thl: jwb, really? why? (11:04:55) c4chris: jwb, yes, that might make things a lot easier to define (11:05:05) tibbs: We have to acknowledge that we can implement policy without implementing the actual access controls. (11:05:16) jwb: thl, to make sure that everything lines up with everything else (11:05:31) thl: jwb, yes, but it can work without it for now (11:05:33) rdieter: co-maintainership can be related, but we need not block on that. (11:05:40) thl: look at the pacakge that was fixed by tibbs (11:05:50) thl: I liked that (11:05:51) jwb: maybe not block on it, but at least keep it in mind (11:05:55) thl: jwb, sure (11:05:57) tibbs: In any case, even CVS actually supports the proper access control mechanisms. (11:06:13) tibbs: thl: Looks like I need to fix syck again because rawhide PHP changed last night. Joy. (11:06:17) jwb: tibbs, it does. but not in a very user friendly way :) (11:06:45) thl: we really need "proper access control mechanisms" (11:06:53) thl: but it works without them for now (11:07:01) tibbs: jwb: All of the ACLs would be generated anyway. (11:07:37) tibbs: But of course, when you talk about generating ACLs, then you start wanting a package database. (11:07:44) jwb: it would also help to have proper roles for maintainers and sponsors defined (11:07:53) tibbs: If we tie everything together, we'll wait forever before implementing anything. (11:08:03) jwb: yeah (11:08:05) abadger1999: Something helpful for VCS ACLs would be to come up with a list of groups which have more global rights. (11:08:15) c4chris: maybe wait a bit for our plates to empty a bit... (11:08:17) tibbs: jwb: That's the MaintainerResponsibilities document, which I predict will require massive flaming to finalize. (11:08:23) abadger1999: tibbs: I'd like to see the whole thing designed if possible. (11:08:31) abadger1999: tibbs: And then implement pieces at a time. (11:08:43) jwb: tibbs, i know (11:08:45) tibbs: abadger1999: I don't see the point to that. (11:08:56) abadger1999: tibbs: Understanding how the whole framework is going to look in the end helps make better choices. (11:09:03) bpepple: tibbs: I would like to see that finalized before implementing co-maintainers. (11:09:25) abadger1999: (Although it doesn't have to be a full design.. Mostly the how does Pkgdb tie into accts and vcs. (11:09:25) tibbs: So we do nothing, because we need to wait for everything to finalize before doing anything. (11:09:29) abadger1999: The interconnections. (11:09:54) finalzone: anyone got their cvs working? I can't get it online because of timeout (11:10:03) abadger1999: tibbs: I'm working on it now so things aren't waiting. (11:10:13) tibbs: I could care less about that. The point is that we need to say "sponsors can change other peoples' packages if they need to". How we enforce that isn't up to FESCo. (11:10:57) thl: just saying "sponsors can change other peoples' packages if there is a god reason for it" would be a start (11:10:58) dgilmore: tibbs: +1 thats infrastructres job (11:11:05) tibbs: If someday a mechanism appears that allows VCS-level enforcement, great. (11:11:08) abadger1999: tibbs: Okay. Sorry I'm on the same page with you now :-) (11:11:11) thl: enforcing it really is not that important (11:11:13) tibbs: Otherwise, we use harsh language. (11:11:16) jwb: yeah (11:11:18) thl: tibbs, +1 (11:11:23) c4chris: tibbs, +1 (11:11:27) abadger1999: tibbs: +1 (11:11:34) rdieter: tibbs +1 (11:11:43) jwb: +! (11:11:57) c4chris: (capslock ?) (11:12:01) jwb: fat fingers (11:12:03) jwb: +1 (11:12:09) c4chris: :-) (11:12:11) thl: k (11:12:13) tibbs: OK, so we're back to who writes it up. (11:12:20) thl: tibbs, I'll do that (11:12:30) thl: and please poke me if I forget it (11:12:37) tibbs: (and there was much rejoicing) (11:12:43) c4chris: yay (11:12:49) thl has changed the topic to: FESCo meeting in progress -- free discussion (11:12:55) thl: anything else we should discuss? (11:13:01) rdieter: fyi folks (if you hadn't seen it yet), I recently announced http://fedoraproject.org/wiki/RexDieter/openmotif (11:13:24) jwb: thanks rdieter (11:13:25) tibbs: The whole Motif thing sucks, but we'll be better off in the long run. (11:13:41) tibbs: What we should be worring about is the upcoming Extras license review. (11:13:44) thl: yeah, thx rdieter (11:13:52) jwb: tibbs, worried? (11:13:56) rdieter: tibbs: maybe that's what I should have said on the wiki page. :) (11:14:05) tibbs: Some of the discussion I've read might indicate that I've been a bit cavalier with licensing. (11:14:16) dgilmore: tibbs: we could be procative about it (11:14:21) tibbs: It seems that they want the actual license text to be approved by FSF or OSI. (11:14:36) dgilmore: distributable packages will have the biggest scrutiny (11:15:09) tibbs: I've looked at licenses and guaged them against the open source definition, but it's looking now like we should have passed those licenses through for explicit approval. (11:15:17) tibbs: That's kind of scary. (11:15:40) rdieter: tibbs: at least things need to be verifiably compatible with FSF or OSI (and currently the criteria is to simply let them verify it) (11:15:59) jima: that is scary. (11:16:03) dgilmore: I think we will need to have OSI or FSF review everything under a distrubutable license (11:16:08) rdieter: them = FSF/OSI (11:16:19) scop: while on the subject of legal things, I'm worried about legal inquiries being practically a blackhole at the moment (11:16:21) tibbs: But not all licenses say "distributable". (11:16:29) rdieter: scop++ (11:16:34) abadger1999: dgilmore: But what about things that are "BSD" (11:16:48) warren: scop, what are unresolved issues? (11:16:49) scop: rdieter, could you try to push it to the board agenda? (11:16:53) tibbs: I've looked at things, said "obviously equivalent to 3-clause BSD" and let them go with "License: BSD". (11:16:55) rdieter: scop: I'll ping Max on that at FPB too. (11:17:03) scop: warren, the same ones that have been there for ages (11:17:06) dgilmore: abadger1999: BSD is Free (11:17:16) warren: scop, like NTFS? (11:17:32) scop: warren, see the FE-Legal keyword in bugzilla (11:17:43) abadger1999: Lots of "BSD" licenses are a lot like the real, approved BSd license but are not copies. (11:17:50) scop: I have some additional ones queued up, but honestly I have zero clue where to ask (11:17:57) abadger1999: During review they are labeled BSD as the reviewer thinks they're close enough. (11:18:32) rdieter: Remember: a specfile's License: tag is not necessarily useful anyway. ): (11:18:37) XulChris: whats the latest status with cvs? (11:18:51) scop: warren, there's also some recent activity at http://fedoraproject.org/wiki/FedoraLegalIssues (11:18:52) warren: It is reasonable that legal issues should be handled by FPB (11:18:57) dgilmore: XulChris: its up (11:18:58) mharris_outside is now known as mharris (11:19:17) XulChris: dgilmore: its not working (11:19:37) bpepple: dgilmore: It looks like it's still down. (11:19:54) ixs: abadger1999: they were mostly labeled "BSDish" (11:19:56) jima: i'd say "down again." (11:20:01) rdieter: confirmed, cvs is down and out. (11:20:03) jwb: we're running long... i need to drop off (11:20:04) jima: it *was* up this morning, iirc. (11:20:09) warren: We still have Iraq listed on Fedora site (and perhaps other places) as an embargoed destination. Is this still true, since Iraq is all liberated and happy and stuff? (11:20:11) jima: well, at one point. (11:20:16) thl: jwb, bye (11:20:32) warren: Yes, all problems in Iraq are solved after the "Mission accomplished" thing. (11:20:32) rdieter: gotta run too.. (11:20:34) jwb: thl, bye. i'll read minutes again :) (11:20:39) thl: k, shall we close the meeting? (11:20:42) abadger1999: jwb, rdieter: Later (11:20:49) mharris: warren: probably not until the US removes Iraq from the "terrorist bad guys" list (11:20:51) thl: or is there anything left we should discuss now? (11:20:54) c4chris: thl, I think so (11:21:11) ***thl will close the meeting in 60 seconds (11:21:15) thl: rdieter, bye (11:21:42) ***thl will close the meeting in 30 seconds (11:22:01) dgilmore: warren: AFAIK they havent been removed from the export ban list (11:22:20) ***thl will close the meeting in 10 seconds (11:22:29) thl: -- MARK -- Meeting end (11:22:34) thl: thx everybody! (11:22:39) c4chris: thl, thanks (11:22:54) abadger1999: thl: Thanks for running the meetings. (11:22:57) c4chris: abadger1999, TTYL (90 minutes, or so, IIRC) (11:23:11) abadger1999: Yep. Talk to you then. (11:23:44) thl has changed the topic to: This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-09-07 1700 UTC | CVS playing up and down ATM }}}
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
