[virt-tools-list] [PATCH-v5.5 5/5] virt-manager version-id changes

[Gene Czarcinski]

On 04/11/2013 12:28 PM, Cole Robinson wrote:
> On 04/11/2013 12:16 PM, Gene Czarcinski wrote:
>> On 04/10/2013 06:29 PM, Cole Robinson wrote:
>>> Gene, I'm sorry, but I truly have no interest in maintaining this as part of
>>> virt-manager. The problems you describe affect just about every open source
>>> project I've worked on, so even though it_is_  sub optimal it's common enough
>>> that it clearly doesn't cause too much grief, so it doesn't warrant such a
>>> complex solution.
>> OK, lets step back a moment.  Before, considering how something is
>> implemented, I want to consider what is implemented and I have the following
>> separate issues.
>>
>> 1.  When python setup.py sdist is run and IF we are running under a giot-clone
>> repository, then there should be a check made for outstanding/uncommited
>> changes and if such changes exist, creating the tarball should be aborted.
>>
>> My reasoning is that the tarball should have a "good, known base."
>>
>> There is the possibility that python setup.py sdist was not run under a
>> git-clone repository, the execution should proceed.
>>
> If we add the MANIFEST file, I don't see why this is required really. What if
> I want to create a test RPM with uncommitted changes, why should that be
> disallowed? That's not a pathological example either, I've certainly done that
> on several occasions when making big build system changes. Yes, I could commit
> my changes first, but really, why add code to enforce it?
Our development/work-styles differ.  I break "large" efforts into multi 
commits and multi branches so that I can easily back our of something 
back to something "known" to work.  When I complete what I wanted to do, 
I then "repackage" all of the small changes into a single bigger change.

But, I can also understand where you are coming from and why building a 
tarball and/or rpm with uncommitted changes makes sense.

"Ideally," I would like to see the check being done unless some override 
was set to "just do it, don't ask questions" as that is sometimes what 
needs to be done.

This is not something I am going to fall on my sword for.
>
>> 2.  Never mind what it is or how it is done, is it desirable to have some sort
>> of snapshot id?  Yes, many projects have this problem, but that does not mean
>> it should be ignored.
>>
>> My submitted solution has many problems including that it is way
>> over-engineered.  I forgot the KISS principle.  I was looking for something
>> simple and the solution got a life of its own.
>>
>> While it might be "nice" to capture the information returned by
>> git-describe--tags, the real issue (IMHO) is to have some simple version
>> differentiator for tarball and rpm names ... autobuild.sh does provide a
>> differentiator for the RPMs it builds.
>>
>> RPM maintainers also do their own differentiation when they build an updated
>> version of some program which is not based on an official release but instead
>> a point-in-time snapshot of a git repository.
>>
>> So, back to the basic question: is a snapshot file-name differentiator
>> something desirable?
> I understand why having an RPM and tarball with a git commit/tag derived
> version is useful for certain usecases. But I don't think it's sufficiently
> useful that we should do it by default or complicate the build system to do so.
Having a git derived version (e.g., based on git-describe--tags) for the 
tarball would work but IMHO it would not work for RPMs (they like 
increasing version ids and the commit id is not that). However, it would 
be "nice" to have this information tucked away somewhere (maybe like for 
the --version response) so that if you are running and you need to get a 
better handle on just what you are running ... there is something to 
tell you.

Whatever is done, it needs to be done ONCE, and only once, when the 
sdist tarball is created.  Like I said, the submitted patch got a life 
of its own and wandered into swamps best left unexplored.
>
> I think this can be solved by adding an option to sdist or rpm subcommands
> that allows temporarily overwriting __version__. Then all the __version__
> building logic can be moved to an external script, which just passes the value
> to setup.py
Great minds and all that stuff.

This is more or less the approach I thought to look into.  Something 
where the default is as it now is but with some means of specifying a 
"user version" override when sdist is run.

My current approach is to make sure I break things up into small pieces 
each of which can be addressed on its own merits.

One such small piece I intend to submit:

Bring back virt-manager.spec.in with @VERSION@ ... virt-manager.spec.in 
would be git tracked but virt-manager.spec would not ... add "my_dist" 
to setup.py which copies spec.in to spec and replaces @VERSION@ with 
whatever the "version id" is (currently cliconfig.__version__).

This is more of a simple automation to replace requiring both 
virtcli/cliconfig.py and virt-manager.spec be modified to change the 
version with just a single update.  If some SIMPLE means of having a 
"user version" override, this would fit in.

BTW, I still prefer using git-tags to specify versions, subversion, RCs, 
etc.

Gene