Open Stack

Excerpts from Chuck Short's message of 2013-03-20 10:38:30 -0700:
> On 13-03-20 01:27 PM, Sean Dague wrote:
> > On 03/20/2013 12:46 PM, Thomas Goirand wrote:
> >> On 03/20/2013 07:53 PM, Sean Dague wrote:
> >>> I noticed yesterday with the cinder review that pep8 was listed as >=
> >>> 1.3, and not pinned. I think this is a really bad idea.
> >>
> >> I do think it always should be this way, and not only with pep8, but
> >> with as much python tools as possible, including all the test suite.
> >>
> >>> After a large amount of pep8 churn at the end of Folsom, we agreed to
> >>> pin pep8 for Grizzly, and it was good. It prevented huge numbers of
> >>> churn patches because a new pep8 minor release came out and now we
> >>> needed an extra space somewhere to pass the scanner.
> >>
> >> Well, from a distribution standpoint, imposing such a restrictive
> >> build-dependency is just crazy. In Debian, there's either pep8 1.2 (in
> >> Wheezy which is frozen) or 1.4.4 (in SID). It's like that, and it wont
> >> change soon, unless there is a new upstream release. There will never be
> >> a 1.3.3. This kind of situation is likely to happen in other
> >> distributions than Debian.
> >>
> >>> I realize that we're trying to uncap as many deps as possible, but I
> >>> think doing that for pep8 isn't the right call, because of the 
> >>> amount of
> >>> code churn it causes.
> >>
> >> Then pep8 is either a bad software, or it isn't updated to Openstack.
> >> IMO, it should always be backward compatible, and be able to validate
> >> the same old code it did validate few versions ago.
> >>
> >>> I think at the beginning of every release cycle we should bump pep8 to
> >>> the latest release version
> >>
> >> PLEASE DON'T !!!
> >>
> >> Openstack already made my Debian package maintainer life miserable,
> >> because there was only version 1.2 in SID. I don't want to have to spend
> >> my life convincing the maintainer of pep8 to upload a new release.
> >>
> >> Now, imagine if all upstream authors were thinking like Openstack. The
> >> only way to be able to use pep8 would be to have as many version of pep8
> >> in Debian as there is upstream project using it.
> >
> > So, I'm confused....
> >
> > As a packager you are re-running the development internal style 
> > checkers on released code? and if so, why?
> >
> > I can understand rerunning unit tests to make sure that you didn't 
> > break function in patching openstack, but I actually don't understand 
> > at all why you'd run style enforcement on code during packaging.
> >
> >     -Sean
> >
> Hi
> 
> In Ubuntu at least it is required by our main inclusion  to run 
> available tests of the testsuites that is available to particular a 
> given project during the project build.
> 

https://wiki.ubuntu.com/UbuntuMainInclusionRequirements

"If the package ships a test suite, and there is no obvious reason why
it cannot work during build (e. g. it needs root privileges or network
access), it should be run during package build, and a failing test suite
should fail the build."

It is not required. The intent is to ensure quality, not to blindly run
everything upstream does.