[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?

[Kamil Rytarowski]

On 14.11.2011 18:16, Michael Scherer wrote:
> Le dimanche 13 novembre 2011 à 22:32 +0100, Kamil Rytarowski a écrit :
>> On 13.11.2011 10:58, Michael Scherer wrote:
>>> Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit :
>>>> On 12.11.2011 20:20, Michael Scherer wrote:
>>>>> Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit :
>>>>>
>>>>>> There is also one important patch missed in Mageia -
>>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's
>>>>>> dependency for the GNS3 simulator. OpenSUSE already includes it
>>>>>> https://build.opensuse.org/package/files?package=qemu&project=openSUSE%3ATools
>>>>>>
>>>>>> If nobody is against I will do it and contact the maintainer (misc).
>>>>> I prefer to wait on the stable release ( ie, no rc1 ).
>>>>> We will wait on stable version of qemu.
>>>> OK
>>>>> And no patch unless it comes from upstream ( and even, I am not keen on
>>>>> backporting feature, better wait for stable release ).
>>>>>
>>>> GNS3 is already in stable! This package is broken - no dynamips (=no
>>>> router emulation at all...), no patched qemu (no virtualization support
>>>> at all...) According to the developers and their online documentation
>>>> for package maintainers http://forum.gns3.net/post11571.html UDP patched
>>>> Qemu is dependency/very important.
>>> The fact that someone pushed a broken package is not a good reason to
>>> add patches to qemu.
>> OK, but I don't understand this.
>>
>> Why to keep defunct packages (this could be at least "major+ issue"  on
>> our bugzilla) in stable and don't even want to fix, ignore this academic
>> software (with maybe overall 1 000 000* downloads and 100 000 regular
>> users), and to support... the inadvisable opinion of Mageia around.. at
>> least the GNS3 users.
> Let me rephrase again. Everybody sooner or later think "that soft is
> great, but why do not add just a small patch there". That's just one
> patch, where is the problem ?
>
> The problem appear just after a few months, when the patch is still not
> upstream, and that someone who do not know C, python whatever has to
> take the software and maintain it. Or when someone who know how to
> program lose time rediffing the patch instead of doing something more
> useful. We face bugs that cannot be reproduced upstream, security
> problem that could be added in non reviewed patch by devs. Fragmentation
> in linux distributions are also caused by differents features, due to
> patchs.
>
> All of this need to be avoided, and I think we have enough problems with
> stuff that people do not want to take care of it to not add more burden,
> be it under the form of a small patch. All big collections start by one
> little stuff.
>
I see your point, but then tell why to keep GNS3 in our repos? What 
would you do? Patch GNS3 to cut the features from GUI? Then we will have 
next version of GNS3 (0.8.x is already in its way..).. well I quote what 
EXACTLY will happen:

>  The problem appear just after a few months, when the patch is still not
>  upstream, and that someone who do not know C, python whatever has to
>  take the software and maintain it. Or when someone who know how to
>  program lose time rediffing the patch instead of doing something more
>  useful

and ALSO

>  We face bugs that cannot be reproduced upstream

//Well I am more aware in this case due to lack o features/broken 
GUI/GNS3 then security problems...

I like this point:

>  All of this need to be avoided, and I think we have enough problems with
>  stuff that people do not want to take care of it to not add more burden,
>  be it under the form of a small patch. All big collections start by one
>  little stuff

But then what to do? Leave a broken package as it is - and just wait for 
bugs on our bugzilla - and support our quality - or remove it from the 
official repos?

Please remember that GNS3 is already in Mageia 1 and we still DO provide 
support of Mga1 for dozen of months.

We can of course hope that nobody will complain about it as long as we 
DO support Mga1 and wait for patch for Mga2 from upstream (very possible 
patch).

BTW. I had facied similar case before. Upstream of newer Xboard provides 
support for many chess variants, but lacks support for pieces in every 
board size. So I decided to patch the source myself to disable the 
partly supported board sizes - to make sure that the end user will have 
EVERYTHING working for sure. So I would also provide a special patch to 
cut qemuwrapper from GUI of GNS3 for our stable and hope to have it 
already fixed by qemu upstream for Mga2.
>> * 799 968 Windows Downloads (just from the sourceforge mirrors) of the
>> latest Windows binary of GNS3 (source
>> http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/)
>>
>>> We have too many patches on a general scale, and I
>>> do not want to end with a 2nd package like gdb.
>>>
>>> Patches make harder to upgrade, harder to make sure security is done
>>> correctly, and harder to ensure stuff are working ( since we are on our
>>> own when we patch something ).
>>> So for the patches, make sure it is upstream
>> It's not qemu upstream, it's GNS3 and its community upstream.
> If you want to have a feature in qemu, the road is "push it upstream".
> Once accepted upstream, it will sooner or later be in our packages.
>
This road if for developers not for package maintainers and users.

But the developers already are trying hard to push it upstream, with the 
support of community.


>>>    ( and given the discussion
>>> on ml, it should be soon )
>> When I ask the developers, they don't know if qemu will include the
>> patch at all and when (now or after one year) and they suggested to do
>> the openSUSE way (today the most recommended and full featured Linux
>> distro for GNS3).
> Maybe we are not talking of the same patch, but I am talking of this
> one :
> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html
I'm talking about the same one that is tried to push upstream -here is 
even a special repo for this patch: http://code.gns3.net/qemu-patches/log/7

The developers are preoccupied with the development of GNS3 and don't 
have manpower to submit patches for every software they rely on, so they 
ask community to do so, and they also use already patched (by the 
community!) qemu under Windows/MacOS for everyday.

> AFAIK, the patch have been accepted, just not committed yet. The last
> mail were from 1 week ago. The only issue is that they are in freeze for
> now, and the git web interface is down, and I do see the commit in my
> checkout about it so far.
>
I don't follow the development of qemu/gns3/qemu-patches/kvm/etc to know 
everything what when and how many times it was submitted or accepted by 
upstream. So I rely on the words of the developers of GNS3, and there 
really don't know if it will be finally in qemu 1.0.x or 1.1.x or later.
>>> and then in a tarball ( again, given that's a
>>> rc 1, that should be ok soon ).
>>>
>>>> We must fix the package and provide at least not so heavy broken ones...
>>>>
>>>> I've prepared new version of GNS3, included into svn dynamips and
>>>> xdotool (this one suggested) - these I can maintain with my mentor, so I
>>>> ask for patch qemu in stable versus UDP support.
>>> Updates are not supposed to get new features,
>> Well this is a special case - the bugfix provides the feature, or the
>> feature provides the bugfix.
> People will always tell "it is a special case". We can always say that
> any feature is a bugfix, provided we say that the bug is "I cannot do
> that".
>