Michael Casadevall <[EMAIL PROTECTED]> tapota : > 1. (*) text/plain ( ) text/html
This commit will likely create a bunch or merge conflict, as the same files were updated on the CERN branch. We need to work differently if you intend to modify heavily files that were also touched on the CERN branch (one particular thing with gettext is the fact that new potfiles modify all i18n files). I will probably go the rough way for i18n files, meaning that I'll just overwrite files and not resolve conflicts. For the code, it would be insane to do it that way; hopefully maybe there wont be any conflict. But I seen that one your previous changes touched the trackers, and most of the changes on the branch happens on the trackers. I hope we will not have a bad surprise the merge day (since unfortunately, it wont be possible to test the tracker with your commit without prematurely merging into the trunk). More generally, when a branch is open and active on a specific part of the code, the best is probably to avoid touching that part of the code or asking to the persons that work on the branch if it possible to commit directly on that branch (or even to branch on the branch). Sorry if this mail sound archs, I'm just mentioning frankly potential issues of this commit. I'm not attacking Michael work. If he made that commit on the trunk, it is not his fault but rather mine, who forgot to explicitely say that commits on the trunk of files also touched on the CERN branch could be a pain the merge day. I realize I made this mistake and that's why I reply on savane-dev about this commits, not to patronize Michael but just to do what I should have done before: raising the problems of concurrent commits. There's nothing to do about what was done before and I do not think it will be a big deal (even if there are conflicts, we are only talking about one code commit, should be fast to fix) but I'd like to avoid this thing getting really problematic. Sum up: the CERN branch mostly affect frontend trackers code, but affect most general the whole frontend. Commits on the frontend should be avoided. Commiting on the CERN branch is way preferred (it wont be the case after November the 21th) so it can be directly tested and wont create merge conflicts. If your commit is about the contend of include/trackers*, send me a mail so I'll tell you the exact status of the file (currently being modified or else). The general rules is that bugfix commits are acceptable on the trunk. But since it is the CERN branch that is tested and was directly derived from the trunk, even bugfix and cosmetics are best being commit on the CERN branch (which could be consired as 1.0.5-dev branch). I hope this clarification wont discourage Michael about commits ;) I perfectly understand how painy it could be to have plenty of "rules" to follow just for a few commits; but the end of it not playing generals and soldiers, only working more efficiently. Regards, -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+
