We should make a list with all current development efforts on the
development repos. Who is going to collect that data, where should we
put it?
HoGent team? VUB team? EhB team? Geneva team? This should really be a
detailed list ( with issue numbers if possible)
Can we put that on the wiki page?
http://support.chamilo.org/projects/chamilo-20/wiki/Planning
I remember this being discussed at some point. Right now the Wiki does
seem like the best place to put this. I could collect it, but then again
those people who are actually working on things are probably best suited
to add their activities themselves. I'll set up some kind of template /
structure which can be used, so it doesn't become too much of a mess. I
would advocate against listing every single issue, we can just link to a
filtered list for that. The pages could include what is being worked on
specifically without going down to the level of individual issues.
Features could all be listed though.
Should we set a fixed date? 30 May is on a monday, or better on Friday
27 (with an IRC meeting to give the official call?) so we can have a
quick overview of last-minute change of plans.
We should check the list from section 1 and see if everybody is ready
with all his/her developments. Can we allow exceptions?
Because of the fact that following the freeze, "some" merges need to be
done, I wouldn't do it on a friday, but on a Monday. Projects which are
still ongoing (our own surveys and matterhorn streaming come to mind)
needn't really be frozen, since they will more then likely not be in the
release just yet anyway.
I'll add a proposed list of packages for the release to the wiki, based
on what was in the previous release. There will no doubt be a few things
that need to be adjusted / added / deleted, but at least it's a starting
point.
I see two actions here:
- merge stable into dev so all bugfixes are kept inside the code
- merge dev into stable to capture all new developments
Correct
Who is going to do this? Is this planned on the next day after the
feature freeze so we keep the timeframe of 'no new development' as
short as possible?
Shouldn't we merge stable into dev more frequent from now on? So we
limit the number of code conflicts while doing the final merge?
It should be done as quick as possible to keep things workable. Who? I'm
more then willing to do the merges on a part of the packages, but for
some of the optional packages it might be better if the actual
maintainers / current developers do it (weblcms, portfolio, assessment,
etc. come to mind)
There will always be merge conflicts I would guess. More frequent merges
would be better though ...
What about upgrade scripts to counter database changes?
That is going to take quite a bit of time I think, not in the least
because we need to index database changes and actually write the update
scripts. Additionally the system doesn't have an update wizard in the
same way that it has an install wizard. How do we want to handle these
updates?
What about the usability issues? Should we move them to next planned
release too?
Who is going to do this?
Yes, IMO they should all move to the next release. They might involve
things which lead to new features or advanced fixes / changes and thus
risk destabilizing what was stable before. The same could of course be
said about some bugs, but bugs are actual mistakes ... usability is more
in the realm of "improving things".
Right now there's 40-something projects on the support-website, right?
Using the filters and multi-actions it should be fairly easy to move the
issues, but who indeed wants to do it?
Best regards,
Hans
On 19/04/2011 14:23, Stefaan Vanbillemont wrote:
Hans & other dev team members,
Good idea! I follow the proposal. Here some more thoughts about the
details, a small list of questions and todo topics.
*1) Current developments*
We should make a list with all current development efforts on the
development repos. Who is going to collect that data, where should we
put it?
HoGent team? VUB team? EhB team? Geneva team? This should really be a
detailed list ( with issue numbers if possible)
Can we put that on the wiki page?
http://support.chamilo.org/projects/chamilo-20/wiki/Planning
*2) Feature freeze
*
Should we set a fixed date? 30 May is on a monday, or better on Friday
27 (with an IRC meeting to give the official call?) so we can have a
quick overview of last-minute change of plans.
We should check the list from section 1 and see if everybody is ready
with all his/her developments. Can we allow exceptions?
*3) Merge stable into dev -> merge dev into stable *
I see two actions here:
- merge stable into dev so all bugfixes are kept inside the code
- merge dev into stable to capture all new developments
Who is going to do this? Is this planned on the next day after the
feature freeze so we keep the timeframe of 'no new development' as
short as possible?
Shouldn't we merge stable into dev more frequent from now on? So we
limit the number of code conflicts while doing the final merge?
What about upgrade scripts to counter database changes?
*4) Update issues on support*
After the feature freeze we should update all issues on the support
projects:
- move all features to next planned release
- prioritize the remainig bug issues
What about the usability issues? Should we move them to next planned
release too?
Who is going to do this?
Regards,
Stefaan
Op 19/04/11 09:20, Hans De Bisschop schreef:
eting, we discussed the feature freeze / stabilization / release
planning of Chamilo a bit more. Since a few key players were not
available and since IRC is a non-official communication channel no
decision was made, but some suggestions were proprosed.
Currently the proposal is to have a feature freeze by the end of may
at which point the current dev repositories would be merged into the
stable. Once that process is completed the stable repos could be used
to finalize a release (later on this year, september maybe?) and
implement bugfixes. Any and every kind of other development could
then, once again, continue on the dev-repos. Lots of "details" still
need to be worked out, but we need to start with somethin ...
As per usual, more feedback is needed / required before we can move
ahead.
Best regards,
--
_______________________________________________
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
