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 [[email protected]] on behalf of Bruno Chareyre [[email protected]] Sent: December 4, 2014 8:38 AM To: [email protected] 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 [[email protected]<mailto:[email protected]>] on behalf of Bruno Chareyre [[email protected]<mailto:[email protected]>] Sent: December 3, 2014 1:55 PM To: [email protected]<mailto:[email protected]> 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, [email protected]<mailto:[email protected]> wrote: ------------------------------------------------------------ revno: 3550 committer: jduriez <[email protected]><mailto:[email protected]> 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 : [email protected]<mailto:[email protected]> 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 : [email protected]<mailto:[email protected]> 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 ________________
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
