From Fedora Project Wiki

< Extras‎ | SteeringCommittee

Revision as of 14:13, 24 May 2008 by fp-wiki>ImportUser (Imported from MoinMoin)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Summary

Present from Fesco: thl, scop, warren, jeremy, ensc, jpo

Topics:

  • Kernel module standardization
  • We need support in the buildsys. thl posted a mail to buildsys-list last week to get the ball running, but was not successful. warren will poke dcbw so we at least know how to get the whole thing running.
  • Should archs be hardcoded with a "ExclusiveArch: i586 i686 x86_64 ppc" or similar entries? That's how it is done in beehive, but scop doesn't like that idea to much. Warren will ask dcbw if there are alternatives.
  • Mass rebuild of Extras for FC5
  • no decision yet if we want to rebuild the noarch packages, too. We continue with the current plan: Rebuild everything binary, and noarch is a lower priority
  • suggestion from scop:
wait until $date, assemble a list of not rebuilt to Wiki, have packagers either rebuild packages, note in Wiki why not, and if nothing happens before $date+N, "someone" rebuilds
  • jpo mentions problems with perl noarch packages on FC5; appears to be perl 5.8.8 related; He placed a warning in the Perl SIGs page.
  • related topic: With the current use scheme (rebuild everything by maintainer) we force people to show up. Are there any other ways to make sure that all packages in general and especially those that enter FE6 have a active maintainer? Ideas anyone? thl will write a mail with the subject "How to find out if maintainers are still active" to fedora-extras-list.
  • warren> I think *all* extras bugs should go to extras-bugs-list, and people can optionally subscribe to that.
  • Where should the bugzilla-spam for review bugs be send to? fedora-extras-list or extras-bugs-list? Both? Seems some people have been increasingly complaining about too much mail on fedora-extras-list.
  • Feedback appreciated!
  • Encourage Extras reviews
  • Review day. Highlights from the discussion:
19:37 <       nirik> | thl: didn't work too well. Not much activity... I guess we could try again with more advertisement. I only mailed extras list
19:37 <       nirik> | also a weekend time might work better.
19:38 <      warren> | I personally don't think this campaign has any chance of making a real long term difference.
19:40 <      warren> | however I personally would rather invest that time into long-term benefit tools, like more documentation and examples.
Review day education is only a short-term solution, maybe even band-aid.
19:44 <      warren> | I think better documentation and training tools, and more explicitly listed examples of tracks toward sponsorship would be helpful
19:44 <      warren> | "review day" needs active participation from the limited time of sponsors, actively engaged in training, so this might be a losing proposition and a short-term solution
19:48 <       |Jef|> | warren: i see your point about tracks... i honestly dont have a clear understanding of how to get sponsorship as a pure reviewer
19:49 <         thl> | |Jef|, could you help to write a "How to become a sponsor" page in the wiki
19:50 <       |Jef|> | thl: i can make up a process to become a sponsor and write a work of fiction
19:51 <       |Jef|> | thl: i'll write something up for the list tonite

Site note: everybody can suggest new sponsors. Just drop thl a mail with the name(s) and he'll discuss them with FESCo and the other sponsors privately.

  • Free discussion. Highlights:
20:00 <         jwb> | wondering about the 'scratch' repo idea that was resurfaced on the extras list today
20:00 <         thl> | jwb, I send a mail to the list; I like the idea
20:00 <         thl> | jwb, But somebody has to work out the details
20:00 <         jwb> | was just about to say i'll wait to see how conversation goes and then go to fesco :)
20:00 <         thl> | jwb, "somebody" can be any active extras contributor
20:01 <       |Jef|> | thl: the deeper question is, is it worth making mock builds a hard requirement for review passing
20:01 <         thl> | is a 'scratch' repo possible at all?
20:01 <         jwb> | i'll see if i can look at what would be needed in plague itself
20:02 <       |Jef|> | thl: once something is submitted... that would just be a special branch
20:02 <         jwb> | i don't think we want to go that route
20:02 <       |Jef|> | thl: for pre-submission review... i have no idea
20:03 <         thl> | |Jef|, who checks what is uploaded to the buildsys?
20:03 <         thl> | |Jef|, security is the buzz-word here
20:04 <       |Jef|> | thl: i realize... and reviewer who already has cvs commit access would have to pushing it in
20:05 <         thl> | and we'll see if there comes out anything further from the current discussion on the list

