Open Stack

++ for having 0.8.1 with oslospinx del fixed.

P.S. The 0.9.0 release will find some style issues in mostly all
projects I think, so, it's better to release it after Icehouse release
or at least RC1.

On Fri, Mar 21, 2014 at 8:58 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> On Fri, Mar 21, 2014 at 8:36 AM, Doug Hellmann <doug.hellmann at dreamhost.com>
> wrote:
>>
>> There is quite a list of un-released changes to hacking:
>>
>> * Make H202 check honor pep8 #noqa comment
>> * Updated from global requirements
>> * Updated from global requirements
>> * Switch over to oslosphinx
>> * HACKING.rst: Fix odd indentation in an example code
>> * Remove tox locale overrides
>> * Updated from global requirements
>> * Clarify H403 message
>> * More portable way to detect modules for H302
>> * Fix python 3 incompatibility in _get_import_type
>> * Trigger warnings for raw and unicode docstrings
>> * Enhance H233 rule
>> * Add check for removed modules in Python 3
>> * Add Python3 deprecated assert* to HACKING.rst
>> * Turn Python3 section into a list
>> * Re-Add section on assertRaises(Exception
>> * Cleanup HACKING.rst
>> * Move hacking guide to root directory
>> * Fix typo in package summary
>> * Add H904: don't wrap lines using a backslash
>> * checking for metaclass to be Python 3.x compatible
>> * Remove unnecessary headers
>> * Add -U to pip install command in tox.ini
>> * Fix typos of comment in module core
>> * Updated from global requirements
>> * Add a check for file with only comments
>> * Enforce grouping like imports together
>> * Add noqa support for H201 (bare except)
>> * Enforce import grouping
>> * Clean up how test env variables are parsed
>> * Fix the escape character
>> * Remove vim modeline sample
>> * Add a check for newline after docstring summary
>>
>> It looks like it might be time for a new release anyway, especially if it
>> resolves the packaging issue you describe.
>
>
>
> I think two new releases are needed. I have been holding off cutting the
> next hacking release until we are closer to Juno. Since the next release
> will include new rules I didn't want to distract anyone from focusing on
> stabilizing Icehouse.
>
> So it sounds like we need:
>
> * Hacking 0.8.1 to fix the oslo.sphinx  oslosphinx issue for Icehouse. Since
> we cap hacking versions at 0.9 [1] this will  get used in icehouse.
> * Hacking 0.9 to release all the new hacking goodness. This will be targeted
> for use in Juno.
>
> [1] https://review.openstack.org/#/c/81356/
>
>
> If this sounds good, I will cut 0.8.1 this afternoon.
>
>>
>> As far as the symlink, I think that's a potentially bad idea. It's only
>> going to encourage the continued use of oslo.sphinx. Since the package is
>> only needed to build the documentation, and not to actually use the tool, I
>> don't think we need the symlink in place, do we?
>>
>> Doug
>>
>>
>> On Fri, Mar 21, 2014 at 6:17 AM, Thomas Goirand <zigo at debian.org> wrote:
>>>
>>> Hi,
>>>
>>> The current version of python-hacking wants python-oslo.sphinx, but
>>> we're moving to python-oslosphinx. In Debian, I made python-oslo.sphinx
>>> as a transition empty package that only depends on python-oslosphinx. As
>>> a consequence, python-hacking needs to be updated to use
>>> python-oslosphinx, otherwise it wont have available build-dependencies.
>>>
>
>
> Thank you for bringing this to our attention, I wonder how we can detect
> this in our CI system in the future to prevent this.
>
>>>
>>> I was also thinking about providing a symlink from oslo/sphinx to
>>> oslosphinx. Maybe it'd be nice to have this directly in oslosphinx?
>>>
>>> Thoughts anyone?
>>>
>>> Cheers,
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.