Mailinglist Archive: yast-devel (121 mails)

< Previous Next >
Re: [yast-devel] Changing the Attitude to Coding YaST
Lukas Ocilka write:
Dne 8.6.2011 15:16, Lukas Ocilka napsal(a):
Code Reviews
- In the SLMS team, we've found out that all the commits should be
reviewed by someone else. This helps to identify potential issues in
time. All the commits are public anyway.
- Fix|Easy to Medium: Either someone is always assigned to review
everyone's code (takes too much time) or developers usually check
code of someone else only.

Martin, thank you for the reviews you do. They've already helped to find
several bugs or possible issues even before they reached our users and
made some harm.

From my POV, this looks very promising. Others will hopefully help with
the reviews later ;)

Bye
Lukas



Well, actually I think that we should connect it with git. Git allows to have
official git repository and a lot of development git repository, so we can do
it same way like kernel, wine or other projects.
see e.g. http://help.github.com/fork-a-repo/ and
http://help.github.com/send-pull-requests/ I really like this workflow, as it
allows to easy checkout your modified repository and then test it, comment each
line.

So you can work in branches on different features, bug fixes etc ( in git
really easy, I hope we have for non-git users presentation on workshop ), do it
and then send pull request which is reviewed by authorized reviewer and if
everything is fine, then accept it. If there is problems, you can discuss it
under pull request and improve branch ( fix issues ) and send again.

Advantages:
- centralized place for reviews
- well defined group which is responsible for accepting patches
- you review whole functionality, not just one commit, but whole set ( so you
can check if it is tested, documented, API looks reasonable, code is readable,
follow style guide etc. ). We can e.g. create process that module backup need
to review it for module specific things ( as side effect he also know how
module changed, so in case of vacation he know code ) and general reviewer
check general rules.

Disadvantages:
- need some time, quick hackish solution will not be so quick and easy
- we need to somehow force use of for packages only code from official repo (
e.g. new services for OBS could help as, as we can have hudson which observe
this repo and send to devel repo packages with recent changes )


I think we should discuss it now and what is more important decide it on
workshop where is everyone and we should decide future direction of YaST.

Pepa


--
Josef Reidinger
Appliance Toolkit team
maintaining parts of webyast and SLMS
author of rubygems - studio_api and net_observer (coauthor)
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups