Open Stack

Hi, I have one patch pending, so the tests for the version calculation
and the version.py module itself are all that you need to care for, to
avoid conflicts.

-Rob

On 12 November 2014 11:54, Kenny Jones <kenny.jones at gmail.com> wrote:
> I have submitted the first patch which focuses on the initial refactor of
> pbr.packaging module.
>
> https://review.openstack.org/#/c/133607/
>
> With that change I have created the following modules:
>
> pbr
>     common
>     git
>     requirements
>     cmds (package)
>         build_doc
>         egg_info
>         install
>         install_scripts
>         sdist
>         test
>
> The commands module are meant to mimic what is done by setup_tools and
> distribute.
> All the git commands are moved into git module, requirements processing is
> moved into the requirements module, and the handful of truly common
> functions are placed within common.
>
> All references to packaging module within pbr (except version) have been
> replaced by the new module. All tests have been updated to test the new
> modules.
>
> I have a second set of changes prepared and tested, and will submit those
> after the above patch is merged that will focus on refactor of the version
> module. The details can be found below, but based on Doug's feedback I'm
> holding that patch to avoid conflict with Robert's SemanticVersion work
> unless Robert thinks it could accelerate his work by having the code base
> refactored.
>
> Any and all feedback welcome, and input on timing of the second patch.
>
> Thanks
> Kenny
>
> ---------- Forwarded message ----------
> From: Doug Hellmann <doug.hellmann at gmail.com>
> Date: Sat, Oct 25, 2014 at 3:23 PM
> Subject: Re: pbr refactor
> To: Kenny Jones <kenny.jones at gmail.com>
> Cc: Mark McLoughlin <markmc at redhat.com>
>
>
> Hi, Kenny,
>
> Sorry for the delay in replying; summit prep is taking a lot of my time
> right now.
>
> It sounds like you’ve done a lot of cleanup on the pbr code. I haven’t had a
> chance to look at the actual changes you’ve made, but I’ve tried to leave
> some general comments below.
>
> On Oct 21, 2014, at 12:50 AM, Kenny Jones <kenny.jones at gmail.com> wrote:
>
> Hi Doug and Mark,
>
> I've become a big fan of pbr for the past year. I wanted to add some
> features but after really going through all the code as well as the base
> setuptools and distribute libraries it seemed to be that pbr needed some
> refactoring to make it easier to support and manage.
>
> I forked the repository on github, and applied changes through 3 separate
> branches to keep the amount of changes smaller.
>
> https://github.com/shad7/pbr
>
> feature/packaging_refactor
> The focus of this branch was to refactor the packaging module which was
> doing so many different tasks that it seemed like the most logical starting
> place.
> I refactored the module into:
> common - the couple of utility functions that were used in several modules
> git - all the git related functions
> requirements - all the requirements processing functions
> package cmds - each command broken up into separate module similar to how
> setuptools and distribute are setup.
>
>
> The divisions you list make sense.
>
>
> feature/version_refactor
> The focus of this branch was refactor all the logic related to versioning.
> Some logic was previously within packaging, some within version module, then
> referenced in others. I broke up the logic
> into a package pkgversion (wanted to avoid conflict with module version and
> provide some backwards compatiability).
> __init__ is what the original version module had prior to semantic class
> being introduced
> semantic is the new semantic class
> metadata is the logic previously located with packaging, some pieces within
> Semantic and others within VersionInfo.
> I then updated the version module to reference the
> pbr.pkgversion.VersionInfo so that any team making direct use of the class
> would not be directly impacted.
> This change should also help with potentially separating all version logic
> into oslo.version, and leave packaging to pbr. But that is for future
> changes.
>
>
> Robert has some SemVer work planned or ongoing, so this might disrupt those
> patches. We may want to wait to take this set of changes until his patches
> are merged, to avoid extra rebases for either of you.
>
>
> feature/upload
> Small extension to support the upload command as separate from the packaging
> native to setuptools. The idea came from twine, but just extended the
> existing setuptools upload by providing lookup of the already built
> distribution archives such that upload would work separate from packaging.
>
>
> We have talked once or twice about disabling upload entirely and encouraging
> the use of twine, which handles secure uploads properly.
>
>
> All test cases work as before. Added some additional test cases I had
> written previously for requirements testing. And was able to verify it
> passed all pep8/hacking standards, and tested for all the configured
> versions of python.
>
> What I'm looking for is, are these changes of interest to the team, and what
> would be the best strategy for submitting them. I am familiar with
> submitting patches as I've gone through it previously with a minor change
> (requirements parsing). But due to delays in getting approval, other changes
> kept coming along that caused conflicts such that it never made it all the
> way to merge into master. Given the size of my changes, I thought it was
> best to reach out and determine interest and approach for successfully
> submitting and merging.
>
>
> The best thing is probably for you to submit patches for the changes, except
> I think the upload command since we favor using twine over direct uploads. I
> can’t promise fast reviews this cycle, since most of the team is going to be
> focused on continuing to graduate code from the incubator, but it sounds
> like most of what you have to propose is not very controversial. Keep in
> mind that the summit is coming up next week, so it will be some time before
> any of us are reviewing much code at all.
>
> Thanks,
> Doug
>
>
>
> Any feedback and thoughts appreciated.
>
> Thanks
> Kenny
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud