Open Stack

On 14/01/14 16:33 -0600, Ben Nemec wrote:
>On 2014-01-14 15:26, Doug Hellmann wrote:
>
>    In the release meeting today, Russell proposed that we at least include the
>    hash of the HEAD when the merge is done, to indicate how far along the oslo
>    changes are. More detail is obviously better.
>     
>    So, let's consider this as a new policy. Does anyone foresee issues with
>    making this work?
>     
>

+1 from me. Lets keep it simple. I agree with you on the fact that we
should be focusing more on graduating modules from the incubator.

>I don't see a problem with doing that, but I'm not clear on where we're
>including the hash.  In the file itself, in a separate file, and/or in the
>commit message?
> 
>Even if we do no more automation, having the commit hash of the last sync would
>be immensely helpful.  Not having to comb through commit logs to figure out
>when the last sync happened would be fantastic. :-)

We should keep it in the openstack-modules.conf file and put it in the
commit message as well. IMHO.

FF

> 
>-Ben
>
>     
>
>
>    On Tue, Jan 14, 2014 at 4:23 AM, Flavio Percoco <flavio at redhat.com> wrote:
>
>        On 13/01/14 12:07 -0500, Doug Hellmann wrote:
>        [.................]
>
>
>
>            I spent some time trying to think through how we could improve the
>            update
>            script for [1], and I'm stumped on how to figure out *accurately*
>            what state
>            the project repositories are in today.
>
>            We can't just compute the hash of the modules in the project
>            receiving copies,
>            and then look for them in the oslo-incubator repo, because we
>            modify the files
>            as we copy them out (to update the import statements and replace
>            "oslo" with
>            the receiving project name in some places like config option
>            defaults).
>
>            We could undo those changes before computing the hash, but the
>            problem is
>            further complicated because syncs are not being done of all modules
>            together.
>            The common code in a project doesn't move forward in step with the
>            oslo-incubator repository as a whole. For example, sometimes only
>            the openstack
>            /common/log.py module is copied and not all of openstack/common. So
>            log.py
>            might be newer than a lot of the rest of the oslo code. The problem
>            is even
>            worse for something like rpc, where it's possible that modules
>            within the rpc
>            package might not all be updated together.
>
>            We could probably spend a lot of effort building a tool to tell us
>            exactly what
>            the state of all of each common file is in each project, to figure
>            out what
>            needs to be synced. I would much rather spend that effort on
>            turning the common
>            code into libraries, though.
>
>            So, here's an alternative:
>
>            1. Projects accept a full sync of Oslo soon, including adding a
>            value in their
>            openstack-common.conf indicating which commit in oslo-incubator is
>            reflected in
>            the sync. We'll try to make those commit messages as detailed as
>            possible.
>
>            2. We modify update.py to remove the option to update individual
>            modules when
>            copying from oslo-incubator. The new version would always apply all
>            changes
>            from the last merged commit, as a series of commits, to the
>            receiving project.
>            So if nova is out of step by 3 commits, then 3 new commits would be
>            created in
>            the branch by the person doing the update, each with the commit log
>            message
>            from the change in oslo-incubator. (This lock-step approach is
>            necessary to
>            have any hope of figuring out which commits are actually being
>            synced, so the
>            log messages are accurate.)
>
>        In my experience, when syncing files from oslo, it'll most likely
>        require syncing more than one module. There's been just *few* times
>        where copying a module from oslo resulted in just that specific module
>        being copied.
>
>        All that to say that I agree with this point.
>
>
>
>
>            3. The person proposing the merge into the project can decide
>            whether to squash
>            the commits, or leave them as separate reviews.
>
>
>
>
>        If we use relative imports for modules in oslo incubators (as
>        mentioned in another email in this thread) and we *always* keep
>        everything up to the latest. What about reconsidering using git
>        submodules?
>
>        AFAIR, the main issue with git submodules is that we wanted to support
>        updating individual modules. If we remove that option, I think git
>        submodules would work just fine. Am I missing something?
>
>        Instead of hacking on update.py we could work on a migration plan out
>        of it.
>
>        A downside of using submodules is that when moving the reference in
>        the submodule, it won't be obvious why that's happening, which is
>        something we wanted to fix with update.py. It would be up to the
>        committer to write a good commit message or to get the messages out of
>        the submodule history.
>
>        Another downside is that it would be hard to apply isolated patches on
>        stable branches for security issues or really awful bugs.
>
>        I'm less convinced about submodules now but I'm leaving this in the
>        email in case someone wants to dig a bit deeper in the topic.
>
>
>
>            I'm not entirely certain I like this approach myself, but it's the
>            best I've
>            been able to come up with. It essentially gives us the current
>            process, while
>            removing the ability to potentially take a version of a module
>            without taking
>            its dependencies (allowing us to step forward, and track the commit
>            messages
>            accurately). It will also produce results similar to what we will
>            have when all
>            of this oslo code moves into separate libraries, where the changes
>            to the
>            library will be seen by the projects without any action at all on
>            their part.
>
>        After going through this for a bit, I agree with you. The goal
>        of the update script should be:
>
>           - Sync modules from the current state to the most updated version
>
>           - Make sure the update information is not lost. If there's an oslo
>             sync review without the commits shas + description, it simply
>             means the committer amended the message.
>
>
>
>            OTOH, it will also require spending time on update.py, instead of
>            releasing a
>            library from the incubator. And it doesn't really buy us that much
>            in terms of
>            making the sync happen more easily, other than a reliable way of
>            having
>            entirely accurate commit messages.
>
>        Although it distracts us from our real goal - releasing libraries - I
>        still think is necessary. We should probably just reduce the changes
>        needed as much as possible, but we'll need it anyway.
>
>
>
>            I would love to have someone else offer an alternative that's less
>            effort to
>            change and provides the desired detailed log messages accurately.
>
>        I think this actually simplifies the way update.py works, TBH. We'll
>        be removing single module sync and we'll also force projects to be
>        updated to the latest version of those modules in oslo-incubator,
>        which is safer, IMHO.
>
>
>        Cheers,
>        FF
>
>        --
>        @flaper87
>        Flavio Percoco
>
>        _______________________________________________
>        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.orghttp://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


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140115/00221c40/attachment.pgp>