Contribution guidelines
Bertrand Chenal
Has said on the irc channel this thread will be used to talk about
some guidelines/processes.
Those guidelines concern:
- Patch submission
- Module submission
- Translations (modules, client and server)
- News submission and translation
Has explained on the wiki[1] the project is structured around
sub-projects, each sub-project is managed by a leader. So the
guidelines should also concern:
- how to become sub-project leader
- what is the job and responsibilities of a leader
Objectives:
Those guidelines are there to simplify the project organization. They
are needed to avoid to always repeats how stuffs work and also to
overcome or at least mitigate the communication problems. This is
important because communication overhead will get bigger and bigger as
the number of participant increase.
For example, I would like to avoid situations where some submission
get stuck because several people are waiting for each other to make
the following step.
The guidelines should stay as short as possible. They are there to
clarify and speed up the most common processes.
I will propose my version of these guidelines in a future mail on this
thread, as usual everyone is invited to contribute.
[1] http://code.google.com/p/tryton/wiki/ProjectOrganization
--
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/
Timitos
i appreciate this step.
I think a short descriptive summary of every process would be very
helpful. After this summary one can add some more informations about
details.
I volunteer to create such a summary on the wiki site
'HowToContribute" if you agree that it is helpful.
But i will wait for your guideline email first.
Korbinian
> Website:http://www.b2ck.com/
Hartmut Goebel
Timitos schrieb:
> i appreciate this step.
Me too, esp. since some of my patches are idling in roundup :-\
> I volunteer to create such a summary on the wiki site
> 'HowToContribute" if you agree that it is helpful.
Thanks in advance
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne:
<http://www.all-about-security.de/kolumnen/cissp-gefluester/>
Goebel Consult mit Mitglied bei <http://www.7-it.de>
Bertrand Chenal
Hereafter you will find our proposal for the contribution guidelines. As
usual everyone is invited to comment.
Timitos: I don't think a description in the wiki is needed as imho the
guidelines are the description of the contributions and if something is
missing or not clear it should be added to the guidelines themselves. It
will also avoid to spread information across several places.
Project Leader
**************
I start to define the role of the (sub-)project leaders as it will
determine most of the guidelines. As explained in the wiki each module
is a project, the Tryton server, the Tryton client, each translation
of Tryton (server, client and modules) and each translation of the
website are all projects. There is also the Tryton (meta-)project
leaded by Cédric (aka the Tryton Bdfl[1]). He has the final decision
on all the issues that affect the project as a whole or if there are
problems between (sub-)project leaders.
The main role of a leader is to centralise and coordinate the work
made on his project. He is responsible for the day to day operations
and for the organisation of the contributions. When needed, he is also
the person that make the decision when no agreement are possible on
controversial situations.
If a leader fail to do his tasks, the project is considered
orphaned. The task for a module leader are:
- Provide bugfixes and new features.
- Collect and apply patches with bugfixes and new features.
- Backport bugfixes to older releases.
- Submit news when major modification have been made.
- Create new releases following the release rules[2].
The task for a Tryton translation leader are:
- Provide translation for new modules or when modification are made to
existing modules for each release.
- Centralise translations from other contributors if any.
The tasks for a website/news language leader are:
- Centralise news in their language from other contributors.
- Translate news from their language to English.
- Translate news and website modifications from English to their
language.
If a project is orphaned anybody can ask to be the new leader. If
there are several applications for the same project the new leader is
chosen by the Bdfl.
If no leader are available for a project when the release process
starts (see [2]), the project is dropped.
Patch Submission
****************
A patch can be a bugfix, a new feature, a documentation update or a
code refactoring.
Patch submission follow these steps:
- Ideally the submitter talk about the patch with the corresponding
leader before writing it. When the patch is in progress or nearly
finished, the patch can be uploaded on Rietveld[3] to ease the
communication about implementation details.
- An issue is opened on the tracker with the patch as attachment and
a comment describing what it does. The patch must be a text file if
only text files are modified and a mercurial bundle otherwise.
- If the patch is accepted, the patch is applied by the leader. If not
the leader may close the issue (if the idea behind the patch is not
right) or ask for improvements (if the implementation is not right).
To be accepted, a patch must:
- Follow the guidelines.
- Be atomic. More precisely a patch should correspond to one and only
one bugfix, one new feature, one documentation update or one code
refactoring.
- Be relative to the current mercurial version. Applying the patch on
the current version of the repository should work without
modifications.
- Make sense with respect to the underlying code (I.E. sometimes it's
better to create a new module than to add code to an existing module).
Module Submission
*****************
As for patch submission the best is to talk about the future module
with other members of the community. The submission follow these
steps:
- An issue that ask for comments is opened on the tracker with a link
to an active mercurial repository of the module.
- Once the talks are considered over, the submitter ask (with a
comment on the issue) the Tryton Bdfl to publish the module.
- The module is published if the following conditions are met:
- The module isn't redundant with an existing module,
- the module provides features that are useful for at least one
situation,
- there are no obvious improvement to be made,
- the module doesn't raise major objection and
- there is a volunteer to be the module leader.
News Submission
***************
The process for news submission works as follow:
- One of the leader propose a topic and propose himself or one member
of his language community as writer. The news must potentially
interest a large part of the Tryton community. For those proposals
we will create a private mailing that will be dedicated to
centralise talks about the news
- The news is written and the draft is reviewed by the news leaders.
- Once the leaders have made the review, the news is translated and
published in each language.
[1] http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
[2] http://code.google.com/p/tryton/wiki/ReleaseGeneral
[3] http://codereview.appspot.com/
--
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/
Hartmut Goebel
here are my comments:
Bertrand Chenal schrieb:
> Timitos: I don't think a description in the wiki is needed as imho the
> guidelines are the description of the contributions and if something is
IMHO the guidelines have to be in the wiki, since this is where
contributors will search it. And the Guidelines have to be verbose
enough to be understood by every medium-experienced developers.
> - Ideally the submitter talk about the patch with the corresponding
> leader before writing it. When the patch is in progress or nearly
> finished, the patch can be uploaded on Rietveld[3] to ease the
> communication about implementation details.
Please clarify "can". Is it pure optional? Is it suggested or required?
(Please have a look at the RFCs definitions of SHOULD, MUST, MAY, etc.
found at the beginning of every current RFC)
Please provide a short introduction into Rietveld, since most
contributors will not know it by now. (In deed, Tryton is the very first
project I know to use it and I never ever heard of it before.
Should changes to the website be but on Rietveld, too?
> - An issue is opened on the tracker with the patch as attachment and
> a comment describing what it does. The patch must be a text file if
> only text files are modified and a mercurial bundle otherwise.
Please clarify: Who is opening the issue? Which "type" should it have?
Should it be assigned to the sub-project leader? Who is in charge of
assigning it? How to submit a bundle of patches (as I did in issue1100)?
(Uploading 20 separate patches is tremulous, an downloading them is it
too.)
Are changes to the website to be treated the same? Who is in charge of
merging the change into the other language websites?
> - If the patch is accepted, the patch is applied by the leader. If not
> the leader may close the issue (if the idea behind the patch is not
> right) or ask for improvements (if the implementation is not right).
Please add: The sub-project leader is in charge of keeping the
originating contributor as submitter if possible. Otherwise hae has to
state the original author in the changelog.
> To be accepted, a patch must:
> - Follow the guidelines.
Please clarify: Which "the guidelines"?
> - Be atomic. More precisely a patch should correspond to one and only
> one bugfix, one new feature, one documentation update or one code
> refactoring.
Please clarify: Should larger refactoring (as in issue 1100) be
submitted as a single, big patch? Should each "mini-patch" go into a
separate issue or should they be bundled into into one issue?
> Module Submission
[...]
> - An issue that ask for comments is opened on the tracker with a link
> to an active mercurial repository of the module.
I do not understand this sentence.
Please clarify: How the module is put into which branch (1.0, 1.2,
devel)? How is tagging to be handles? Will new module be put into
hg.tryton.org?
Cédric Krier
> Hi,
>
> here are my comments:
>
> Bertrand Chenal schrieb:
>
> > Timitos: I don't think a description in the wiki is needed as imho the
> > guidelines are the description of the contributions and if something is
>
> IMHO the guidelines have to be in the wiki, since this is where
> contributors will search it. And the Guidelines have to be verbose
> enough to be understood by every medium-experienced developers.
>
> > - Ideally the submitter talk about the patch with the corresponding
> > leader before writing it. When the patch is in progress or nearly
> > finished, the patch can be uploaded on Rietveld[3] to ease the
> > communication about implementation details.
>
> Please clarify "can". Is it pure optional? Is it suggested or required?
> (Please have a look at the RFCs definitions of SHOULD, MUST, MAY, etc.
> found at the beginning of every current RFC)
>
> Please provide a short introduction into Rietveld, since most
> contributors will not know it by now. (In deed, Tryton is the very first
> project I know to use it and I never ever heard of it before.
http://code.google.com/p/rietveld/wiki/CodeReviewHelp
Already in http://code.google.com/p/tryton/wiki/HowtoContribute
>
> Should changes to the website be but on Rietveld, too?
Why not.
> > - An issue is opened on the tracker with the patch as attachment and
> > a comment describing what it does. The patch must be a text file if
> > only text files are modified and a mercurial bundle otherwise.
>
> Please clarify: Who is opening the issue? Which "type" should it have?
mercurial changeset.
> Should it be assigned to the sub-project leader? Who is in charge of
It is explain in http://code.google.com/p/tryton/wiki/HowtoContribute
> assigning it? How to submit a bundle of patches (as I did in issue1100)?
You don't.
> (Uploading 20 separate patches is tremulous, an downloading them is it
> too.)
>
> Are changes to the website to be treated the same? Who is in charge of
Yes.
> merging the change into the other language websites?
I don't understand.
> > - If the patch is accepted, the patch is applied by the leader. If not
> > the leader may close the issue (if the idea behind the patch is not
> > right) or ask for improvements (if the implementation is not right).
>
> Please add: The sub-project leader is in charge of keeping the
> originating contributor as submitter if possible. Otherwise hae has to
> state the original author in the changelog.
If the changeset works and is correct, it will be.
> > To be accepted, a patch must:
> > - Follow the guidelines.
>
> Please clarify: Which "the guidelines"?
http://code.google.com/p/tryton/wiki/CodingGuidelines
>
> > - Be atomic. More precisely a patch should correspond to one and only
> > one bugfix, one new feature, one documentation update or one code
> > refactoring.
>
> Please clarify: Should larger refactoring (as in issue 1100) be
> submitted as a single, big patch? Should each "mini-patch" go into a
> separate issue or should they be bundled into into one issue?
One fix = one changeset
> > Module Submission
> [...]
> > - An issue that ask for comments is opened on the tracker with a link
> > to an active mercurial repository of the module.
>
> I do not understand this sentence.
An issue asking for comments is opened...
>
> Please clarify: How the module is put into which branch (1.0, 1.2,
It depends of the branch for which the module is.
> devel)? How is tagging to be handles? Will new module be put into
> hg.tryton.org?
It is the purpose of module submission.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Udo Spallek
Am Freitag, den 24.07.2009, 00:06 +0200 schrieb Hartmut Goebel:
> > - Ideally the submitter talk about the patch with the corresponding
> > leader before writing it. When the patch is in progress or nearly
> > finished, the patch can be uploaded on Rietveld[3] to ease the
> > communication about implementation details.
>
> Please clarify "can". Is it pure optional? Is it suggested or required?
> (Please have a look at the RFCs definitions of SHOULD, MUST, MAY, etc.
> found at the beginning of every current RFC)
FYI http://www.faqs.org/rfcs/rfc2119.html
Regards
Udo Spallek
--
____________________________________
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
Bertrand Chenal
> Hi,
>
> Am Freitag, den 24.07.2009, 00:06 +0200 schrieb Hartmut Goebel:
>>> - Ideally the submitter talk about the patch with the corresponding
>>> leader before writing it. When the patch is in progress or nearly
>>> finished, the patch can be uploaded on Rietveld[3] to ease the
>>> communication about implementation details.
>> Please clarify "can". Is it pure optional? Is it suggested or required?
>> (Please have a look at the RFCs definitions of SHOULD, MUST, MAY, etc.
>> found at the beginning of every current RFC)
> FYI http://www.faqs.org/rfcs/rfc2119.html
>
> Regards
> Udo Spallek
Yes, good idea, I will re-factor the content to follow those rules once
we agree on the content. In the meanwhile, the occurrences of "can" must
be read as "may", the two occurrence of "should" must be read as "must".
I will also add a link to Reitveld.
Mathias Behrle
+0200):
Just contributing some small aspects before going to vacancy, hopefully his
discussion will last more than 2 weeks...;)
> Timitos: I don't think a description in the wiki is needed as imho the
> guidelines are the description of the contributions and if something is
> missing or not clear it should be added to the guidelines themselves. It
> will also avoid to spread information across several places.
It is not as important on how many pages the information is spread, provided it
is good linked together and most important explicit enough to answer almost all
questions of a newcomer.
> Project Leader
> **************
>
> I start to define the role of the (sub-)project leaders as it will
> determine most of the guidelines. As explained in the wiki each module
> is a project, the Tryton server, the Tryton client, each translation
> of Tryton (server, client and modules) and each translation of the
> website are all projects. There is also the Tryton (meta-)project
> leaded by Cédric (aka the Tryton Bdfl[1]). He has the final decision
> on all the issues that affect the project as a whole or if there are
> problems between (sub-)project leaders.
>
> The main role of a leader is to centralise and coordinate the work
> made on his project. He is responsible for the day to day operations
> and for the organisation of the contributions. When needed, he is also
> the person that make the decision when no agreement are possible on
> controversial situations.
>
> If a leader fail to do his tasks, the project is considered
> orphaned. The task for a module leader are:
>
> - Provide bugfixes and new features.
> - Collect and apply patches with bugfixes and new features.
> - Backport bugfixes to older releases.
> - Submit news when major modification have been made.
> - Create new releases following the release rules[2].
The Release Rules should be clarified to give the exact steps to take for a
release. E.g. I am missing the exact explanation how modules should be packed,
what is mandatory to be included (CHANGELOG), how the release process shall
work when modules are copied over to a new branch (there is interfering
leadership between repos maintainer and module maintainer), how module packages
have to be submitted...
> The task for a Tryton translation leader are:
>
> - Provide translation for new modules or when modification are made to
> existing modules for each release.
> - Centralise translations from other contributors if any.
>
> The tasks for a website/news language leader are:
>
> - Centralise news in their language from other contributors.
> - Translate news from their language to English.
> - Translate news and website modifications from English to their
> language.
Here again we have a case of interfering leaderships:
Since for example the website repos (www.tryton.org) is a project of b2ck, they
also provide the translation interface, which by its construction of
strict translation sentence by sentence currently is not very good to
reflect properties of some languages.
I am also missing statements about the contribution of website content.
The job of a translator is somewhat related to the content he should translate.
Just speaking for me: it is currently not very attractive to translate content,
that I couldn't review (like you are planning for news) and that I have to
accept just *as is* (and for what others and me sometimes have other notions or
proposals).
Depending a little bit on the future possibility to contribute content I
eventually would favour another setup: for language communities providing an
own community site/portal just leave tryton.org in English and point the
language link to the site of the language community (of course only if the
community wishes to do it that way).
> If a project is orphaned anybody can ask to be the new leader. If
> there are several applications for the same project the new leader is
> chosen by the Bdfl.
>
> If no leader are available for a project when the release process
> starts (see [2]), the project is dropped.
The project is dropped as a whole or only on dev and new release branches?
> Patch Submission
> ****************
>
> A patch can be a bugfix, a new feature, a documentation update or a
> code refactoring.
>
> Patch submission follow these steps:
>
> - Ideally the submitter talk about the patch with the corresponding
> leader before writing it. When the patch is in progress or nearly
> finished, the patch can be uploaded on Rietveld[3] to ease the
> communication about implementation details.
> - An issue is opened on the tracker with the patch as attachment and
> a comment describing what it does. The patch must be a text file if
> only text files are modified and a mercurial bundle otherwise.
> - If the patch is accepted, the patch is applied by the leader. If not
> the leader may close the issue (if the idea behind the patch is not
> right) or ask for improvements (if the implementation is not right).
>
> To be accepted, a patch must:
> - Follow the guidelines.
> - Be atomic. More precisely a patch should correspond to one and only
> one bugfix, one new feature, one documentation update or one code
> refactoring.
> - Be relative to the current mercurial version. Applying the patch on
> the current version of the repository should work without
> modifications.
It would be good to have some sort of timeline for submissions. It is hardly
possible to be relative to the current mercurial version if you don't get
feedback.
> - Make sense with respect to the underlying code (I.E. sometimes it's
> better to create a new module than to add code to an existing module).
>
>
> Module Submission
> *****************
>
> As for patch submission the best is to talk about the future module
> with other members of the community. The submission follow these
> steps:
>
> - An issue that ask for comments is opened on the tracker with a link
> to an active mercurial repository of the module.
> - Once the talks are considered over, the submitter ask (with a
> comment on the issue) the Tryton Bdfl to publish the module.
Timeline? (see above)
> - The module is published if the following conditions are met:
>
> - The module isn't redundant with an existing module,
> - the module provides features that are useful for at least one
> situation,
> - there are no obvious improvement to be made,
> - the module doesn't raise major objection and
> - there is a volunteer to be the module leader.
>
>
> News Submission
> ***************
>
> The process for news submission works as follow:
>
> - One of the leader propose a topic and propose himself or one member
> of his language community as writer. The news must potentially
> interest a large part of the Tryton community. For those proposals
> we will create a private mailing that will be dedicated to
> centralise talks about the news
I suppose you are speaking about a mailing *list*? I think to be able to follow
changes of different news contributors and to ease contribution it would be
better to have some sort of version controlled interface like a wiki for the
news content itself.
> - The news is written and the draft is reviewed by the news leaders.
> - Once the leaders have made the review, the news is translated and
> published in each language.
>
>
> [1] http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
> [2] http://code.google.com/p/tryton/wiki/ReleaseGeneral
> [3] http://codereview.appspot.com/
Cheers,
Mathias Behrle
Bertrand Chenal
> * Betr.: " [tryton] Re: Contribution guidelines" (Thu, 23 Jul 2009 17:09:29
> +0200):
>
> Just contributing some small aspects before going to vacancy, hopefully his
> discussion will last more than 2 weeks...;)
>
>> Timitos: I don't think a description in the wiki is needed as imho the
>> guidelines are the description of the contributions and if something is
>> missing or not clear it should be added to the guidelines themselves. It
>> will also avoid to spread information across several places.
>
> It is not as important on how many pages the information is spread, provided it
> is good linked together and most important explicit enough to answer almost all
> questions of a newcomer.
Yes, in my mind (but I forgot to tell it), the content of the guidelines
should appear on the website because by nature they are not subject to
frequent modifications. On the contrary, the page with the listing of
modules and leader will (hopefully) evolve.
But I wouldn't have any objections of putting the contribution
guidelines on the wiki given that all other pages (code guidelines,
release process, sub-projects) are already on the wiki.
Yes, the page describing the release rule must be improved, atm the only
documentation are the mercurial logs themselves. For the interfering
leadership, I'm not sure to understand your point but for info the
module leader will have commit access on the main repository.
>> The task for a Tryton translation leader are:
>>
>> - Provide translation for new modules or when modification are made to
>> existing modules for each release.
>> - Centralise translations from other contributors if any.
>>
>> The tasks for a website/news language leader are:
>>
>> - Centralise news in their language from other contributors.
>> - Translate news from their language to English.
>> - Translate news and website modifications from English to their
>> language.
>
> Here again we have a case of interfering leaderships:
> Since for example the website repos (www.tryton.org) is a project of b2ck, they
> also provide the translation interface, which by its construction of
> strict translation sentence by sentence currently is not very good to
> reflect properties of some languages.
Would a paragraph by paragraph translation be better or the only
solution for you would be a page by page translation ?
> I am also missing statements about the contribution of website content.
>
> The job of a translator is somewhat related to the content he should translate.
> Just speaking for me: it is currently not very attractive to translate content,
> that I couldn't review (like you are planning for news) and that I have to
> accept just *as is* (and for what others and me sometimes have other notions or
> proposals).
This will be the role of the mailing list that is talked hereafter.
> Depending a little bit on the future possibility to contribute content I
> eventually would favour another setup: for language communities providing an
> own community site/portal just leave tryton.org in English and point the
> language link to the site of the language community (of course only if the
> community wishes to do it that way).
Imho the community websites are not the same as the simple translation
of tryton.org and there is already a link to the community website. So
for me your proposition is just "drop the website translation". I think
that we should always keep a minimal set of pages that are available in
all languages.
>> If a project is orphaned anybody can ask to be the new leader. If
>> there are several applications for the same project the new leader is
>> chosen by the Bdfl.
>>
>> If no leader are available for a project when the release process
>> starts (see [2]), the project is dropped.
>
> The project is dropped as a whole or only on dev and new release branches?
The best would be of course to continue to maintain older releases if
they exist. Maybe one should define a intermediate state between
'active' and 'orphaned', but I'm not sure we will encounter this problem
one day.
What would be the timeline? Depending of the context, an unfortunate
patch can get obsolete very quickly and sometimes a patch can be valid
over a long period of time.
And what if the timeline is not respected ? The patch that is no more
applicable is applied? The leader is kicked?
We do not have any control on each others, so the only resort is
goodwill. If the submitter wants to maximize the odds of getting is
patch accepted, he must make the work to apply it as easy as possible.
And if he wants to speed up things he can talk about it with the leader
on the irc channel. OTOH, nothing prevent the leader to accept obsolete
patch and merge them by hand.
But the best answer to this problem is the first point: if the patch
have been discussed before, it will be easier and thus quicker for the
leader to review it as he already knows the ins and the outs for it.
Also the patch is more likely to be correct from the first version.
>
>> - Make sense with respect to the underlying code (I.E. sometimes it's
>> better to create a new module than to add code to an existing module).
>>
>>
>> Module Submission
>> *****************
>>
>> As for patch submission the best is to talk about the future module
>> with other members of the community. The submission follow these
>> steps:
>>
>> - An issue that ask for comments is opened on the tracker with a link
>> to an active mercurial repository of the module.
>> - Once the talks are considered over, the submitter ask (with a
>> comment on the issue) the Tryton Bdfl to publish the module.
>
> Timeline? (see above)
If nobody answer this means the module is ok. One can define a minimal
delay but I don't think it's necessary (What if someone interested by
the module is on holiday? :D). The best is to trust the submitter and
the bdfl because they know who has potentially some insight or comments.
>
>> - The module is published if the following conditions are met:
>>
>> - The module isn't redundant with an existing module,
>> - the module provides features that are useful for at least one
>> situation,
>> - there are no obvious improvement to be made,
>> - the module doesn't raise major objection and
>> - there is a volunteer to be the module leader.
>>
>>
>> News Submission
>> ***************
>>
>> The process for news submission works as follow:
>>
>> - One of the leader propose a topic and propose himself or one member
>> of his language community as writer. The news must potentially
>> interest a large part of the Tryton community. For those proposals
>> we will create a private mailing that will be dedicated to
>> centralise talks about the news
>
> I suppose you are speaking about a mailing *list*? I think to be able to follow
> changes of different news contributors and to ease contribution it would be
> better to have some sort of version controlled interface like a wiki for the
> news content itself.
Yes a mailing list. This does not prevent anybody to use other tools as
long as he warn the others.
>> - The news is written and the draft is reviewed by the news leaders.
>> - Once the leaders have made the review, the news is translated and
>> published in each language.
>>
>>
>> [1] http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
>> [2] http://code.google.com/p/tryton/wiki/ReleaseGeneral
>> [3] http://codereview.appspot.com/
>
> Cheers,
> Mathias Behrle
>
Have a nice holiday !
Hartmut Goebel
>>> - An issue is opened on the tracker with the patch as attachment and
>>> a comment describing what it does. The patch must be a text file if
>>> only text files are modified and a mercurial bundle otherwise.
>> Please clarify: Who is opening the issue? Which "type" should it have?
>
> mercurial changeset.
I meant: what type of issue.
>> assigning it? How to submit a bundle of patches (as I did in issue1100)?
>
> You don't.
So please explain how this should be handled then.
>> merging the change into the other language websites?
>
> I don't understand.
If I submit a change to the english website, how is in charge to care
the otehr languages are changed, too.?
>>> - If the patch is accepted, the patch is applied by the leader. If not
>>> the leader may close the issue (if the idea behind the patch is not
>>> right) or ask for improvements (if the implementation is not right).
>> Please add: The sub-project leader is in charge of keeping the
>> originating contributor as submitter if possible. Otherwise hae has to
>> state the original author in the changelog.
>
> If the changeset works and is correct, it will be.
Since we all agree, this can be written in the Guideline :-)
>>> - Be atomic. More precisely a patch should correspond to one and only
>>> one bugfix, one new feature, one documentation update or one code
>>> refactoring.
>> Please clarify: Should larger refactoring (as in issue 1100) be
>> submitted as a single, big patch? Should each "mini-patch" go into a
>> separate issue or should they be bundled into into one issue?
>
> One fix = one changeset
Changes are not only bugfixes. And Fixes may relay one on each other. So
how is it meant to submit patch bundles?
>>> Module Submission
>> [...]
>>> - An issue that ask for comments is opened on the tracker with a link
>>> to an active mercurial repository of the module.
>> I do not understand this sentence.
>
> An issue asking for comments is opened...
By whom? By magic? Where should the link point to exactly? The Revision
the patch is based on? Please clarify.
>> Please clarify: How the module is put into which branch (1.0, 1.2,
>
> It depends of the branch for which the module is.
Please describe the policy therefore.
>> devel)? How is tagging to be handles? Will new module be put into
>> hg.tryton.org?
>
> It is the purpose of module submission.
Please describe this.
Hartmut Goebel
> It would be good to have some sort of timeline for submissions. It is hardly
> possible to be relative to the current mercurial version if you don't get
> feedback.
+1
Esp. if the maintainer submitts later patches first (see isseu1101 and 1100)
Cédric Krier
> Cédric Krier schrieb:
>
> >>> - An issue is opened on the tracker with the patch as attachment and
> >>> a comment describing what it does. The patch must be a text file if
> >>> only text files are modified and a mercurial bundle otherwise.
> >> Please clarify: Who is opening the issue? Which "type" should it have?
> >
> > mercurial changeset.
>
> I meant: what type of issue.
It depends of the issue.
> >> assigning it? How to submit a bundle of patches (as I did in issue1100)?
> >
> > You don't.
>
> So please explain how this should be handled then.
You don't need to submit a set of patches.
> >> merging the change into the other language websites?
> >
> > I don't understand.
>
> If I submit a change to the english website, how is in charge to care
> the otehr languages are changed, too.?
The translators.
> >>> - If the patch is accepted, the patch is applied by the leader. If not
> >>> the leader may close the issue (if the idea behind the patch is not
> >>> right) or ask for improvements (if the implementation is not right).
> >> Please add: The sub-project leader is in charge of keeping the
> >> originating contributor as submitter if possible. Otherwise hae has to
> >> state the original author in the changelog.
> >
> > If the changeset works and is correct, it will be.
>
> Since we all agree, this can be written in the Guideline :-)
>
> >>> - Be atomic. More precisely a patch should correspond to one and only
> >>> one bugfix, one new feature, one documentation update or one code
> >>> refactoring.
> >> Please clarify: Should larger refactoring (as in issue 1100) be
> >> submitted as a single, big patch? Should each "mini-patch" go into a
> >> separate issue or should they be bundled into into one issue?
> >
> > One fix = one changeset
>
> Changes are not only bugfixes. And Fixes may relay one on each other. So
> how is it meant to submit patch bundles?
One fix or improvement = one changeset
> >>> Module Submission
> >> [...]
> >>> - An issue that ask for comments is opened on the tracker with a link
> >>> to an active mercurial repository of the module.
> >> I do not understand this sentence.
> >
> > An issue asking for comments is opened...
>
> By whom?
By the people who wants to submit a module.
> By magic?
By hand.
> Where should the link point to exactly? The Revision
To the repo of the module.
> the patch is based on? Please clarify.
It is not based on anything, it is a module.
> >> Please clarify: How the module is put into which branch (1.0, 1.2,
> >
> > It depends of the branch for which the module is.
>
> Please describe the policy therefore.
There is no policy. When you develope a module, you develope on a specific
serie.
> >> devel)? How is tagging to be handles? Will new module be put into
> >> hg.tryton.org?
> >
> > It is the purpose of module submission.
>
> Please describe this.
I don't understand.
Hartmut Goebel
> One fix or improvement = one changeset
So you really wanted issue1100 to be 18 separate issues? Come on!
Neither would a contributor want to file 18 issues, not would you want
to review these.
>>>> Please clarify: How the module is put into which branch (1.0, 1.2,
>>> It depends of the branch for which the module is.
>> Please describe the policy therefore.
>
> There is no policy. When you develope a module, you develope on a specific
> serie.
Even this is a policy. This has to be clearly stated in the contibution
guideline.
>>>> devel)? How is tagging to be handles? Will new module be put into
>>>> hg.tryton.org?
>>> It is the purpose of module submission.
>> Please describe this.
>
> I don't understand.
Please describe the process of module submission, esp. how tagging
should be done. Remember: many users are still used to the concepts of
CVS/SVN.
Sasa Ostrouska
On Sat, Jul 25, 2009 at 12:53 PM, Hartmut
Goebel<h.go...@goebel-consult.de> wrote:
> Cédric Krier schrieb:
>
>> One fix or improvement = one changeset
>
> So you really wanted issue1100 to be 18 separate issues? Come on!
> Neither would a contributor want to file 18 issues, not would you want
> to review these.
>
You can always do one big diff, isnt it ?
Hartmut Goebel
> Hi,
>
> On Sat, Jul 25, 2009 at 12:53 PM, Hartmut
> Goebel<h.go...@goebel-consult.de> wrote:
>> Cédric Krier schrieb:
>>
>>> One fix or improvement = one changeset
>> So you really wanted issue1100 to be 18 separate issues? Come on!
>> Neither would a contributor want to file 18 issues, not would you want
>> to review these.
>>
> You can always do one big diff, isnt it ?
Still using isse1100 as a sample: If this would have been one big diff,
nobody could have followed the changes, since nearly every line was
touched (and be it just due to changed indent level).
Cédric Krier
> Cédric Krier schrieb:
>
> > One fix or improvement = one changeset
>
> So you really wanted issue1100 to be 18 separate issues? Come on!
> Neither would a contributor want to file 18 issues, not would you want
> to review these.
No one changeset
Hartmut Goebel
> On 25/07/09 12:53 +0200, Hartmut Goebel wrote:
>> Cédric Krier schrieb:
>>
>>> One fix or improvement = one changeset
>> So you really wanted issue1100 to be 18 separate issues? Come on!
>> Neither would a contributor want to file 18 issues, not would you want
>> to review these.
>
> No one changeset
IC. So this should be stated clearly in the guideline, too.
Udo Spallek
Am Samstag, den 25.07.2009, 12:53 +0200 schrieb Hartmut Goebel:
> Cédric Krier schrieb:
> >>>> Please clarify: How the module is put into which branch (1.0, 1.2,
> >>> It depends of the branch for which the module is.
> >> Please describe the policy therefore.
> > There is no policy. When you develope a module, you develope on a specific
> > serie.
> Even this is a policy. This has to be clearly stated in the contibution
> guideline.
http://producingoss.com/en/release-branches.html
We have one difference from the description in the link above to
practical release of Tryton: In Tryton we test at first the trunk, and
then branch for the release.
Personally I dislike this way, because testing became very complicated
when new features are submitted in the testing phase, specially on
release 1.2 this has been hard to follow.
So for me the best way is to do at first the release branch, feature
freeze this branch, then test and fix this branch. If the testing is
over aka Tryton release, backport the fixes from the last release branch
back to trunk.
With this it is always possible to commit new stuff into the trunk and
to have a stable/feature freezed environment for testing. Tester can
concentrate their work focussed to the release branch, while developer
can work on both if needed.
Cédric Krier
Hartmut Goebel
> I don't agree with this process. It is well explain in
Well, Udo described at least two processes: the one he revered to and
his opinion. Since you quoted all of them: What do you nor agree with.
Or the otehr way round: please document your opinion.
> http://www.youtube.com/watch?v=i7pkyDUX5uM
Sorry, video are barley readable :-) Please write it down instead of
pointing to youtube.
Cédric Krier
> Cédric Krier schrieb:
>
> > I don't agree with this process. It is well explain in
>
> Well, Udo described at least two processes: the one he revered to and
> his opinion. Since you quoted all of them: What do you nor agree with.
> Or the otehr way round: please document your opinion.
He makes a proposition on which I don't agree.
Bertrand Chenal
> Cédric Krier schrieb:
>
>> One fix or improvement = one changeset
>
> So you really wanted issue1100 to be 18 separate issues? Come on!
> Neither would a contributor want to file 18 issues, not would you want
> to review these.
>
>
>>>>> Please clarify: How the module is put into which branch (1.0, 1.2,
>>>> It depends of the branch for which the module is.
>>> Please describe the policy therefore.
>> There is no policy. When you develope a module, you develope on a specific
>> serie.
>
> Even this is a policy. This has to be clearly stated in the contibution
> guideline.
How can it be different? How can someone develop a module that isn't
meant to work with any series? Maybe the guidelines should clearly state
that the module should be a Tryton module?
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Udo Spallek
Am Samstag, den 25.07.2009, 17:22 +0200 schrieb Cédric Krier:
> On 25/07/09 16:40 +0200, Udo Spallek wrote:
> >
> > Hi,
> > Am Samstag, den 25.07.2009, 12:53 +0200 schrieb Hartmut Goebel:
> > Here can be found some legetimations about using release branches:
> > http://producingoss.com/en/release-branches.html
> I don't agree with this process. It is well explain in
> http://www.youtube.com/watch?v=i7pkyDUX5uM
first I smile when Cédric send me a video link for explaining the
release process of Tryton. Then I was shocked by the bad video quality
and the quite nerdy speaker...
But the content of the speech is incredible interesting for me!
Thinking about this, let me rid of old habits in traditional open source
release process. Below I write my analys about Trytons development
process in contrast to my experiences in former projects.
Finaly I completely agree with Cédric, the general release process on
Tryton is absolutely the road to take. The BSD style release process he
recommends is a successful way to go for me, because in fact we have
produced two quite stable releases with this process.
In retrospective the /release pain/ for testers and developers I
mentioned before has been on Tryton much more moderate then I
experienced in my former projects. In these projects I learned that
moving the release date later and later, cuts soon all my motivations
off. My expected jump to a much better quality in having more time to
test and fix has been in fact seldom fulfilled.
After such a delayed release the pain wont stop, because now the awful
backporting release to trunk starts. What a luck that most of the
projects I work before freeze the trunk while release, for half a year
or longer. But this is half a year without evolution in functionality
and features. Developments which where finalized a second after feature
freeze needed to wait a long time to be backported in the trunk. So I
learned to put my half-baken developments into the trunk a second before
the feature freeze...
Not to think about maintaining a set of already released versions in my
projects before. Like after release is before a release, the community
tries to forget as quick as possible everything about already released
versions of their software and looking into the future of the next
release which hopefuly comes in some years. First starting to backport
the release branch to trunk backporting all former 'new developments'
from the old to the new trunk, awful, painful.
Of course there came several bugfix releases for the last release, but
never came one for one of the releases before.
The question why bugfix releases are necessary while we test the
software this well and for such a long release feature-freezed-time was
never ask in my former projects.
Not on Tryton. A Tryton release takes me at most four very stressful
painful weeks, but then it's released definately and I am free. Bugfix
releases will come while bugs are raising up. And as I learned, bugs
will always raising up. Bugs are independend from the time I test the
software. Finding Bugs IMHO depended of a high motivation of testers and
developers working close together for a very short time, good testing
coverage[1] and some simple tools which Tryton already has[2].
Our BSD style release process to branch _after_ testing and bugfixing
eliminates the /pain/ of as-quick-as-possible backporting the new stuff
of the release branch into a possibly changed development trunk. Tryton
development never leave the trunk, even not in late releasing process.
So release become a tag in the trunk and a copy to a subfolder for the
branch, nothing more.
Upon this it allow us to maintain some levels of aged releases with
minimal efford/pain/stress at any time we want. Because the release
branches are independend from the trunk. A bugfix release in Tryton is
not a new release of the trunk, it is always a release in an independend
branch. You will find minor releases like 1.0.1, 1.0.2 only in the
specific Branch[3], but not in the trunk[4] because of their
independence. This aged release maintenance is actively done on Tryton
1.0[3] by Cédric as I can see at the 'last change date', which was at
least three weeks ago from today. Good work!
So avoiding the /release pain/ seems not possible at all. The actual
release process on Tryton lowers the /pain/ to some hard but successful
weeks and gives the possibilities to maintain a set of aged versions of
Tryton. Not to forget the big benefit for the users and implementors,
they have a fixed date when Tryton will release next time, half a year
before.
Here[5] you find the slides of the above video, but don't forget to
watch the video, for me it is definately valuable to see.
Regards
Udo Spallek
[1] http://code.google.com/p/tryton/wiki/Testing1_2_0
[2] https://bugs.tryton.org/
[3] http://hg.tryton.org/1.0/trytond/tags
[4] http://hg.tryton.org/trytond/tags
[5] http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
Juan Fernando Jaramillo
modules that the Tryton do not: (product_cost_history, stock_product_location,
stock_supply_day, stock_forecast, product_cost_fifo), why?
Regards
--
Juan Fernando Jaramillo
Gerente Tecnología
MIG Internacional
www.miginternacional.com
Cédric Krier
> Cool description of Udono, I have a dout, the branch of Tryton 1.2 have five
> modules that the Tryton do not: (product_cost_history, stock_product_location,
> stock_supply_day, stock_forecast, product_cost_fifo), why?
>
See http://groups.google.com/group/tryton/browse_frm/thread/a328d66ebe1578dc
Mathias Behrle
> Has said on the irc channel this thread will be used to talk about
> some guidelines/processes.
>
> Those guidelines concern:
>
> - Patch submission
> - Module submission
> - Translations (modules, client and server)
> - News submission and translation
This is a separated followup to thread "Contribution guidelines".
As stated already earlier I think we should improve the handling of News on
tryton.org.
I am proposing the creation of a News team, that should be a sub project on
http://code.google.com/p/tryton/wiki/ProjectOrganization
- to offload some work from the shoulders of the maintainers.
- to improve quality of the content by more input, general review, professional
handling
I am personally not very happy with the current concept of 'descriptive
changelog'. I think we perhaps even need two different
News lines, one technically orientated, another one press orientated. The
second could point to the first, if there is interest in technical details.
Cheers!
--
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: 0x89BCA161
Mathias Behrle
+0200):
> > Should changes to the website be but on Rietveld, too?
>
> Why not.
Website of tryton.org should be a sub project on
http://code.google.com/p/tryton/wiki/ProjectOrganization and should
follow indeed contribution guidelines.
Hartmut Goebel
> I am personally not very happy with the current concept of 'descriptive
> changelog'. I think we perhaps even need two different
> News lines, one technically orientated, another one press orientated. The
> second could point to the first, if there is interest in technical details.
+1
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
B2CK Info
> * Betr.: " [tryton] Contribution guidelines" (Fri, 17 Jul 2009 17:01:55 +0200):
>
>> Has said on the irc channel this thread will be used to talk about
>> some guidelines/processes.
>>
>> Those guidelines concern:
>>
>> - Patch submission
>> - Module submission
>> - Translations (modules, client and server)
>> - News submission and translation
>
> This is a separated followup to thread "Contribution guidelines".
>
> As stated already earlier I think we should improve the handling of News on
> tryton.org.
>
> I am proposing the creation of a News team, that should be a sub project on
> http://code.google.com/p/tryton/wiki/ProjectOrganization
>
> - to offload some work from the shoulders of the maintainers.
> - to improve quality of the content by more input, general review, professional
> handling
No problem here, people interested by the news just needs to manifest
themselves some days before the release day (and optionally add their
name on a "News" subproject on the wiki page).
> I am personally not very happy with the current concept of 'descriptive
> changelog'. I think we perhaps even need two different
> News lines, one technically orientated, another one press orientated. The
> second could point to the first, if there is interest in technical details.
There is already two kind of news, the one that is posted on tryton.org
and all the others that are posted to news websites. We may share the
work of creating a default press oriented news.
> Cheers!
>
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium