Proposal for the development cycle

[Farzad Sehat]

M. Farzad Sehat
farzad.sehat at gmail.com


2009/11/13 Mildred Ki'Lya <ml.mildred593 at gmail.com>

>  On 11/13/2009 05:09 PM, Farzad Sehat wrote:
>
>
>>  I absolutely agree with this point of view, our community is not big
> enough and moreover
> there is a lot of work to be done in the documentation. 2 release per year
> is too much and
> we have to favour quality.
> As Xavier said we have to freeze the stable 2 or 3 month before release in
> order to have a high
> quality release.
> The key feature is to make regular and complete report to benoit about the
> feature each member is developping.
> This way benoit can merge them more easely and more efficiently to the
> master branch and moreover he can merge
> to the stable branch more often. Indeed a good communication about all
> developping features let Ben to work
> better and to have fewer bug when freezing the stable.
>
>
> Ok, perhaps big releases is not such a good idea, i'm willing to admit
> that.
>
> But I think we should, at least internally, have more than one release a
> year. Those wouldn't be much publicized, and will be only for Lisaac
> enthusiasts. I don't think we can yet produce high quality releases (the
> language itself doesn't yet meet my criteria of quality). But I think we
> should be more dynamic. Without doing much, we can create a momentum that
> could carry us much further.
>
> It's also important for us psychologically to see things moving. If we can
> say that 3 month before, the compiler was missing this and that feature but
> now, it's available. It helps us keep the faith in what we do and keep
> moving.
>
>
>
If all team member respect the new policy we will have internaly release
often. So what i mean by internally realease ? The word STABLE means STABLE
not changing every day or every hour. In the new policy the master
developpement is made by Ben in the master branch. We help him by making new
features in our name_feature branch and he takes them if he want to evolve
the master branch, then regulary, more than once a year, he makes Internal
release in the stable branch. And when the stable branch corresponds to the
public release quality we make a public release.
So the new cycle of developpement, not only make the team more dynamic, but
it make us also more responsable about our way
to contribute to the project. Moreover this way each public release will be
a high quality release beacause it will be the result of
several internal releases.



>
> Also, that's a little off topic here, but I think we should include in the
> source directory a changelog file. Each new release will be added in it, and
> each new feature as well. Features should make reference to git commits so
> those who want to review them (Ben?) can see what exactly has been done. Any
> other commit should be trivial enough.
>

In the compiler branch there is also a changelog and Ben will update it each
time he integrate a new feature. Otherwise, it s a good idea to have a
changelog in each name_feature branch in order to make Ben's work easier by
providing him what we are developping. This changelog should contains a real
description of each feature the team member is developping for a better
comprehension.


>
>
>
> Mildred
>
> --
> Mildred Ki'Lya
> ╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
> │ Jabber, GoogleTalk: <mildred at jabber.fr> <mildred at jabber.fr>
> │ Website: <http://ki.lya.online.fr> <http://ki.lya.online.fr>           GPG ID: 9A7D 2E2B
> │ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
>
>
> _______________________________________________
> Lisaac-devel mailing list
> Lisaac-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/lisaac-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20091114/a057b83a/attachment.htm>