Re: Code review [Was: GNA is down...}

[Sebastian Reitenbach]

On Monday, February 13, 2012 22:31 CET, Fred Kiefer <fredkiefer@gmx.de> wrote:

> On 13.02.2012 22:09, Eric Wasylishen wrote:
> > One big advantage of dvcs's, which is something I don't hear
> > discussed a lot, is how much better the GUI's are for reviewing
> > recent commits made by other people. In my opinion, every active
> > developer should be reviewing the diffs of most commits to their
> > project. It's simply too slow for me to deal with in subversion (look
> > up the revision number, run svn diff -rRevisionBeforeFoo:foo | vim -,
> > wait several seconds, read the diff, look up the next rev # I want to
> > read, repeat…). Is everyone else reviewing most diffs of recent
> > commits? My bet is people aren't reviewing as much as they could
> > because it's slow with subversion.
>
> I try to do a code review of all changes to gui and back. I do this by 
> clicking on the links send to the GNUstep-cvs mailing list. (For example 
> http://svn.gna.org/viewcvs/gnustep?rev=34741&view=rev)
> Surely not the fastest way to do a code review, but I can do it even when 
> travelling from an internet cafe or my iPad.
> What ever new DVCS we come up with it should be able to send similar mails. 
> Or it will increase the work load.

Yes, those mails are important and I can just support this request, whatever 
will be used in the future, it should provide a similar feature.


But a bit more on the topic of code review, independently of what VCS will be 
used, let me share my experiences with OpenBSD:

Code review is usually done before its commited to the main tree. For each part 
of the tree, there is at least one, sometimes more maintainers.
If you have changes, you figure out, who is the maintainer, and send the patch 
for review. Important here is to send a patch inline, not as attachment.
Sending inline has the advantage you can just feed the mail to the patch 
command if a reviewer wants to test it actually. On many mail clients its a 
hassle to
view/open an attachment. Those reviewers then look at it, or even test, then 
give an OK, or request for changes.
Larger diffs with major changes are even sent to tech@, or a private m/l for a 
larger review by a wider audience, and requesting for testing it. Maintainers 
of the parts of the tree have rights to commit changes without review, but 
still, for major changes, its also for them recommended to
send the diffs to the m/l and request testing. When the commit is done, its 
noted in the commit message, who gave the OK.
Then, if things still break afterwards, the committer and reviewer(s) that gave 
the OK are responsible to fix it ;)

All this may seem to be much work, and may slow down development, but its 
indeed fairly effective, because most bugs/problems get catched, before
they enter the source tree, so people don't need that often spend lots of time 
trying to figuring out which of the commits broke a given feature.

Also, another thing that I like is that OpenBSD has scheduled release cycles, 
where customers/users can count on.
Before a release, developers are required to test, users are requested to test, 
and report back any issues they have.
This way, for a release, the base system and packages are all in sync, and 
supposed to work well.


Maybe gnustep should also have a scheduled release cycle, once or twice a year 
for a major new release, where all libraries, and main applications PC, Gorm, 
GWorkspace, ... are tested to work with each other, and released at the same 
time, even if there were only some minor changes or none at all.
This way, it would not happen that the latest base release doesn't play well 
with latest -gui/back for example ;)

All this said, OpenBSD has a comparably small developer team working on an 
operating system, compared for example to Linux. But without some rigid rules, 
to which people, especially the developers, have to adhere to, it wouldn't be 
possible to have a stable working release every half a year. There is only 
usually a handful of patches for each stable release.
Here is also a nice presentation detailing the OpenBSD release cycle: 
http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/

I don't want to push GNUstep into this direction, however, if it would be 
considered a good idea, and would go that way, I'd probably like it ;)
just wanted to share my experiences with the hope it may be of interest to 
someone.

cheers,
Sebastian

>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep