[Fusionforge-general] Partial report of the FusionForge meeting
Christian Bayle
gforge at free.fr
Sun Oct 14 11:08:25 CEST 2012
Hi
Also we all agreed about Thorsten proposal, didn't we ?
<mira|fr> Suggested ground rules for API:
<mira|fr> • absolutely no db_* calls in www/
<mira|fr> • absolutely no echo, print, etc. in common/
<mira|fr> • www/include/ should not exist
<mira|fr> • all plugins, hooks, etc. MUST NOT call echo, print, etc. but
only return strings/numbers, arrays, objects
<mira|fr> might make an exception for generic code that takes
arrays/objects and prints them, for www/include/
And I should work on git commit notification
Christian
On 12/10/2012 13:28, Roland Mas wrote:
> Hi all,
>
> Here's a quick dump of the notes I took last Wednesday during our
> meeting in Paris.
>
> * TODO Roland: cleanup project membership on fusionforge.org, since
> there's no point in having users being marked as project members
>
> * We should think of implementing some way of helping forge admins to
> find inactive accounts (maybe store a last login date in the users
> table and provide a report on that)
>
> * TODO Roland (+ others): rework fusionforge.org homepage to make it
> more readable, with direct links to appropriate pages
>
> * Governance: decisions are discussed in the weekly IRC meeting, then
> the proposal is written up and sent to the mailing-list; if a week
> passes and nobody objects, the next IRC meeting ratifies it
>
> * TODO: update list of plugins, and include information on each plugin
> such as who uses it regularly, who maintains it, and so on
>
> * SCM switch to git, with svn still available via the gateway (see
> Alain's mail)
>
> * Since we now have better branching and merging, the packaging stuff
> (for *.deb and *.rpm packages) should be split off into dedicated
> repositories, or at least dedicated branches
>
> * Also related to branching: let's do development on feature branches
> from now on, and only merge each feature branch onto trunk when it's
> ready and tested (with a testsuite!), this should help preventing
> further delays in stable releases. I think bugfixes can still go
> directly to trunk, but let's be really careful about that.
>
> * We should probably, *as an upstream project*, stop publishing (or
> advertising) ready-made packages. People interested in getting
> packaged versions should go to the packagers or the distributions, or
> build the packages themselves. Providing packages only creates
> confusion, since the requirements imposed by each target distribution
> vary wildly and the result is inconsistency in how the packages
> behave.
>
> Please add what I forgot :-)
>
> Roland.
More information about the Fusionforge-general
mailing list