Fine by me! I think we have already started implementing all the features we wanted for our pilot in September, so no problem.
I will make a list of all the features we are still currently working on. Op 04/21/2011 09:59 AM, Stefaan Vanbillemont schreef: > 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
_______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev
