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 <[email protected]> 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 <[email protected]> > Date: Sat, Oct 25, 2014 at 3:23 PM > Subject: Re: pbr refactor > To: Kenny Jones <[email protected]> > Cc: Mark McLoughlin <[email protected]> > > > 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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
