[Gforge-devel] Commit policy?

[Thomas Charron]

  Hrm.  One has to wonder, if it's feature complete, exactly why some of us
are putting in features that are present in the gforge AS commercial
package.

  Thomas

On 10/5/06, Michael Casadevall <sonicmctails at aol.com> wrote:
>
> 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
>
> _______________________________________________
> Gforge-devel mailing list
> Gforge-devel at lists.gforge.org
> http://lists.gforge.org/mailman/listinfo/gforge-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://svr1.gforge.org/pipermail/gforge-devel/attachments/20061005/31958086/attachment.html