In general that sounds like a good start for a plan ... but I would
guess a lot more input is needed, so ... everyone, *please* tune in.
Hans
On 04/04/2011 10:07, Systho wrote:
I 've began to work on a yearly schedule and of course I agree that
the main part of it is when to add features and when to feature freeze.
Even if I'm ok to feature freeze I think it is unfair to declare it
without telling how much tim it will last.
In the idea of a yearly stable simultaneous release in June I think
April might be a good time for freezing features of core in order for
the optional apps to stabilize and feature freeze the optional apps in
may in order for the documentation / i18n team to do their job for june.
June / July / Augustus can be a time for proposing and adopting an
agenda for accepted big features / refactorization of next years.
Additional features can be added till next april if they're in the
planing or if they're not in the planning but do not break things.
What do you think ?
Systho
Le 4/04/2011 9:58, Hans De Bisschop a écrit :
Hi all,
We've recently seen a lot of discussion on a plentitude of subjects,
quite a few of them involving yet another round of big refactoring.
Considering our current situation (get it stable) and the fact that
e.g. an official meeting with the Claroline team is still to take
place (but has been scheduled) and afterc onsulting with everyone
involved, I think it is agains our best interests to currently start
any big refactoring. I'm hesitant to use use the term "feature
freeze", but I do think that, especially for the core, we are running
out of time to actually impose a true feature freeze.
Of course, such a feature freeze could only work if EVERYONE adheres
to it, no exception. I we want to be able to tell people that no new
features are currently being accepted, we should follow that rule
ourselves too, no?
As an example I would quote the FrontController and OO-ification of
requests and responses as something which does not seem like a very
realistic thing to start working on in the near future. It can of
course be planned and prepared, but the time isn't quite right for an
actual implementation. (Too many things remain that need to be
cleared out, both technically, structurally AND on a management
level). Another example would be an idea I've been toying around with
for a long time: further abstraction of tools ... it's interesting
and definately in the future, but right now it's just too much and
too big.
On the other hand something like implementing an additional storage
engine (e.g. PDO-based MySQL, Doctrine DBAL, ZF DB, ...) should be
considered an alternative implementation that works within the
margins of the existing framework. Any holes which would subsequently
be found in the general framework can be considered bugs and can
obviously be fixed. (as long as they don't include major architecture
changes)
There will always be exceptions of course, which can obviously be
discussed if and when the need arises. I'm not trying to put a damper
on everyone's enthousiasm, but considering we're already pretty
ambitious (or so I've been told) ... we have to be very careful to
make sure we can actually proverbially walk before we start to run.
Big refactorings might be just a tad too ambitious right now.
Best regards,
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
