[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

FESCo Meeting Minutes 2006-08-31

= 2006 August 31 FESCo =

Meeting Summaries are posted on the wiki at:


== 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
=== 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
=== 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 ===
 * 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
 * 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
 * Separate meeting took place.  IRC Log is:
=== "If there's something to be fixed and someone wants to fix it, then
fix it" ===
 * Ties in with comaintainership and Maintainer Responsibilities as
 * 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 --
(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 --
(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
(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
(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
(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
(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]
(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
(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]
(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
(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
(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
(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
(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
(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
(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
(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]
(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
(10:41:44) thl: I think we need to agree on a general direction here,
(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
(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
(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
(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
(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
(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
(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
(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
(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 -
(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
(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
(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
(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
(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
(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
(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
(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
(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
(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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]