[vdsm] minutes: today's call
On Mon, Apr 23, 2012 at 07:34:14AM -0500, Adam Litke wrote:
On Mon, Apr 23, 2012 at 04:17:18AM -0400, Ayal Baron wrote:
> Hi all,
>
> I would like to discuss the following on today's call:
>
> 1. Gerrit vs. mailing list
Gerrit is an inhibiter for some contributors.
One approach to solve this improve gerrit:
- Gerrit should send the patch when it notified of a change. This may
attract more reviewers.
- comments should be posted with their context
- pick up a patch/comment from the mailing list
Anthony finds the classic mailing list approach more comfortable. Our
development model should allow people to:
- be able to track current code development
- comment without logging in
It was suggested to move patch content into vdsm-devel; -patches list is
not a common concept. At least as long as -patches is full of
machine-generated noise, I think that this should be avoided. Currently
-devel is intended to general discussions (though we won't reject a
general discussion based on a patch).
Another approach is to relax contrinution requirement. This should not
be done causually, since if this door is opened it would be harder to
shut, and we may be stuck with two competing and mutualy confusing
development models.
We need to set a checkpoint in time to see if the first approach flied
regarding fixin
> 2. mandatory unittest per patch
Adam: it's a good idea. adds complexity but leads to a better code.
People should be informed on how to add unit tests for their code.
Ok then, it's an official policy.
We need to add more complex tests, that require a running vdsm instance.
> 3. pep8
Currently we have a whitelist. New code modules should be added to it.
Over time all existing modules should be added as well.
No objections for this were raised. Cool.
> 4. ??
4. REST API Update / Recommendations
Patches are ready for review. There is no objection to separate the code
into a different rpm; generating xml/json/collection templates
automatically to avoid data duplication may be a little complex at this
point (though I would prefer killing the duplication in its infancy).
Regards,
Dan.