Stefaan,
I think that if that "works for" (=is agreed upon by) all those who have
to / want to migrate this summer, I'll be the last to complain and/or
disagree.
Best regards,
Hans
On 13/04/2011 15:12, Stefaan Vanbillemont wrote:
Hans,
I understand the situation we have right now is not desirable and only
temporary. I know a lot of these essential features are still in
development and should be in the next stable release :-)
Can we make a proposal?
step 1: merge frequently the stable into dev (until the day before
step 2), current developments should be finished and testend by then
(make list of current developments on dev repos), no new feature
development may start as of today/week (I want to contact all current
developers and summarize their planning).
step 2: merge dev repos into stable repos (end may/begin June), new
development can start again on development repos
step 3: stabilize (bugfixing) the stable repos (organisations that
want can use this stable repos in production)
step 4: new release (end of the summer?)
That way, all organisations that want to migrate this summer, or start
in production next academic year have a set of stable repos to work
on. And it gives us some more time to prepare the simultaneous release.
What do you think?
Kind Regards,
Stefaan
Op 13/04/11 14:15, Hans De Bisschop schreef:
Hi Stefaan,
A new simultaneous release sometime around end May/June? Considering
all the new features being developed and refactoring being done
that's .... optimistic ... or is our simultaneous release going to be
nothing more then a packaging of the current stable branches (so
without any of the new essential and urgent features)? I was under
the impression those features were essential for those institutions
migrating this summer.
All applications / packages which were in the first release were
marked as 1.0.0. A next release could be a 1.1.0 or a 2.0.0,
depending on the scope of the improvements / changes. It's up to
every team or person responsible for a package to determine that. It
might be the easiest to add a 1.0.0 for all projects right now for
everything that was done prior to release of said packages (or even
the Beta and RC flavours if we want to keep the backlog that
detailed) and a 2.0.0 beta and 2.0.0 stable for the upcoming
release. Additionally maybe a 3.0.0 for things which are on the
horizon but not a priority for the upcoming release. It's not up to
me to determine it, the aforementioned is just a suggestion, which -
and I'm certain of that - in some cases is not the best solution.
As for "who is doing what where by which date" ... that should go on
the wiki for now. It might be best for every developer / institution
to just add a page or add their activities to a page which can serve
as a general overview. I would keep the list pretty straightforward:
package, estimated deadline and maybe a short description of what is
being done.
Dates depend a lot on whether and when an agreement can be reached on
the primary topics. An IRC meeting is fine by me ...
Best regards,
Hans
On 13/04/2011 13:55, Stefaan Vanbillemont wrote:
Hans,
Can we start by defining some version numbers for the different
packages/applications & dates for the next releases? So we can move
issues/feature requests? It should make it all a bit clear for
everybody to see the work left in the different applications.
As I see it right now we should have a new simultanious release
sometime around end May/June? So all institutions that want to
migrate this summer have a new stable release with lots of bugfixes.
-Who is busy developing on the dev? fixing on stable? Who is doing
what? Deadlines?
- Date for feature freeze on dev repos? Branching all current dev
repos into a future-stable line?
- Settings a date to merge current stable into dev/future-stable line?
- What should be the composition of that release? What optional apps
should be included?
- Who will test the future stable release?
- Date to release the package? Who will package it?
Lots of questions right now ..
We have to make some decisions here, maybe we can organize an IRC
meeting about it in the next days?
Stefaan.
Op 12/04/11 14:56, Hans De Bisschop schreef:
Stefaan,
As software coordinator I strongly believe this is the only future
that can work to sustain the project / product. It goes without
saying of course, that this can only work if and when everyone
agrees to the rules of the game AND actually follows them ... and
it obviously applies to BOTH the core AND the optional
applications. As cruel as it may sound: "playtime" is over and we
need to come to some kind of consensus or agreement on this as soon
as possible.
Best regards,
Hans
On 12/04/2011 10:03, Stefaan Vanbillemont wrote:
Systho,
I follow your workflow but I have 1 remark, If a package is not
ready/candidate for simultaneous release you go back to an
implementation fase and then to a 'release ready' fase.
Shouldn't it go into the bugfix/stabilized/documentation fase??
We should put some more energy into this discussion, what about
the other developers? Hans, as software coordinator, can you see
some future in this?
We could/should try to set some milestones for the next year and
try this workflow.
Can we discuss this on a next dev meeting?
Kind Regards,
Stefaan
Op 8/04/11 15:00, Philippe Van Eerdenbrugghe schreef:
As asked, here is a workflow presenting the release planning
proposition (I didn't put dates on purpose in order to keep it
focused on transitions)
http://support.chamilo.org/projects/chamilo-20/wiki/Planning
Systho
_______________________________________________
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
--
*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
--
*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
--
*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
