Hi,
Even though this has been explained before ... just to make sure we
understand each other ...
Chamilo 2.0 has 2 sets of repositories: one dubbed STABLE and another
one dubbed DEV. Stable is where bugs get fixed, dev is where new
developments are added. Obviously every once in a while we like to apply
all bugfixes from STABLE to DEV, to make sure we're not doing the same
thing over and over again. Not every single developer uses the same
development tools and per extension the exact same formatting. Some
changes might also seem to conflict (when they really don't in reality).
So, preparing a merge is nothing more or nothing less than what the
message says. (and even done automatically by a variety of IDEs) The
formatting of Chamilo 2.0 has been documented and is used by the
development team, as such it should not need additional information.
If someone wants to spend time going through all changes in formatting
or all changes which were applied to STABLE before and are now simply
being copied over to DEV: sounds boring and unneccesary to me, but they
should feel free to do so. Apart from that each and every change that
was ported was adequately (even if it wasn't always extensively)
commented on on the stable branch. The relation between STABLE and DEV
is a well known thing among 2.0 developers, it's come up on the dev list
a few times.
Some commits simply don't need more information if you know the project
(which I would guess one does or intends to do if he or she dives into
the codebase on Bitbucket). I find it regrettable (and somewhat
offending if I can be honest) that this would be associated with
laziness. It is most definately NOT laziness when someone takes the time
or makes the effort to go through thousands of changed files and make
sure we can move ahead to a next release. If they use a self-explicatory
and generic 2.0 message to document that in over 160 code repositories,
I would apploud them for the effort and care less about the message.
In general I dare even say that the majority of commit messages is more
then adequate for me to know what the developer in question has done.
Not to mention that all those active right now, have been so for quite a
while and I personally, don't feel the need to constantly review their
code. If others do feel this is necessary, please do let us know.
I like the idea of being able to hook up commits with Redmine, that
makes things somewhat (a lot) easier. I just hope Redmine / the server
can handle making connections between the different projects and over
300 repositories. Considering the software and platform it's built on
though, I would not really expect that to be a problem. Looking forward
to trying it out though.
By the way: the 2.0 team has never been as active as these past few
months. Lots of great things are being realized ... but not all of them
have an immediate impact on the code base. (and I think some of the
repositories might not even be hooked up to the noticiation script yet
either, would have to check that)
Best regards,
Hans
On 16/11/2011 15:06, Yannick Warnier wrote:
Hi all,
Just to make sure we understand each other...
The text that goes with a commit is meant to make review easier. That
is, when tracking a particular bug that was "just introduced", it is
probably around 20 times faster to try to locate the file that is the
origin of the problem, then to see which commits were recently made on
that file, just by looking at the title of the commit.
As such, a commit text like "Preparing merge with STABLE" or "Exercises
categories" is rather useless and would force the reviewer to open each
and every one of the commit detail page and analyse the code in-depth to
try and figure out what was changed.
In general, it is always possible to find a clear explanation of what
one has done. Like for example: "Reformat exercise wrapper to include
white spaces before merge", or "Fixed random capability of exercises
categories".
I'm pretty sure a number of you will recognize themselves in these
descriptions. Please consider that we are not enough people to be
wasting the time of reviewers just for momentaneous laziness. It is
important to be strict and a proper patch should not be considered
complete until you have found the proper wording to explain the commit.
Also, I generally use a special keyword to indicate that the commit is
just a code style change (and as such it has no chance of introducing a
bug): I prefix my commit with "Minor - ".
Finally, Redmine has a pretty neat feature which allows you to
automatically bind a commit to a corresponding task in Redmine.
This is done by setting up a local copy of the repository on the Redmine
server and using the " refs #3456 " suffix in your commits. This allows
for even faster code review, because you can search for a bug in Redmine
and then get the reference to the corresponding commit immediately.
I should be migrating Redmine to our new server next week, so setting up
these local repositories should be easy and practical.
Nice to see a few people getting back to work on 2.*!
Yannick
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
*Hans De Bisschop*
Adviseur | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
