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 14:55:23 +0000

> On 27 Feb 2016, at 17:01, Stefan Bidigaray <address@hidden> wrote:

<snip>
> I believe the real hard part is where to draw the line.  One might argue that 
> Windows and GNU/Linux native integration is actually part of "a framework for 
> portable software development in the Objective-C language...", because 
> without this integration can you really say it is portable?

I completely agree ... my original statement was an attempt to be distinctly 
ruthless by omitting everything which, to the best of my 
knowledge/recollection, hasn't been officially committed to by the GNUstep 
maintainers.

> I'm not arguing for or against that, just suggesting how the stated goal 
> might be used to justify side-projects to be included as part of the official 
> project.

> And then, once you've drawn the line it needs to be respected.  This last bit 
> is tough with a community driven project.  Folks are always going to want to 
> push their pet projects, and the easiest way to gain legitimacy for these 
> side-projects is to include it in the upstream project.

Yes, and I strongly approve of these projects being rolled into the main 
official project; but as completed items at least one or two people committed 
to continuing to support them.
It's great for the core project objectives to expand over time (eg support a 
later OSX API version, or support windows native look and feel rather than just 
running on windows), but to mergin in a side/sub project, that project should 
(IMO) be functional (complete barring minor bugs/omissions) and come with its 
own maintainer(s) unless an existing maintainer offers to formally take it over.

<snip>

> The Wiki is already full of such pages.  In my opinion, any effort to provide 
> such a list-of-links should also include an effort to clean up the website 
> and wiki.  Personally, I think we should model whatever we do on the Qt 
> (http://www.qt.io/) and GTK+ (http://www.gtk.org/) websites.  These are 
> GNUstep's most direct competitors.  I really like how the GTK+ website is 
> short and to the point, it says a lot about the project in very few words.
> 
> The main web page, for example, has the statement "A comprehensive list of 
> applications on our Wiki application pages and in the Software Index".  When 
> using "our" it implies that it is part of the project.
> 
> The wiki currently includes extremely outdated pages that were created by 
> side-projects but once the project was abandoned, discontinued or 
> incorporated they wiki was never updated.  Take the Camaelon 
> (http://wiki.gnustep.org/index.php/Camaelon) page, for example.  It is 
> currently referenced by the Themes 
> (http://wiki.gnustep.org/index.php/Themes).  This was just the most obvious 
> example I found, there are many others that reference side-projects where the 
> description is unclear.
> 
> We also have a wish-list already, it is just extremely confusing and goes 
> against some of the things you said and the stated goal 
> (http://wiki.gnustep.org/index.php/Wish_list).
>  
> I think trying to publicise/support these side projects would actually feed 
> back into GNUstep rather than sucking away resources. 
> 
> I agree, but it is also important to keep it up-to-date.
> 
> Whatever is done, though, I think it needs to be a concerted effort.

Yes,  I think all that sounds like an effort to consolidate/formalise this 
stuff into a managable number of side/sub projects.

> Every developer needs to realize not everything they want will make the cut 
> and that maybe additional stuff will be added that they disagree with.

I have no desire to exclude anything/anyone from GNUstep, on the contrary, I 
hope that it could encourage people to combine things or to rationalise 
multiple similar pieces of work to combine their efforts.  It's true that such 
work involves compromises, but the benefits should outweigh the drawbacks.  For 
instance, there's a tendency of people to want a GNUstep based distribution on 
their own preferred operating system, but in many cases the different base 
operating systems share a common heritage and packaging system, so those people 
could get together and make something that serves all their purposes.







reply via email to

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