gnustep-dev
[Top][All Lists]
Advanced

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

Re: side projects and sub projects


From: Richard Frith-Macdonald
Subject: Re: side projects and sub projects
Date: Sun, 28 Feb 2016 15:10:16 +0000

> On 28 Feb 2016, at 09:55, Riccardo Mottola <address@hidden> wrote:
> 
> Hi,
> 
> Stefan Bidigaray ha scritto:
>> 
>> I agree with you that the overall goal of GNUstep--the GNU project, not the 
>> community that enable the project--already has a stated goal.  I also agree, 
>> however, that the project is not clear about the "other stuff".  For 
>> example, GNUstep includes GWorkspace and System Preferences as officially 
>> supported packages, but these are desktop applications.  It also includes 
>> things like EC, Performance, GDL, etc in the official repository which, 
>> despite being useful frameworks, go beyond the stated goal.  Like it or not, 
>> these sub-projects add to the confusion.
> 
> what is GNUstep? I think that actually our SVN repositories are actually 
> clearer than the websites

Riccardo, I think perhaps I've not been clear enough about what I'm trying to 
talk about here.
Obviously there is more than one meaning of GNUstep, and I was trying to 
address issues of how to make progress with the non-core stuff (admittedly, 
partly in the hope of improving the core too).

So I was sticking to the official aims of the GNUstep project ... that code 
*maintained* and officially supported by the team.

Another meaning (2) of 'GNUstep project' is a legal term applicable to the FSF, 
and refers to all software whose copyright has been assigned to the FSF as part 
of the project.  That's completely different from the set of actively developed 
code.

Then there's what I think you are referring to (3) ... the umbrella term that 
encompasses everything GNUstep relatred (but in particular the long term goal 
of a complete GNUstep desktop environment ... something like a clone of 
NeXTstep, but updated).  This is more of an ideal or an ethos common to members 
of the team.

The second of these meanings is a technical one of little use to anyone apart 
from lawyers, but it has strong bearing on what's in svn and what isn't.

The third meaning also historically had a big influence on the layout of the 
svn repository.

So really, the layout of the repository is not a good guide to the actively 
maintained project I'm tryuing to discuss here


reply via email to

[Prev in Thread] Current Thread [Next in Thread]