Perry Greenfield wrote:
>> 2) While I understand the desire to increase the quality of commits to
> scipy by putting in a more formal process, like making sure code is
> reviewed, tests are present, and documentation is provided, I too,
> like Travis, worry that this may inhibit many useful contributions.
> Rather than act as a barrier, why not just have some sort of "seal of
> approval" for things that have gone through that process.
Lots of projects have -stable and -dev branches. The -stable branch for
scipy could involve the "seal of approval" with review, doctests, etc.
The -dev branch could be the unreviewed code. This lets Travis commit
to something and get his patches out there, but also clearly defines a
line in the sand between reviewed and unreviewed code. I realize that
scipy already has something of -dev and -stable branches, based on
releases. Maybe this idea boils down to: only reviewed code is allowed
in an official release, but there is a -dev branch with all code
available as well. As code is reviewed, it is moved into the -stable
branch and released in the next release.
In reality, using a DVCS, each developer's copy of the repository then
becomes a private -dev branch that can be pulled from. Developers get
to commit and publish unreviewed changes, and someone (the release
manager) can pull in to -stable the changes that are reviewed. The
release manager could also pull all changes from developer repositories
into an official -dev branch if you wanted to have a central clearing
house for what everyone is working on.
Jason
--
Jason Grout