I've added my idead to the planning page on the wiki :
http://support.chamilo.org/projects/chamilo-20/wiki/Planning
Le 4/04/2011 10:29, Hans De Bisschop a écrit :
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
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
