QEMU release tagging script?

QEMU release tagging script?

[John Snow]

Hi,

Is there a script that's public that you use for tagging the QEMU 
release? I see make-release in scripts/, but that's for creating the 
tarballs after the tagging has been done.

I am looking into being able to cut releases for our Python QMP library, 
but due to constraints in the Python packaging ecosystem I have not yet 
been able to solve, it requires its own VERSION file.

It would be nice if when 5.2.0 is tagged that "0.5.2.0" could be written 
into ./python/VERSION as well.

(Effectively I am targeting using '0.' + VERSION. This is pending 
discussion on the python packaging series.)

Thanks,
--js

Re: QEMU release tagging script?

[Peter Maydell]

On Fri, 30 Oct 2020 at 13:32, John Snow <jsnow@redhat.com> wrote:
> Is there a script that's public that you use for tagging the QEMU
> release? I see make-release in scripts/, but that's for creating the
> tarballs after the tagging has been done.

I use this script:
https://git.linaro.org/people/peter.maydell/misc-scripts.git/tree/qemu-tag-release

> I am looking into being able to cut releases for our Python QMP library,
> but due to constraints in the Python packaging ecosystem I have not yet
> been able to solve, it requires its own VERSION file.
>
> It would be nice if when 5.2.0 is tagged that "0.5.2.0" could be written
> into ./python/VERSION as well.

I'm pretty strongly against having the version hardcoded
anywhere except the top level VERSION file. Everything else
should read the information from there.

thanks
-- PMM

Re: QEMU release tagging script?

[John Snow]

On 10/30/20 9:38 AM, Peter Maydell wrote:
> On Fri, 30 Oct 2020 at 13:32, John Snow <jsnow@redhat.com> wrote:
>> Is there a script that's public that you use for tagging the QEMU
>> release? I see make-release in scripts/, but that's for creating the
>> tarballs after the tagging has been done.
> 
> I use this script:
> https://git.linaro.org/people/peter.maydell/misc-scripts.git/tree/qemu-tag-release
> 

Thanks!

>> I am looking into being able to cut releases for our Python QMP library,
>> but due to constraints in the Python packaging ecosystem I have not yet
>> been able to solve, it requires its own VERSION file.
>>
>> It would be nice if when 5.2.0 is tagged that "0.5.2.0" could be written
>> into ./python/VERSION as well.
> 
> I'm pretty strongly against having the version hardcoded
> anywhere except the top level VERSION file. Everything else
> should read the information from there.
> 

Yeah, I know. I don't want to do it either, but I don't see an 
alternative that works with Python packaging tooling right now.

The problem is that whenever you run an install, (which runs a python 
"build"), the source is copied out into a temp directory where it loses 
all access to the parent directory and any knowledge of .git.

Perhaps someone has a solution, but I've not found one yet. The authors 
of pip are aware of the problem and are working on a solution, but we 
don't have one yet.

> thanks
> -- PMM
> 

Re: QEMU release tagging script?

[Daniel P. Berrangé]

On Fri, Oct 30, 2020 at 09:47:04AM -0400, John Snow wrote:
> On 10/30/20 9:38 AM, Peter Maydell wrote:
> > On Fri, 30 Oct 2020 at 13:32, John Snow <jsnow@redhat.com> wrote:
> > > Is there a script that's public that you use for tagging the QEMU
> > > release? I see make-release in scripts/, but that's for creating the
> > > tarballs after the tagging has been done.
> > 
> > I use this script:
> > https://git.linaro.org/people/peter.maydell/misc-scripts.git/tree/qemu-tag-release
> > 
> 
> Thanks!
> 
> > > I am looking into being able to cut releases for our Python QMP library,
> > > but due to constraints in the Python packaging ecosystem I have not yet
> > > been able to solve, it requires its own VERSION file.
> > > 
> > > It would be nice if when 5.2.0 is tagged that "0.5.2.0" could be written
> > > into ./python/VERSION as well.
> > 
> > I'm pretty strongly against having the version hardcoded
> > anywhere except the top level VERSION file. Everything else
> > should read the information from there.
> > 
> 
> Yeah, I know. I don't want to do it either, but I don't see an alternative
> that works with Python packaging tooling right now.
> 
> The problem is that whenever you run an install, (which runs a python
> "build"), the source is copied out into a temp directory where it loses all
> access to the parent directory and any knowledge of .git.
> 
> Perhaps someone has a solution, but I've not found one yet. The authors of
> pip are aware of the problem and are working on a solution, but we don't
> have one yet.

What does the  copying logic do when it sees a symlink ?   Can you keep
a "VERSION" file in the python subdir that is a symlink to the top level
"VERSION" file, such that when python copies the source files to the temp
dir, it deep copies the symlink content. 


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: QEMU release tagging script?

[John Snow]

On 10/30/20 9:51 AM, Daniel P. Berrangé wrote:
> On Fri, Oct 30, 2020 at 09:47:04AM -0400, John Snow wrote:
>> On 10/30/20 9:38 AM, Peter Maydell wrote:
>>> On Fri, 30 Oct 2020 at 13:32, John Snow <jsnow@redhat.com> wrote:
>>>> Is there a script that's public that you use for tagging the QEMU
>>>> release? I see make-release in scripts/, but that's for creating the
>>>> tarballs after the tagging has been done.
>>>
>>> I use this script:
>>> https://git.linaro.org/people/peter.maydell/misc-scripts.git/tree/qemu-tag-release
>>>
>>
>> Thanks!
>>
>>>> I am looking into being able to cut releases for our Python QMP library,
>>>> but due to constraints in the Python packaging ecosystem I have not yet
>>>> been able to solve, it requires its own VERSION file.
>>>>
>>>> It would be nice if when 5.2.0 is tagged that "0.5.2.0" could be written
>>>> into ./python/VERSION as well.
>>>
>>> I'm pretty strongly against having the version hardcoded
>>> anywhere except the top level VERSION file. Everything else
>>> should read the information from there.
>>>
>>
>> Yeah, I know. I don't want to do it either, but I don't see an alternative
>> that works with Python packaging tooling right now.
>>
>> The problem is that whenever you run an install, (which runs a python
>> "build"), the source is copied out into a temp directory where it loses all
>> access to the parent directory and any knowledge of .git.
>>
>> Perhaps someone has a solution, but I've not found one yet. The authors of
>> pip are aware of the problem and are working on a solution, but we don't
>> have one yet.
> 
> What does the  copying logic do when it sees a symlink ?   Can you keep
> a "VERSION" file in the python subdir that is a symlink to the top level
> "VERSION" file, such that when python copies the source files to the temp
> dir, it deep copies the symlink content.
> 

It either doesn't copy the symlink at all, or it shallow copies and 
breaks the link:

FileNotFoundError: [Errno 2] No such file or directory: 'QEMU_VERSION'

So I am meekly asking for the concession of adding an extra step to the 
qemu-tag-release script.

--js