← Back to team overview

yade-dev team mailing list archive

Re: Rev 3550 - which kind of collaborative work ?

 

Ok, I do understand these guidelines. I think by the way I obey them generally (see e.g. #3 of https://bugs.launchpad.net/yade/+bug/1112763, when now a proposal is stucked in limbo ;-) ). Since I had surely here a higher risk-tolerance than you, I can follow them more strictly.

Jerome


________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx]
Sent: December 4, 2014 8:38 AM
To: yade-dev@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Yade-dev] Rev 3550 - which kind of collaborative work ?

Hi Jérôme,
This is an interesting case, thank you for opening the discussion. In the past years potential contributors were usually applying a strong self-censorship, as they were so afraid to break something (so many of them never commited anything for this reason). As far as I remember it is the first time that someone asks for more freedom to commit whatever he likes. So, for the first time, I will try and give a few guidelines below.

On 03/12/14 23:34, Jerome Duriez wrote:
Entering now general discussion, do you mean each commit should be discussed on yade-dev ?
No. See my messages again, they refer to specific (e.g. "low level") parts of the code.
Up to now I considered that thanks to git, the buildboot (when it works), etc.., we can enjoy a collaborative work on a (open source) code that belongs to everyone, without too much control. Errors, still possible, are spotted and corrected thanks to feedback of other devs, or users, when errors appear (which, finally, does not happen so often it seems).

We are 19 members in yade-dev. Did you ever try building a house or something with 19 asynchronous workers, overlapping each other but not talking, without a global plan and with the only feedback "until now it didn't fail"? I doubt it can work.
It is the same here. If 19 people feel free to push changes to every files, and without a need to notify what they do, reviewing will become a full-time job and everything will be broken in a matter of months.
Errors appear not so often precisely because of the self-censorship mentioned above. Also because a few of us are keeping track of what happens. It takes a lot of time already, no need to make it more time consuming.
I do not mean that some parts of the code must not be changed, only asking for discussion before changing them.

The capillary law is typical. It has no regression tests (then the buildbot is helpless) and only a few users (delayed and/or little user feedback - counting on regular users to detect bugs is bad practice anyway, it refrains them from updating, leading to no user feedback ultimately).
In my mental map of yade the capillary code is something stable that nobody is touching. Hence if in 6 months somebody has strange errors with "yade -j6", I will not suspect the capillary law if I don't know that somebody (you) modified it. Fixing bugs is time consuming when you don't know where they are. It is even worst when you think they are not in a place where they actually are.


If we have to adopt a centralized workflow, I would conform the decision whatever my thoughts. But this should come from a global consensus, not from a discussion between 2 people, I think.

We don't have to adopt anything new. We reached the consensus in 2011 [1], and it has been confirmed again during the first yade workshop in Grenoble.
Therefore, I suggest:

Guidelines:
These are situations when we don't expect prior discussion (though it never hurts):
- commit by a seasoned[2] dev
- change in some code by the author or co-author of the code
- or the notorious maintainer if the original authors left
- or someone following an agreed workplan, in which case we don't need one email per commit if the task will involve many commits on a long period (note that git branches are well suited in this situation, though)
- small-scale changes and typos in the documentation or in example scripts (I know you did that a lot recently, thanks a lot for that)
In other cases it should be discussed.
In every cases, please, put a few words in the commit logs (not like [4]).

Cheers.

Bruno

[1] https://lists.launchpad.net/yade-dev/msg07310.html
[2] where "seasoned" must be considered with respect to what is being modified. For instance you Jérôme are not yet seasoned in openMP programming according to [3]. I am not seasoned in debian packaging. I don't think anyone can claim expertise on 100% of the code actually. Everyone has to know his own limits.
[3] https://lists.launchpad.net/yade-dev/msg11722.html
[4] https://github.com/yade/trunk/commit/6c2eb71382d44b6884fb1aa15fdc37af20959c40, giving the hyperlink is great but it says nothing in itself. We need something in plain english, then a hyperlink when possible.




________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx>] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx<mailto:bruno.chareyre@xxxxxxxxxxxxxxx>]
Sent: December 3, 2014 1:55 PM
To: yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3550: Add of O.thisScene() function to know in which scene we are

Jérôme, I think the commit is right but I have the same comment as before: please don't touch this kind of code without a note here on yade-dev.
Of course you can change whatever you like in your local copy, so my request should not block your production at any point.
Pushing to trunk is another thing. I can't track changes if people start changing low level code silently just like that.
Thanks
Bruno



On 01/12/14 20:49, noreply@xxxxxxxxxxxxx<mailto:noreply@xxxxxxxxxxxxx> wrote:

------------------------------------------------------------
revno: 3550
committer: jduriez <jerome.duriez@xxxxxxxxxxx><mailto:jerome.duriez@xxxxxxxxxxx>
timestamp: Mon 2014-12-01 11:20:51 -0700
message:
  Add of O.thisScene() function to know in which scene we are
modified:
  py/wrapper/yadeWrapper.cpp


--
lp:yade
https://code.launchpad.net/~yade-pkg/yade/git-trunk<https://code.launchpad.net/%7Eyade-pkg/yade/git-trunk>

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription<https://code.launchpad.net/%7Eyade-pkg/yade/git-trunk/+edit-subscription>




_______________________________________________
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp




--
_______________
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21
Fax : +33 4 76 82 70 43
________________




_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp




--
_______________
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21
Fax : +33 4 76 82 70 43
________________


Follow ups

References