Hans,
A small summary:
- if you have a template ready I can start with adding the HoGent stuff
on the wiki. VUB/EhB/Geneva should do the same ..
- Monday 30 may it is! FEATURE FREEZE! A list of what packages are going
into a feature freeze mode is really important for all users/developers.
So there is no misunderstanding.
- New simultanious release is sheduled for September 2011
- Hans does the merge for the core packages, VUB does the merge of
Portfolio/Handbook/Metadata, HoGent does the merge of all the rest of
the optional apps. It should happen on monday 30 may/tuesday 31 may.
- I want to do the main maintenance of the feature freeze (moving all
issues/usability issues to a later release version)
Nathalie? Laurent? Jens? As you are the other core developers, are you
ok with this approach/planning?
Regards,
Stefaan
Op 19/04/11 20:57, Hans De Bisschop schreef:
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
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