Full Log

18:53            --> | scop (Ville Skytta)  has joined #fedora-extras
18:56 <      warren> | *poof*
18:58              * | jeremy is about 50% here
18:59            --> | ensc|w (Enrico Scholz)  has joined #fedora-extras
19:00            --- | thl has changed the topic to: FESCo Meeting in Progress
19:00 <         thl> | Hello everyone
19:00 <         thl> | who'S around?
19:00              * | scop waves
19:00              * | ensc|w
19:01 <         thl> | okay, let's start
19:01            --- | thl has changed the topic to: FESCo Meeting in Progress -- Kernel module standardization
19:01 <         thl> | scop, jeremy, did you see my mail?
19:01 <     jeremy> | thl: haven't seen any mail from you
19:01 <         thl> | regarding the xen- kernels?
19:01 <        scop> | nope
19:01              * | thl wonders where that one got lost
19:01 <         thl> | okay, I'll send it again
19:02 <         thl> | we still have no plan how to get the buildsys running for the kmods
19:02 <         thl> | jeremy, warren could you poke dcbw after FC5T3 is out?
19:02 <      warren> | sure
19:02 <        scop> | the absolute minimum IMO is that we'd have a way of telling it the archs to build for
19:03 <        scop> | everything else can be temporarily hardcoded in specfiles
19:03              * | thl send the mail out
19:03 <      warren> | why not hard-code archs in specfiles like any other package?
19:03 <         thl> | warren, are you on buildsys-list?
19:03 <        scop> | warren, how?
19:03 <      warren> | ExclusiveArch: i586 i686 x86_64
19:04 <      warren> | explicitly list the archs you want
19:04 <        scop> | ah, that abuse
19:04 <      warren> | and it goes through the list
19:04 <      warren> | Core does it with beehive
19:04 <         thl> | scop, but that's how plague works afaik
19:04 <         thl> | I'm also for the ExclusiveArch solution
19:04 <        scop> | does it?  there was a discussion about this on the FE list some time ago, with no clear conclusion
19:05 <         thl> | I tested it once -- worked fine
19:05 <      warren> | Core and beehive works exactly this way.  It builds once for each listed arch.
19:05 <      warren> | no mistaking if you supply it an explicit list
19:06 <        scop> | I'd like to point out that doing that based on ExclusiveArch is plain _wrong_ (but an acceptable workaround for now if no better way exists)
19:06 <      warren> | why wrong?
19:06 <      warren> | we've been doing it that way in Core for years
19:07 <        scop> | it is not a buildsys directive, it's a property of the packaged software
19:08 <         thl> | warren, can you ask dcbw if another solution would be possible somehow?
19:08 <         thl> | otherwise I suggest that we go for ExclusiveArch for now
19:08 <         thl> | okay for everybody?
19:08 <      warren> | realistically, you ask the buildsys to build only the archs that work, or the desired archs.  The buildsys could build any listed archs that buildhosts are supported, and ignore any others (like s390x) if they are listed.
19:09 <      warren> | This is a simple solution.
19:09 <     warren> | thl, OK, I will ask dcbw
19:09 <         thl> | warren, thx
19:09 <      warren> | and maybe I'm missing context here, maybe there is a better way, I'll find out.
19:10 <         thl> | warren, I posted to buildsys-list some days ago
19:10 <         thl> | there are some questions / open issues
19:10 <         thl> | where we need help from dcbw
19:10 <         thl> | afaics
19:10            --> | jpo (Unknown)  has joined #fedora-extras
19:10 <      warren> | dcbw must be pretty swamped, but I or jeremy will corner him and get answers.
19:10              * | warren evil grin
19:10            --- | thl has changed the topic to: FESCo Meeting in Progress --  Mass rebuild of Extras for FC5
19:11 <         thl> | I'm working on a script that shows how far we are
19:11 <        scop> | the problem with exclusivearch is that let's say you list i586 i686 x86_64 ppc and someone wants to rebuild it for alpha -> won't build, even if the package/software would work
19:11            <-- | fitheach  has left #fedora-extras ( )
19:11 <         thl> | should be ready tomorrow
19:11 <      warren> | scop, you can include other archs in the list, buildsys can simply ignore Extras non-supported archs.
19:12 <         thl> | well, do we want to rebuild the SRPMS?
19:12 <         thl> | I know that SRPM don't need a rebuild per se. But I still think that we should rebuild them, too, because this was me make sure that:
19:12 <         thl> | - they still build
19:12 <         thl> | - they still have a maintainer
19:12 <         thl> | - we have no remaining packages in the distro that have "fc4" in the name due to using "%{dist}"
19:12 <         thl> | - hopefully someone looked at the older packages and checked if the update patch FC -> FC5 works
19:12 <      warren> | ExclusiveArch behaving in this manner has the benefit of also allowing glibc or openssl like multi-arch building, giving you i386 and i686 of a performance intensive (proven by benchmarks) package.
19:13 <        scop> | warren, it's abuse of the tag nevertheless
19:13 <      warren> | scop, I'd personally disagree, but either way this is very simple and it already behaves similar to this in Core literally forever.
19:14 <      warren> | more importantly the simplicity of this allows us to move forward sooner
19:14 <      warren> | (assuming dcbw doesn't have a better idea)
19:14 <        scop> | that I agree with
19:15 <         thl> | okay, now proceed to Mass rebuild?
19:15 <     warren> | thl, I'd say find out what isn't rebuilt, and that list can serve more than one purpose
19:15 <       scop> | thl, I can say that the packages I maintain are checked for those
19:15 <     warren> | thl, 1) Who isn't responsible in maintaining?  (probably me)  2) And we decide if we rebuild it anyway, just like Core.
19:16 <     bpepple> | Has gstreamer-08 been imported in extras yet.  There's about 3 or 4 packages dependent on that for a rebuild.
19:16 <         thl> | scop, I now that you checked your packages
19:16 <      jeremy> | bpepple: I don't remember seeing it in the "needs review" queue yesterday
19:16 <         thl> | But just remember comptons packages
19:17 <         thl> | they probably would never have entered FE4
19:17 <        scop> | of course, that's a completely different scenario
19:17 <         thl> | yeah
19:17              * | nirik needs to find time to fire off rebuilds for all his. Pesky lack of time.
19:17 <         thl> | But that's why I would like that every maintainers shows up
19:17 <         thl> | and rebuilds all his packages
19:18 <      warren> | realistically, a volunteer driven project will have people disappear and reappear, and we cannot expect everyone to be there always.
19:18 <     bpepple> | jeremy: Does it need a formal review, since it was just removed from Core?
19:18 <         thl> | warren, sure
19:18 <         thl> | warren, but we need to know if they disapeear
19:18 <     warren> | thl, and even Core is mass rebuilt by the technical leaders without input from the individual package maintainres.
19:18 <         thl> | disappear
19:18 <     warren> | thl, yes, the list after voluntary rebuilds can tell us.
19:18 <      jeremy> | bpepple: everything needs have a review to be imported into extras
19:18 <        scop> | I have some 50+ packages not yet rebuilt this week, the vast majority of which are noarch and would have _no_ practical benefits from a rebuild to anyone but me, and I've checked most of them locally already
19:18 <     warren> | thl, however more simply, parsing the extras-commits-list can tell us the same.
19:19            --> | monkey- (michael)  has joined #fedora-extras
19:19 <      warren> | I personally see no benefit to rebuilding noarch.  Actually there is no benefit in rebuilding i386 and x86_64 IIRC.  The ABI change was only ppc?  Gotta fact check...
19:19              * | warren reads mail
19:19 <         thl> | well, we IMHO should discuss the noarch issue now
19:19 <     bpepple> | jeremy: Rule must have changed.  Use to be that if it was in Core, that it could be imported into Extras.
19:19 <         thl> | otherwise we are running out of time
19:19 <      jeremy> | bpepple: yeah, that changed a few months ago
19:20 <      jeremy> | warren: there are security features in 4.1 that help i386 and x86_64
19:20 <         thl> | even core seems to rebuild the noarch packages afaik
19:20              * | scop needs to flee in about 15 or so minutes, btw
19:20 <      warren> | jeremy, oh right
19:20 <         thl> | well, do we want to vote on the noarch issue?
19:21 <         thl> | Or wait another week?
19:21 <      warren> | How about this... rebuild everything binary, and noarch is a lower priority, we can decide to do that next week or later.
19:21 <         jpo> | Build noarch: +1
19:21 <         thl> | warren, that's the current situation already
19:21 <        scop> | -1
19:21 <      warren> | Build noarch: Decide later, low priority +1
19:21 <         jpo> | I am having problems with  a perl noarch packages
19:21            --> | cwickert (Christoph Wickert)  has joined #fedora-extras
19:21 <      warren> | jpo, no longer compatible with FC5 perl for some reason?
19:22 <         jpo> | appears to be perl 5.8.8 related
19:22 <      warren> | should compat symlinks in 5.8.8 be removed?
19:22 <      warren> | jpo, any bugzilla to track this issue?
19:22 <        scop> | wait until $date, assemble a list of not rebuilt to Wiki, have packagers either rebuild packages, note in Wiki why not, and if nothing happens before $date+N, "someone" rebuilds
19:23 <     warren> | thl, scop: Note that "didn't voluntarily rebuild" is not the only way to figure out who isn't active anymore.  extras-commits-list can tell us too.
19:23 <         jpo> | I don't think so. I still haven't figured out the problem.
19:23 <         jpo> | warren: I placed a warning in the Perl SIGs page.
19:24 <         thl> | warren, how should that work in extras-commits-list?
19:24 <         thl> | warren, we have some packages that have selfdom upstream updates
19:24 <         thl> | take bonnie++ or tiobench for example
19:24 <         thl> | they are both older than 2 years already
19:24 <     warren> | thl, something to do with package owner, and did they checkin since
19:25 <     warren> | thl, isn't bonnie++ me? ^^
19:25 <         thl> | warren, and tiobench is mine ;-)
19:25 <         thl> | but they serv as good example
19:25 <      warren> | I know that I'm behind 5,000 mail
19:25 <      warren> | I personally don't think this is a big issue, eventually we should do what we do in Core in every cycle, just rebuild everything and poke all maintainers.
19:26 <      warren> | However the level of expectation of responsibility for maintainers disappearing in Extras is different than core.
19:26 <         thl> | yeah
19:27 <      warren> | Maybe we can consider an automatic timeout, like "If you don't respond in X amount of time, package goes automatically into orphan."  However I wouldn't want bugzilla to stop going to the maintainer.
19:27 <      warren> | orphan mail should be going to a list for multiple people to watch....
19:27 <         thl> | warren, sound like a plan
19:27 <      warren> | arguably that should be extras-list along with all other extras bugs, in addition to package reviews, however some people have been increasingly complaining about too much mail on that list.
19:28 <      warren> | Other teams have began using another list like foo-bugs-list, maybe we should split it out.
19:28 <         thl> | maybe
19:28 <      |Jef|> | thl: whoa are you talking about the orphans thing i brought up?
19:28 <         thl> | |Jef|, not directly
19:29 <         thl> | I think I'm going to send a separate mail to fedora-extras-list
19:29 <         thl> | "How to find out if maintainers are still active"
19:29 <         thl> | and we wait what comes out of the discussion
19:29 <         thl> | and we proceed with the rebuild as announced
19:29 <         thl> | that okay for everybody for now?
19:30 <         thl> | we can talk about hte noarch packages in the next meeting again
19:30 <      |Jef|> | thl: the stats guy is starting to poke at scripts to try to narrow potential orphaned items
19:30 <      |Jef|> | thl: in private email with me
19:31 <      warren> | separate discussion and decision item, I think *all* extras bugs should go to extras-bugs-list, and people can optionally subscribe to that.
19:31 <         thl> | |Jef|, k, thx, I'll talk to him
19:32 <         thl> | warren, I know somebody that will complain if we do that
19:32 <     warren> | thl, eh?
19:32 <         thl> | warren, he'll say "we need as much people as possible to watch the reviewers"
19:32 <         thl> | But I tend to agree
19:32 <     warren> | thl, when I say *all* extras bug mail, I don't mean removing the maintainers from direct mail, this is an additional auto-CC
19:33 <     warren> | thl, "we need as much people as possible to watch the reviewers"   I don't understand what this means.
19:33 <         thl> | warren, with the current scheme (everything to one list) everybody see the comments in the review-bugs
19:33 <         thl> | If we have a separate mailinglist for bugzilla-spam
19:34 <         thl> | then only a few will subscribe
19:34 <         thl> | and no one watches the reviewers if they do a good job
19:34 <      warren> | ah
19:34 <         thl> | But I tend to agree
19:34 <         thl> | A separte mailinglist has benefits
19:34 <      warren> | I think bug mail should go either to extras-list, or extras-bugs-list
19:34 <      warren> | I don't care which
19:35 <         thl> | warren, I'll note that in the summary
19:35 <         thl> | we can revisit this next week
19:35 <      |Jef|> | thl: on a personal note.. i already filter out the review items in extras-list into a seperate category
19:35 <     warren> | thl, thanks
19:35 <         thl> | |Jef|, hehe, you're probably not the only one doing this
19:35 <      |Jef|> | thl: i doubt highly actively people read extras-list in timestamp order without filtering
19:36 <         thl> | okay, done with this?
19:36            --- | thl has changed the topic to: FESCo Meeting in Progress --  Encourage Extras reviews
19:36 <         thl> | nirik, what's your opinion on the review day after the first one is done?
19:36 <      |Jef|> | thl: seperate lists for reviews have the advantge of web archive threading readability...if we had good web archives
19:37 <      |Jef|> | thl: opps...nevermind topic changed
19:37 <      nirik> | thl: didn't work too well. Not much activity... I guess we could try again with more advertisement. I only mailed extras list
19:37 <       nirik> | also a weekend time might work better.
19:37 <       nirik> | or we could just forget it. ;)
19:37 <       |Jef|> | nirik: let me strongly suggest..from my very experient trying to do bug days...back in the day.... you'll have to advertise more
19:38 <         thl> | nirik, yeah, we should try this further
19:38 <      warren> | I personally don't think this campaign has any chance of making a real long term difference.
19:38 <       nirik> | yeah, probibly true.
19:38 <      warren> | Realistically this goes back to the motivation of volunteers.  Volunteers only do what interests them.
19:38 <      warren> | we should instead be focusing on education
19:38 <       |Jef|> | warren: unless there is a way to get more reviewers into the pool as part of the process
19:39 <       nirik> | I can try again in a few weeks? before fc5?
19:39 <       nirik> | warren: one advantage of review days is that it might help educate people on how to do them...
19:39 <       |Jef|> | warren: what if activity during review days...helped towards getting contributor status?
19:39 <      warren> | perhaps yes
19:40 <        scop> | I need to run now.  CU
19:40 <       |Jef|> | warren: so people who dont have the ability to approve could earn that ability by participating in organized review days
19:40 <      warren> | however I personally would rather invest that time into long-term benefit tools, like more documentation and examples.  Review day education is only a short-term solutoin, maybe even band-aid.
19:40            <-- | scop has quit ("Leaving")
19:40 <      warren> | |Jef|, maybe, I don't know for sure
19:41 <      warren> | (about effectiveness)
19:41 <       |Jef|> | warren: is there a mechanism in place right now to get approval status that doesn't involve submitting your own package and becoming a package maintainer?
19:41 <       |Jef|> | warren: realistically
19:41 <      warren> | technically getting approval status is proving to a sponsor that you read all documentation and understand all the rules, and are technically sound.  You prove it somehow.
19:42 <      warren> | packaging just was a simple way to do it in the past
19:42 <       |Jef|> | warren: "somehow"
19:42 <      warren> | we can probably expand that into example tracks
19:42 <       |Jef|> | warren: what im saying is i dont see a realistic way to do that as a reviewer
19:42 <      warren> | track A, track B, track C, only examples
19:42 <       |Jef|> | warren: review days..organized specifically to build a track record sponsors can use when judging a sponsorship request seem usefule to me
19:42 <      warren> | |Jef|, please educate me, but have you ever packaged anything or done a review yourself in Extras?
19:43 <       |Jef|> | warren: yes
19:43 <      warren> | ok, I haven't been folllowing all traffic, I don't know.
19:43 <      warren> | |Jef|, I personally as a sponsor watch activity of folks over the span of days or weeks and search google to see level of clue before making decisions.
19:43 <       |Jef|> | warren: my ratio right now is 2/1 reviews to maintained packages :->
19:44 <       |Jef|> | warren: and im trying to keep that ratio
19:44 <      warren> | I think better documentation and training tools, and more explicitly listed examples of tracks toward sponsorship would be helpful
19:44 <      warren> | "review day" needs active participation from the limited time of sponsors, actively engaged in training, so this might be a losing proposition and a short-term solution
19:45 <         thl> | warren, it's better then nothing
19:45 <       |Jef|> | warren: indeed.. review days would need to have sponsors participating to be used for recruitment
19:45 <      warren> | sorry, I shouldn't be discouraging.  I'll attempt to attack the problem from the other side.
19:45 <      warren> | multiple fronts...
19:45 <       |Jef|> | warren: and my answer to that is... more sponsors !
19:46 <         thl> | |Jef|, nominate them
19:46 <      |Jef|> | thl: i can nominate sponsors?
19:46 <         thl> | |Jef|, drop me a mail with some names
19:46 <         thl> | Sure
19:46 <      |Jef|> | thl: i dont have to be a sponsor to nominate more sponsors?
19:46 <      warren> | |Jef|, more sponsors alone cannot solve the problem, you need the right people with the right motivation, and the only way to do that is by education
19:46 <         thl> | I don't think that is required
19:47 <      warren> | I don't particularly see review days as being effective in that.  It is too time consuming for the existing experts.
19:47 <         thl> | |Jef|, but the sponsors and/or FESCo will discuss the names
19:47            <-- | cweyl has quit (Read error: 104 (Connection reset by peer))
19:47 <         thl> | guys, we're running out of time
19:47 <      warren> | |Jef|, thl: I do see value in a nomination list, but perhaps collecting info and URLs of their work would help FESCO make quicker decisions with low time overhead
19:47 <         thl> | does anyone want has anything else important to that topic?
19:48            --> | JSchmitt (Jochen Schmitt)  has joined #fedora-extras
19:48 <       |Jef|> | warren: i see your point about tracks... i honestly dont have a clear understanding of how to get sponsorship as a pure reviewer
19:48 <       |Jef|> | warren: its much more clear how to get it by trying to be a package maintainer
19:48 <      warren> | |Jef|, then examples of that can be added in tracks
19:48 <      warren> | being a package maintainer has never been a hard and fast requirement, the documentation now is very unclear on that and maybe contradcitory to what I've always been thinking
19:49 <       |Jef|> | warren: no not a requirement... but its more clear how to work towards sponsership as a maintainer
19:49 <         thl> | |Jef|, could you help to write a "How to become a sponsor" page in the wiki
19:49 <         thl> | |Jef|, I can help if you need input
19:49 <      |Jef|> | thl: if i knew how
19:49 <      warren> | I think perhaps that owning a package gives you a stake in it, it is difficult to get someone involved enthusiastically if they don't "own" something.  Volunteer motivation
19:50 <      |Jef|> | thl: i can make up a process to become a sponsor and write a work of fiction
19:50 <      warren> | |Jef|, write to the list first please, I can combine the problem with my thoughts then redo the existing doc
19:50 <         thl> | warren, sounds like a good idea
19:51 <         thl> | |Jef| ?
19:51 <      |Jef|> | thl: i'll write something up for the list tonite
19:51 <         thl> | |Jef|, thx
19:52 <         thl> | okay, moving on
19:52 <      warren> | I'm almost out of time
19:52            --- | thl has changed the topic to:  FESCo Meeting in Progress  -- Weekly sponsorship nomination
19:52 <         thl> | John Mahowald / jpmahowald ?
19:52 <         thl> | warren?
19:52 <      warren> | He's doing OK, I need to look deeper
19:53 <      warren> | (one benefit of manually approving branches is it force me to read all reviews.   One detriment is that I'm letting ignacio's work stagnate...)
19:53 <         thl> | hehe
19:53 <         thl> | okay, any other nominations?
19:53 <     warren> | thl, don't ask me to decide alone, but I can make a decision by next week.  If I'm silent then then I'm +1
19:54 <         thl> | warren, scop also said +1 on FESCo list
19:54 <         thl> | and he remindet me to mention jpmahowald
19:55 <         thl> | reminded
19:55 <         thl> | okay, then next week
19:55            <-- | finalzone has quit ("Download Gaim: http://gaim.sourceforge.net/")
19:55            --- | thl has changed the topic to: FESCo Meeting in Progress  -- free discussion
19:56 <     warren> | thl, I'm liking your meeting organizational style and following up on points.
19:56 <       nirik> | yeah... you're doing great thl. :)
19:56 <         thl> | well, the meetings were shorted in gregdek's days
19:57 <     warren> | thl, you're inspiring us to get to conclusions
19:57 <         thl> | warren, thx :)
19:57 <         thl> | nirik, thx, too
19:57 <      warren> | I'm out of time
19:57 <      warren> | thanks
19:57 <      warren> | everyone
19:57 <        jwb> | thl, i especially like the summary notes being sent to the -extras list
19:57 <         thl> | I's good to also get some positive feedback now and then ;-)
19:57 <      warren> | I like the /topic changing
19:58 <         jwb> | that too
19:58 <         thl> | anyway: does anyone have anything left to discuss?
19:58 <         thl> | Or can we call it a day?
19:59              * | thl will close the meeting in 30
19:59              * | thl will close the meeting in 15
19:59              * | thl will close the meeting in 10
19:59              * | thl will close the meeting in 5
19:59 <         jwb> | one thing
19:59 <         thl> | :)
19:59 <         jwb> | oh, nevermind
19:59              * | thl waits
19:59 <         jwb> | i'll wait for next week
19:59 <         thl> | jwb, shoot
20:00 <         jwb> | wondering about the 'scratch' repo idea that was resurfaced on the extras list today
20:00 <         thl> | jwb, I send a mail to the list
20:00 <         thl> | jwb, I like the idea
20:00 <         thl> | jwb, But somebody has to work out the details
20:00 <         jwb> | was just about to say i'll wait to see how conversation goes and then go to fesco :)
20:00 <         thl> | jwb, "somebody" can be any active extras contributor
20:01 <       |Jef|> | thl: the deeper question is, is it worth making mock builds a hard requirement for review passing
20:01 <         thl> | |Jef|, the real question imho is:
20:01 <         thl> | is a 'scratch' repo possible at all?
20:01 <         jwb> | i'll see if i can look at what would be needed in plague itself
20:02 <       |Jef|> | thl: once something is submitted... that would just be a special branch
20:02 <         jwb> | i don't think we want to go that route
20:02 <       |Jef|> | thl: for pre-submission review... i have no idea
20:02 <         thl> | |Jef|, well, I'm not sure on this
20:03 <         thl> | |Jef|, who checks what is uploaded to the buildsys?
20:03 <         thl> | |Jef|, security is the buzz-word here
20:04 <       |Jef|> | thl: i realize... and reviewer who already has cvs commit access would have to pushing it in
20:04 <         thl> | |Jef|, yeah, that could work
20:04 <         thl> | |Jef|, I'll mention it in the summary
20:05            <-- | kbsingh has quit ("HomeTime")
20:05 <         thl> | and we'll see if there comes out anything further from the current discussion on the list
20:05 <         thl> | okay for everybody?
20:05              * | thl will close the meeting in 15
20:05 <       |Jef|> | thl: scratch post-submission might be more tractable
20:06 <         thl> | |Jef|, yeah
20:06 <         thl> | well, let's stop for today
20:06              * | thl will close the meeting in 5
20:06 <         thl> | MARK Meeting end
20:06 <         thl> | thx everybody