Just to clarify: my idea was to seriously start considering going
towards a feature freeze, not necessarily to impose it *right now*.
Hans
On 04/04/2011 10:26, Stefaan Vanbillemont wrote:
Hans,
I follow your remarks to put an temporary feature freeze right now
without forgetting the refactoring ideas/plans that where suggested
the last few weeks.
Systho: can you put your 'year' idea on a wiki page so we have a more
clear view ??
The rework of the support project is more or less ready, as soon as we
have a agreement on the release management I can start creating
versions for the different applications/packages. So the combined
roadmap should become very clear for everybody!
I also created 2 'testing' queries for people that want to test
bugfixes/feature implementations. SO can access them in the issue list
view of Core and Applications
Applications:
http://support.chamilo.org/projects/chamilo-20/issues?query_id=48
Core: http://support.chamilo.org/projects/chamilo-20/issues?query_id=47
If wanted, I can create queries to offer a combined view with open
issues too :-)
Kind Regards,
Stefaan Vanbillemont
Op 4/04/11 10:16, Hans De Bisschop schreef:
ion. 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,
--
_______________________________________________
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
