From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30345 invoked by alias); 7 Jan 2002 20:04:18 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 30301 invoked from network); 7 Jan 2002 20:04:15 -0000 Message-ID: <3C39FF78.4040209@t-online.de> Date: Mon, 07 Jan 2002 12:04:00 -0000 From: khamis2@t-online.de (Khamis Abuelkomboz) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralf Corsepius CC: Mo DeJong , Sourcenav List Subject: Re: SourceNav release ... References: <20020105195420.47a9e61c.supermo@bayarea.net> <1010327798.1505.4.camel@mccallum> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 520027106440-0001@t-dialin.net X-SW-Source: 2002-q1/txt/msg00014.txt.bz2 Hi Ralf, I find your input great. we need an "open" way to add work into SN, I had the idea about taking the current redhat SN and provide my own SN release, basicly to rework the GUI and extend the existing parsers. As example I would like - to integrate the symbol browser into the main window, - add more functionality to the browser, like add/remove files, history, etc. - making it possible to open more than one editor pane in a window. - list the symbols of current edited file on the right (OLD SN functionality reenabled) - etc. Actually I already started to do this work, see http://oimanager.de/sn/newsngui.gif and welcome your input. But the problem is, where to keep the whole SN? My own web space is too small. However I find puting SN into an open CVS is a first step to achieve this gool. Khamis Ralf Corsepius wrote: >Am Son, 2002-01-06 um 04.54 schrieb Mo DeJong: > >>On Sun, 6 Jan 2002 02:25:59 -0600 >>"Simonovsky, Pavel" wrote: >> >>> So - you mean , that in fact SN is dead , and there is no >>>any development team behind it? It is very important info - I suggested this >>>tool to 2-3 teems in our company ... I have to warn them - that it dose no >>>worth a waste of time... >>> >>Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help. >> >>I know for a fact that Ian has been doing some great work on his own >> >time to get the development version that uses Tcl/Tk 8.3 available via >CVS. It is quite an improvement over the 5.0 release. That said, what is >lacking is time and resources to put out a 5.1 release. What is the >solution? I am not sure. I would like to hear ideas from people on this >list. > >OK, here is mine: > >IMHO, the basic problem is to render SN into an active project. > >As RH apparently is not developing actively anymore, one solution would >be to convert SN into a real OpenSource community project. > >AFAIS, there would be 2 approaches to such an attempt: > >1.) Apply the existing RH-infrastructure and run it >RH-conducted/assisted. >This would require RH to provide minimal assistance and support (ML, >CVS, ftp etc) + generally OK-ing into such undertaking. > >Given the existing SN-related infrastructure at RH, I fail to see why >this should not work. At that lacks are active maintainers (RH or Non-RH >person) willing to accept and apply patches + to guide people though >development. > >>From my POV, it's only the lack of active maintainers which currently >lets appear SN as "dumped dead code junk". > >2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's >SN-code as basis. IMHO, nobody actually would be interested in doing so >and I also doubt it would actually work out. > >>I would think the right solution would provide a stable 5.1 release, >>but also provide a plan for 5.2 and future releases. >> >I fully agree. > >But the only way to achieve something of this kind IMHO would be >somebody (the maintainer - who is it? Ian, you?) to show some visible >initiative - Currently, SN appears not only to be dead, but to >unmaintained. > >Ralf > > >