futuro do desenvolvimento do noosfero: processo e novos committers

Tue Jan 6 10:52:32 BRST 2015

Parabéns acho que ficou muito bom ;)
Em 06/01/2015 07:20, "Antonio Terceiro" <terceiro em colivre.coop.br> escreveu:

> A gente tem discutido bastante na Colivre sobre a necessidade de
> flexibilizar o desenvolvimento no Noosfero. Com esta mensagem a gente
> inicia esse processo.
>
> Acabei de dar push de uma documentação para o processo de
> desenvolvimento que vai valer daqui para a frente:
>
> https://gitlab.com/noosfero/noosfero/blob/2bdb49acc2f9faa5e88a94b256c9359b2366a165/DEVELOPMENT.md
>
> Segue o conteúdo inline. Ao final dele tem alguns pontos extras.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> # Noosfero Development Policy
>
> ## Developer Roles
>
> * *Developers* are everyone that is contributing code to Noosfero.
> * *Committers* are the people with direct commit access to the Noosfero
> source
>   code. They are responsible for reviewing contributions from other
> developers
>   and integrating them in the Noosfero code base. They are the members of
> the
>   [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
> * *Release managers* are the people that are managing the release of a new
>   Noosfero version and/or the maintainance work of an existing Noosfero
> stable
>   branch. See MAINTAINANCE.md for details on the maintaince policy.
>
> ## Development process
>
> * Every new feature or non-trivial bugfix should be reviewed by at least
> one
>   committer. This must be the case even if the original author is a
> committer.
>
>   * In the case the original author is a committer, he/she should feel
> free to
>     commit directly if after 1 week nobody has provided any kind of
> feedback.
>
> * Committers should feel free to push trivial (or urgent) changes directly.
>   There are no strict rule on what makes a change trivial or urgent;
> committers
>   are expected to exercise good judgement on a case by case basis.
>
>   * Usually changes to the database are not trivial.
>
> * In the case of unsolvable conflict between commiters regarding any
> change to
>   the code, the current release manager(s) will have the final say in the
>   matter.
>
> * Release managers are responsible for stablishing a release schedule, and
>   about deciding when and what to release.
>
>   * Release managers should announce release schedules to the project
> mailing
>     lists in advance.
>
>   * The release schedule may include a period of feature freeze, during
> which
>     no new features or any other changes that are not pre-approved by the
>     release manager must be committed to the repository.
>
>   * Committers must respect the release schedule and feature freezes.
>
> ## Maintainance process
>
> ### Not all feature releases will be maintained as a stable release
>
> We will be choosing specific release series to be maintained as stable
> releases.
>
> This means that a given release is not guaranteed to be maintained as a
> stable
> release, but does *not* mean it won't be. Any committer (or anyone,
> really) can
> decide to maintain a given release as stable and seek help from others to
> do
> so.
>
> ### No merges from stable branches to master
>
> *All* changes must be submitted against the master branch first, and when
> applicable, backported to the desired stable releases. Exceptions to this
> rules
> are bug fixes that only apply to a given stable branch and not to master.
>
> In the past we had non-trivial changes accepted into stable releases while
> master was way ahead (e.g. during the rails3 migration period), that made
> the
> merge back into master very painful.  By eliminating the need to do these
> merges, we save time for the people responsible for the release, and
> eliminate
> the possibility of human errors or oversights causing changes to be
> accepted
> into stable that will be a problem to merge back into master.
>
> By getting all fixes in master first, we improve the chances that  a future
> release will not present regressions against bugs that should already be
> fixed,
> but the fixes got lost in a big, complicated merge (and those won't exist
> anymore, at least not from stable branches to master).
>
> After a fix gets into master, backporting changes into a stable release
> branch
> is the responsibility of whoever is maintaing that branch, and those
> interested
> in it. The stable branch release manager(s) are entitled the final say on
> any
> matters related to that branch.
>
> ## Apendix A: how to become a committer
>
> Every developer that wants to be a committer should create [an issue on
> Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be
> added as
> a committer. This request must include information about the requestor's
> previous contributions to the project.
>
> If 2 or more commiters consider second the request, the requestor is
> accepted
> as new commiter and added to the Noosfero group.
>
> The existing committers are free to choose whatever criteria they want to
> second the request, but they must be sure that the new committer is a
> responsible developer and knows what she/he is doing. They must be aware
> that
> seconding these requests means seconding the actions of the new committer:
> if
> the new committer screw up, her/his seconds screwed up.
>
> ## Apendix B: how to become a release manager
>
> A new release manager for the development version of Noosfero (i.e. the one
> that includes new features, a.k.a. the master branch) is apointed by the
> current release manager, and must be a committer first.
>
> Release managers for stable branches are self-appointed, i.e. whoever
> takes the
> work takes the role. In case of a conflict (e.g. 2+ different people want
> to do
> the work but can't agree on working together), the development release
> manager
> decides.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Estou postando aqui na lista em português porque sendo realista no
> momento o desenvolvimento do Noosfero está restrito ao Brasil, então não
> faz sentido a gente discutir entre a gente em inglês.
>
> Basicamente o texto documenta como a coisa já funciona, e adiciona como
> a gente pensou que deve funcionar a entrada de novos committers. Para
> fazer o bootstrap da entrada de novos committers, a gente dicidiu
> oferecer uma exceção ao processo acima para as seguintes pessoas:
>
> - Larissa Reis
> - Victor Costa
> - Braulio Bhavamitra
> - Leandro Nunes dos Santos
> - Aurelio A. Heckert
>
> Essa exceção consiste no seguinte: essas pessoas não precisam que 2
> outros committers apoiem a sua solicitação; basta pedir que a gente
> aceita automaticamente. A partir daí, elas passam a poder apoiar novos
> committers também, pelo processo normal.
>
> Atualmente o papel de release manager é meu.
>
> --
> Antonio Terceiro <terceiro em colivre.coop.br>
> Colivre - Cooperativa de Tecnologias Livres
> http://www.colivre.coop.br/
>
>
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br em listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20150106/7d2974cb/attachment.html>