From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18782 invoked by alias); 25 Jul 2008 13:06:09 -0000 Received: (qmail 18771 invoked by uid 22791); 25 Jul 2008 13:06:08 -0000 X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from agminet01.oracle.com (HELO agminet01.oracle.com) (141.146.126.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 13:05:29 +0000 Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m6PD4PIB020983; Fri, 25 Jul 2008 08:04:25 -0500 Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m6O4wsM1015757; Fri, 25 Jul 2008 07:04:24 -0600 Received: from c-98-217-204-18.hsd1.ma.comcast.net by acsmt359.oracle.com with ESMTP id 11042901641216991051; Fri, 25 Jul 2008 08:04:11 -0500 Message-ID: <4889CE2C.8040403@oracle.com> Date: Fri, 25 Jul 2008 13:06:00 -0000 From: Elena Zannoni Organization: Oracle USA Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Tom Tromey CC: Frysk List Subject: Re: meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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/msg00067.txt.bz2 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? 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 > > -- Elena Zannoni, Oracle Senior Engineering Manager, Tools/Languages - Linux Engineering Blog: http://blogs.oracle.com/ezannoni Email: elena.zannoni@oracle.com