Voting proposal
Cédric Krier
take place from 27-06-2010 to 03-07-2010.
Definitions:
- contribution: any code or xml data submit for commit into a repository of
Tryton.
- contributor name: the name of the contributor in the patch
- contributor email: the email address set by the contributor in the patch
- key words: http://tools.ietf.org/html/rfc2119
Proposals for vote:
- The contributor name must be the real name of the natural person who submit
the code
- The contributor email must be a valid email address
- The contributor email must be unique
- The domain of contributor email must not contain tryton
- The username of the mercurial patch must be in the form:
Name <email>
Discussion on this proposals and definitions is openned and will end at Jun 27
18:00:00 CEST 2010 [1].
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Bertrand Chenal
Cédric Krier <cedric...@b2ck.com> a écrit :
> Here is the proposal for vote on improving contribution requirements
> that will take place from 27-06-2010 to 03-07-2010.
>
> Definitions:
>
> - contribution: any code or xml data submit for commit into a
> repository of Tryton.
> - contributor name: the name of the contributor in the patch
> - contributor email: the email address set by the contributor in the
> patch
> - key words: http://tools.ietf.org/html/rfc2119
>
>
> Proposals for vote:
> - The contributor name must be the real name of the natural person
> who submit the code
>
> - The contributor email must be a valid email address
>
> - The contributor email must be unique
>
> - The domain of contributor email must not contain tryton
>
> - The username of the mercurial patch must be in the form:
>
> Name <email>
Some precision on how I see stuffs : Those 'must' rules are enforced
for each changeset of the repositories, so they can be expressed as
'should' rules for patch submissions. More practically: If a patch
(submitted to the bugtracker) does not observe one of the previous
points it may happens one of the following:
- The patch is simply ignored,
- The patch is rewritten from scratch,
- The contributor name is replaced and the patch is applied (in the
case of a trivial patch, there is no original work and no way of
rewriting it)
Which means that the rules are enforced for each patch that reach the
repositories.
Mathias Behrle
> Here is the proposal for vote on improving contribution requirements that will
> take place from 27-06-2010 to 03-07-2010.
>
> Definitions:
>
> - contribution: any code or xml data submit for commit into a repository of
> Tryton.
> - contributor name: the name of the contributor in the patch
> - contributor email: the email address set by the contributor in the patch
> - key words: http://tools.ietf.org/html/rfc2119
>
>
> Proposals for vote:
>
> - The contributor name must be the real name of the natural person who submit
> the code
>
> - The contributor email must be a valid email address
>
> - The contributor email must be unique
>
> - The domain of contributor email must not contain tryton
>
> - The username of the mercurial patch must be in the form:
>
> Name <email>
I propose to add all questions as 'should' to provide the choice, if a
question is 'required' (must) or if it is 'wished behavior' (should, i.e. for
questions, that cannot be enforced in reality like uniqueness of email).
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Mathias Behrle
> Le Sun, 20 Jun 2010 20:18:51 +0200,
> Cédric Krier <cedric...@b2ck.com> a écrit :
>
> > Here is the proposal for vote on improving contribution requirements
> > that will take place from 27-06-2010 to 03-07-2010.
> >
> > Definitions:
> >
> > - contribution: any code or xml data submit for commit into a
> > repository of Tryton.
> > - contributor name: the name of the contributor in the patch
> > - contributor email: the email address set by the contributor in the
> > patch
> > - key words: http://tools.ietf.org/html/rfc2119
> >
> >
> > Proposals for vote:
> > - The contributor name must be the real name of the natural person
> > who submit the code
> >
> > - The contributor email must be a valid email address
> >
> > - The contributor email must be unique
> >
> > - The domain of contributor email must not contain tryton
> >
> > - The username of the mercurial patch must be in the form:
> >
> > Name <email>
>
>
> Some precision on how I see stuffs : Those 'must' rules are enforced
> for each changeset of the repositories, so they can be expressed as
> 'should' rules for patch submissions.
I don't understand this paragraph. 'Should' rules change to 'Must' rules on
commit time? Then they are indeed 'Must' rules...
> More practically: If a patch
> (submitted to the bugtracker) does not observe one of the previous
> points it may happens one of the following:
>
> - The patch is simply ignored,
> - The patch is rewritten from scratch,
> - The contributor name is replaced and the patch is applied (in the
> case of a trivial patch, there is no original work and no way of
> rewriting it)
>
>
> Which means that the rules are enforced for each patch that reach the
> repositories.
Is this a proposal to discuss or is it a definition, while you are speaking here
in your functionality as maintainer?
Bertrand Chenal
Mathias Behrle <math...@mbsolutions.selfip.biz> a écrit :
> * Betr.: " Re: [tryton] Voting proposal" (Tue, 22 Jun 2010 13:04:18
> +0200):
>
> > Le Sun, 20 Jun 2010 20:18:51 +0200,
> > Cédric Krier <cedric...@b2ck.com> a écrit :
> >
> > > Here is the proposal for vote on improving contribution
> > > requirements that will take place from 27-06-2010 to 03-07-2010.
> > > [...]
> >
> > Some precision on how I see stuffs : Those 'must' rules are enforced
> > for each changeset of the repositories, so they can be expressed as
> > 'should' rules for patch submissions.
> > [...]
> I don't understand this paragraph. 'Should' rules change to 'Must'
> rules on commit time? Then they are indeed 'Must' rules...
Let me re-phrase my proposition:
1) To be applied on a repository, a changeset MUST contains the name
of a real person and a valid and unique email address.
2) Hence a submission of changeset on the bugtracker SHOULD contains
the name of a real person and a valid and unique email address. If the
submission doesn't observe this constraint, and in order to ensure
point 1), it MAY happen one of the following: The patch is simply
ignored or the patch is rewritten from scratch or he contributor name
is replaced and the patch is applied.
> >
> > Which means that the rules are enforced for each patch that reach
> > the repositories.
>
> Is this a proposal to discuss or is it a definition, while you are
> speaking here in your functionality as maintainer?
>
This is a proposal, with more details on what happens if a submission on
the bugtracker is invalid, more precise and IMO better than the
previous one. As such everybody is welcome to vote for it or against it
once the voting window opens.
And of course everybody is welcome to give a new proposal or to suggest
a variation of this one.
Bertrand
Juan Fernando Jaramillo
Here is the proposal for vote on improving contribution requirements that will
take place from 27-06-2010 to 03-07-2010.
Definitions:
- contribution: any code or xml data submit for commit into a repository of
Tryton.
- contributor name: the name of the contributor in the patch
- contributor email: the email address set by the contributor in the patch
- key words: http://tools.ietf.org/html/rfc2119
Proposals for vote:
- The contributor name must be the real name of the natural person who submit
the code
- The contributor email must be a valid email address
- The contributor email must be unique
- The domain of contributor email must not contain tryton
- The username of the mercurial patch must be in the form:
Name <email>
Who certify that the names, are real names? We must use pgp to confirm that! in Debian use it, I use to sing my emails with this keys, and I have the sign of a DD, and there are a net of certifications in Debian, but from few month I don't sign with such key. The idea is similar? If so, I thing that is a good Idea, but if not, you must to explain which method use.
Cédric Krier
Here, it is a matter of trust. I don't think we need to sign the changeset as
there are reviewed by the community. So there will be no risk about malicious
code insertion.
For now, we are very few people to have push access to the main repository so
we can trust those people (Bertrand and me :-).
But you can propose to have pgp signed submition of changeset inside roundup
or inside the changeset (if possible).
Mathias Behrle
Hi Bertrand,
> Le Fri, 25 Jun 2010 12:22:52 +0200,
> Mathias Behrle <math...@mbsolutions.selfip.biz> a écrit :
>
> > * Betr.: " Re: [tryton] Voting proposal" (Tue, 22 Jun 2010 13:04:18
> > +0200):
> >
> > > Le Sun, 20 Jun 2010 20:18:51 +0200,
> > > Cédric Krier <cedric...@b2ck.com> a écrit :
> > >
> > > > Here is the proposal for vote on improving contribution
> > > > requirements that will take place from 27-06-2010 to 03-07-2010.
> > > > [...]
> > >
> > > Some precision on how I see stuffs : Those 'must' rules are enforced
> > > for each changeset of the repositories, so they can be expressed as
> > > 'should' rules for patch submissions.
> > > [...]
> > I don't understand this paragraph. 'Should' rules change to 'Must'
> > rules on commit time? Then they are indeed 'Must' rules...
>
> Let me re-phrase my proposition:
>
> 1) To be applied on a repository, a changeset MUST contains the name
> of a real person and a valid and unique email address.
>
> 2) Hence a submission of changeset on the bugtracker SHOULD contains
> the name of a real person and a valid and unique email address. If the
> submission doesn't observe this constraint, and in order to ensure
> point 1), it MAY happen one of the following: The patch is simply
> ignored or the patch is rewritten from scratch or he contributor name
> is replaced and the patch is applied.
- You are separating stuff for different media of the project, which changes
(extends) the definition (Originally: - contribution: any code or xml data
submit for commit into a repository of Tryton.)
- Question 1 is just a summary of questions already exposed in the very first
proposal. There is nothing new in it.
- Do you want this proposal be handled in the final vote as one question (2
depends from 1)?
And to throw in my 2¢:
- I will not vote for a requirement, that I cannot enforce. Email unique (btw.
the definition of this term is lacking, I suppose it to be: unique user of an
email address) can not be controlled in any way. No need to enforce it.
- "...or the contributor name is replaced and the patch is applied."
Replaced with what? An ununique email address like anon_...@tryton.org? ;)
Strictly no for hijacking of patches with a maintainer address from me.
> > > Which means that the rules are enforced for each patch that reach
> > > the repositories.
> >
> > Is this a proposal to discuss or is it a definition, while you are
> > speaking here in your functionality as maintainer?
> >
>
> This is a proposal, with more details on what happens if a submission on
> the bugtracker is invalid, more precise and IMO better than the
> previous one. As such everybody is welcome to vote for it or against it
> once the voting window opens.
Since it changes the definition, it is another vote: the vote about the
definition.
Mathias
Chenal Bertrand
> Here is the proposal for vote on improving contribution requirements that will
> take place from 27-06-2010 to 03-07-2010.
>
> Definitions:
>
> - contribution: any code or xml data submit for commit into a repository of
> Tryton.
> - contributor name: the name of the contributor in the patch
> - contributor email: the email address set by the contributor in the patch
> - key words: http://tools.ietf.org/html/rfc2119
>
>
> Proposals for vote:
>
> - The contributor name must be the real name of the natural person who submit
> the code
>
> - The contributor email must be a valid email address
>
>
> - The contributor email must be unique
>
>
> - The domain of contributor email must not contain tryton
>
>
> - The username of the mercurial patch must be in the form:
>
> Name<email>
>
>
> Discussion on this proposals and definitions is openned and will end at Jun 27
> 18:00:00 CEST 2010 [1].
>
> [1] http://www.timeanddate.com/worldclock/fixedtime.html?day=27&month=6&year=2010&hour=18&min=0&sec=0&p1=48
>
>
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Li�ge
Belgium
Tel: +32 474 207 906
Email: bertran...@b2ck.com
Website: http://www.b2ck.com/
Carlos Perelló Marín
El 20/06/10 20:18, C�dric Krier escribi�:
> Here is the proposal for vote on improving contribution requirements that will
> take place from 27-06-2010 to 03-07-2010.
>
> Definitions:
>
> - contribution: any code or xml data submit for commit into a repository of
> Tryton.
> - contributor name: the name of the contributor in the patch
> - contributor email: the email address set by the contributor in the patch
> - key words: http://tools.ietf.org/html/rfc2119
>
>
> Proposals for vote:
>
> - The contributor name must be the real name of the natural person who submit
> the code
>
+1
> - The contributor email must be a valid email address
>
+1
> - The contributor email must be unique
>
+1
> - The domain of contributor email must not contain tryton
>
+1
> - The username of the mercurial patch must be in the form:
>
> Name<email>
>
+1
> Discussion on this proposals and definitions is openned and will end at Jun 27
> 18:00:00 CEST 2010 [1].
>
> [1] http://www.timeanddate.com/worldclock/fixedtime.html?day=27&month=6&year=2010&hour=18&min=0&sec=0&p1=48
>
>
--
Carlos Perell� Mar�n
[P+] SERVICIOS PROFESIONALES
http://www.pemas.es
mailto:car...@pemas.es || mailto:car...@gnome.org
Este mensaje y los ficheros anexos son confidenciales. Los mismos
contienen informaci�n reservada de la empresa que no puede ser
difundida. Si usted ha recibido este correo por error, tenga la
amabilidad de eliminarlo de su sistema y avisar al remitente mediante
reenv�o a su direcci�n electr�nica; no deber� copiar el mensaje ni
divulgar su contenido a ninguna persona.
Su direcci�n de correo electr�nico junto a sus datos personales forman
parte de un fichero titularidad de PEMAS Servicios Profesionales, S.L.
cuya finalidad es la de mantener el contacto con Ud. De acuerdo con la
Ley Org�nica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificaci�n, cancelaci�n y, en su caso, oposici�n enviando una
solicitud por escrito, acompa�ada de una fotocopia de su DNI dirigida a
PEMAS Servicios Profesionales, S.L. C/ Santos Justo y Pastor, 72 - 5,
C.P. 46022 de Valencia (Espa�a).