From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31321 invoked by alias); 27 Jul 2008 14:49:37 -0000 Received: (qmail 31313 invoked by uid 22791); 27 Jul 2008 14:49:36 -0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_05,DATE_IN_PAST_06_12,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Jul 2008 14:49:18 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6REn8ab001278; Sun, 27 Jul 2008 10:49:08 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6REn8SW012268; Sun, 27 Jul 2008 10:49:08 -0400 Received: from [10.14.51.19] (vpn-51-19.sfbay.redhat.com [10.14.51.19]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6REn5iQ025178; Sun, 27 Jul 2008 10:49:06 -0400 Message-ID: <488C2E6C.10301@redhat.com> Date: Sun, 27 Jul 2008 14:49:00 -0000 From: Eric Bachalo User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Elena Zannoni CC: Tom Tromey , Frysk List Subject: Re: meeting References: <4889CE2C.8040403@oracle.com> In-Reply-To: <4889CE2C.8040403@oracle.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00073.txt.bz2 Elena Zannoni wrote: > Thanks for posting the minutes, I was out of town. > I have a question, what is Redhat's position on the versions of frysk > shipped with > fedora and RHEL? They were tech previews, but are they going to be kept > there? > or obsoleted? Or? Good questions. I don't have answers today, but answers to these questions will be forthcoming, - Eric > > elena > > > Tom Tromey wrote: >> Tom> I reset the bridge using a trick to try to work around its >> Tom> timezone woes. I used this successfully once last week -- I hope >> Tom> it works again tomorrow. >> >> It did, yay. >> >> Tom> My agenda items are: >> [...] >> >> Some outcomes: >> >> * Thiago is happy with the decision. As far as we can tell he was the >> only non-RH person on the call. >> >> * There is some confusion about our relationship to gdb. This is >> understandable, IMO, since it is a bit vague. Basically I think the >> best way to think about this project is that it is a development >> branch with reasonably specific goals (see the earlier threads). >> >> * Speaking of the goals, an action item for everyone is to look at the >> roadmap and see (1) if anything is missing, and (2) what you are >> interested in working on. >> >> For #1, Sami asked about the state of non-stop multi-thread >> debugging. There are patches on the list. Andrew asked about the >> multi-process work, but we don't really know enough about it yet -- >> the discussion on the gdb list seems to be preliminary >> investigation. >> >> * There was general consensus that we should not reuse the frysk list >> for this work. So, we will set up a new list. Project name ideas >> that I remember: >> >> gdb-- >> >> Hmm, that is the only one I wrote down, but I know Phil had another >> one. >> >> "--" seems a bit dismal to me, but "++" seems a bit arrogant :) >> How about "Project Pelican"? >> >> Or anything else. Please. >> >> I'd like to settle this today, so... respond. >> >> * Where to host? Lots of hosting choices out there, but sourceware >> seems like the default. We all have accounts, we have access, etc. >> I'd like to get things set up ASAP, say today. >> >> * Talked about source control some. Jim Meyering is setting up a git >> mirror of gdb CVS. We'll use this as our upstream and have our own >> git repository. >> >> Andrew brought up gdb's eventual move to svn. We can revisit our >> choices if/when that happens. >> >> * We talked about our planned process. >> >> The basic change is introducing universal patch review. The scratch >> idea is: >> >> - All patches must be reviewed by someone other than the author. >> - I forgot to mention this, but Apache-like, a strong objection >> should stall a patch until a rough consensus is reached. >> - Anybody "in the project" can review a patch. In fact, I think it >> is pretty important that everybody do reviews. >> - Proposed patch review guidelines: >> * Does it have internal documentation (comments)? >> * Does it follow upstream coding style? >> * Does it have external documentation, if needed? >> * Does it have a test case, if needed? >> * Is it clear/complete/etc? >> >> Andrew asked about how we will decide to accept new contributors >> into the fold. I think we'll solve this when it comes up. >> >> * Action items, for me: >> - Set up hosting, mailing list >> - Send consolidated roadmap to the new list >> (Probably process stuff too) >> - Send announcement to gdb list >> >> Tom >> >> > >