[Gforge-devel] Commit policy?

[Michael Casadevall]

The other problem is the mass of GForge's code is fairly haphazard,  
dating back from SourceForge. It's not bad, but its not great, and  
it's starting to reach feature creep. Plugins helped reduce the creep  
because they can be removed, but they complicate development because  
now its impossible to have all the code in one place (CVS doesn't  
like it when you try to check out into a checked out repository. To  
compound the problem, changes involving the database are a pain,  
mostly because you need to know what patch files to apply to the  
database to just get it installed from CVS. The best solution here  
would be some sorta intelligent upgrade that can apply the changes  
per each checkout - Mediawiki uses something like that.

Having been a Savannah developer before joining the GForge project,  
they chose to cut out a lot of extra compontents. They're  
bastardization of Sourceforge 2.0 only has Mailing Lists, SCM  
integration, and a release area, with forums merged into the news  
section and depreciated; they also rewrote a LOT of the tracker code  
to be cleaner. The difference here is while the GForge codebase is  
fairly bloated and tricky to setup, but has every feature + the  
kichten sink, Savannah is feature light, but really easy to setup  
(you need PHP, Mailman, and Linux. You just do ./configure, make,  
make install in there source, and answer a few questions).

The final thing is that GForge has reached feature complete status  
more or less. I can't think of another feature (expect for SCM  
plugins) to make it better. The codebase is mature, and I'm at a loss  
to see what really needs to be added from this point on.
Michael

On Oct 5, 2006, at 4:14 AM, Tim Perdue wrote:

> Jacob Levine wrote:
>> Hello list,
>> I have been wondering what sort of policy I should be following  
>> regarding
>> commits to the svn repository. As far as I can tell, since opening a
>> handful of bugs last month here and in the Mod Auth GForge project  
>> no else
>> has made any changes to them. I have patches attached to half of  
>> my bugs--
>> valid patches so far as I can understand.
>> That's the crux of my question-- I have only just joined this  
>> project and
>> so have a very limited understanding of how GForge works. Should I  
>> just go
>> ahead and commit the patches that look ok to me, expecting someone  
>> else to
>> revert them if they discover a problem? Or should I continue to post
>> patches to the trackers, hoping that someone will find the time to  
>> look at
>> them? The Contribution Guide indicates that the latter approach  
>> should be
>> taken, but in the trackers I've found some old patches that have  
>> never
>> been addressed.
>
> You should try to review and commit patches, fix bugs, etc, as long  
> as you are keeping it stable.
>
> Basically, the core team of GForge needs to be rebuilt. The old  
> core team of french guys all quit working on the project a couple  
> years ago, and I quit posting here 6 months ago because absolutely  
> no one was responding or supporting me or my team in any way. I  
> provided all the support on the user forum for the last 1-2 years  
> and can't remember the last time someone simply said 'thanks'.
>
> In order for an open source project to survive, their needs to be  
> people encouraging and supporting it, not just sucking the system  
> dry, which is what happened here. The project got sucked dry and  
> without any feedback from the users, people stopped working on it.  
> I call it the "Rip n Run" mentality of the GForge user base.
>
> I'd suggest consolidating discussions on the user forum so as not  
> to divide attention between two low-volume lists.
>
> Tim
> _______________________________________________
> Gforge-devel mailing list
> Gforge-devel at lists.gforge.org
> http://lists.gforge.org/mailman/listinfo/gforge-devel