<p>Em 05/07/2011 02:22, "Ben Walton" <<a href="mailto:bwalton@opencsw.org">bwalton@opencsw.org</a>> escreveu:<br>
><br>
> Excerpts from Maciej Bliziński's message of Mon Jun 13 06:05:41 -0400 2011:<br>
><br>
> > Our aim is to build a culture in which peer review is one of the key<br>
> > elements.  There needs to be an environment which encourages peer<br>
> > reviews and makes them easy.<br>
><br>
> A thought I had on the train tonight is that review could begin with<br>
> the maintainer detailing the following changes for a package release:<br>
><br>
> 1. Version info.<br>
> 2. Changed configure options (if any).<br>
> 3. Overrides used and why.<br>
> 4. New or removed patches and their function.<br>
> 5. Filesystem layout changes and how they're gracefully handled.<br>
><br>
> Having the maintainer lay this info out clearly to kickstart the<br>
> discussion does a few things:<br>
><br>
> 1. Makes the maintainer think about the changes in a package at a<br>
>   level higher than the build recipe.<br>
> 2. Gives other maintainers insight into hot spots to review if they<br>
>   want to look in more depth.</p>
<p>Sounds good. Would that be on the devel or the maintainers list?</p>
<p>I once had a bit of code that was creating a list of code commits that fall between releases. A tool like this could be used to start a review email.</p>
<p>I also had an idea for a better package diff tool, which was basically a different of two formatted python data structures. One of the issues was to sort all the output so that the diff is meaningful.</p>
<p>I am on vacations this week; will provide more feedback when I get back.</p>
<p>Maciej<br>
</p>