Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Jan 23, 2013 at 01:48:32PM +0100, Marc-André Lureau wrote: The fedora package was updated in fedora/koji for the reporter to check if it solves his problem, before doing the release which was planned to come quickly after, as it did. There was only a few days between the two releases, and it was Christmas break. After this thread and the spice-gtk 0.17 release, I'm _very_ surprised to see some patches on top of the F18 and rawhide package, including (at least) one patch which is mandatory to build spice-gtk with newer gtk+ versions. jhbuild is one downstream user which is impacted by this issue. I haven't even seen this patch being sent to the mailing list, and I can't find it in the archive. If this was pushed without being sent to the list, this makes it even harder for anyone to be aware of the issue, and that it's fixed in git. Last but not least, your patches to the Fedora package are buggy: $ pkg-config --modversion spice-client-gtk-2.0 0.17-dirty Can we get a 0.17.1 release to fix all of this? Thanks, Christophe pgpC7XW5zERS4.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Feb 13, 2013 at 4:19 PM, Christophe Fergeau cferg...@redhat.com wrote: After this thread and the spice-gtk 0.17 release, I'm _very_ surprised to see some patches on top of the F18 and rawhide package, including (at least) one patch which is mandatory to build spice-gtk with newer gtk+ versions. jhbuild is one downstream user which is impacted by this issue. We don't go through review for trivial build fixes in spice-gtk. Also, those fixes are only necessary for unstable gtk+ releases afaik. Last but not least, your patches to the Fedora package are buggy: $ pkg-config --modversion spice-client-gtk-2.0 0.17-dirty It's on purpose, since it's not official version. Is that a problem? Can we get a 0.17.1 release to fix all of this? I'll do a new release, since other people depends on unstable gtk+ release. -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Feb 13, 2013 at 4:44 PM, Christophe Fergeau cferg...@redhat.com wrote: In my opinion, we should follow what libvirt does here, send the patch to the list with a note indicating that it has already been pushed to fix the build. This is very helpful to let others know about such fixes. People have been reporting this issue on IRC for a few days now, and it was only when someone said git was building fine that I noticed this fix and could help them. I would probably have remembered about it if I had seen the patch on the ML.. It should be first contributor reaction (or user who want to help) to try a git build. Not searching through a general ML treating various problems and projects related to Spice, at various point in time. I follow spice-commits list. I invite others who needs your approach to do that too. -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Feb 13, 2013 at 04:49:53PM +0100, Marc-André Lureau wrote: On Wed, Feb 13, 2013 at 4:44 PM, Christophe Fergeau cferg...@redhat.com wrote: In my opinion, we should follow what libvirt does here, send the patch to the list with a note indicating that it has already been pushed to fix the build. This is very helpful to let others know about such fixes. People have been reporting this issue on IRC for a few days now, and it was only when someone said git was building fine that I noticed this fix and could help them. I would probably have remembered about it if I had seen the patch on the ML.. It should be first contributor reaction (or user who want to help) to try a git build. Not searching through a general ML treating various problems and projects related to Spice, at various point in time. In this case, their initial reaction was to ask on IRC, which makes sense to me. And I couldn't help them as I didn't really have time to update gtk+, see if I could reproduce, ... I follow spice-commits list. I invite others who needs your approach to do that too. Well, spice-commits is not that convenient as you can sometimes get multiple commits in the same email. Moreover, 95% of the mails there are redundant with patches from the mailing list, so it's easy to miss the one commit that you did not see on the mailing list. So it would be very nice if you could run a quick git send-email --annotate after pushing such commits... Christophe pgpUQE4BEOg0V.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Feb 13, 2013 at 04:44:10PM +0100, Christophe Fergeau wrote: On Wed, Feb 13, 2013 at 04:23:12PM +0100, Marc-André Lureau wrote: On Wed, Feb 13, 2013 at 4:19 PM, Christophe Fergeau cferg...@redhat.com wrote: After this thread and the spice-gtk 0.17 release, I'm _very_ surprised to see some patches on top of the F18 and rawhide package, including (at least) one patch which is mandatory to build spice-gtk with newer gtk+ versions. jhbuild is one downstream user which is impacted by this issue. We don't go through review for trivial build fixes in spice-gtk. In my opinion, we should follow what libvirt does here, send the patch to the list with a note indicating that it has already been pushed to fix the build. FYI libvirt Fedora packages no longer carry patches as a general rule. Instead for libvirt we aim to provide stable release branches with trivial fixes applied. This ensures that the stable packages are easily available to everyone, not merely Fedora users. I'd encourage the same approach for spice too really. Daniel. -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Feb 13, 2013 at 05:17:25PM +0100, Marc-André Lureau wrote: Hi On Wed, Feb 13, 2013 at 5:14 PM, Daniel P. Berrange berra...@redhat.com wrote: FYI libvirt Fedora packages no longer carry patches as a general rule. Instead for libvirt we aim to provide stable release branches with trivial fixes applied. This ensures that the stable packages are easily available to everyone, not merely Fedora users. I'd encourage the same approach for spice too really. That's what I discussed earlier too, not maintaining patches in fedora but in upstream stable branch, so I agree. How often do you do a stable release then? I would just call that a stable snapshot, hmm whatever.. There is no fixed time frame. They are simply done whenever there is a critical mass of fixes to get out to users Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi, On Tue, Jan 01, 2013 at 11:37:26AM +0100, Hans de Goede wrote: Marc-André just did a new Fedora build fixing the SSL issues we we're having with 0.15 (thanks for that), but this is based on a git snapshot, and because of the way our buildsys code generates git snapshot tarbals is numbered 0.15.3 There are several problems with this: 1. If we've a serious bug like this, we should just do a new tarbal release with official announcements, updating of the download page, etc. Fedora / RHEL are not our only downstreams. Other distributions are packaging spice-gtk too, and we should behave as a good upstream for them. Doing an official 0.15.1 bugfix release would clearly indicate to those other upstreams that that is the version to use, rather then them having to pick a random git snapshot. After seeing the 0.15.3 git snapshot getting into fedora, I wanted to raise the same point, how do we get distros to know there is a critical fix for 0.15? After having read the whole thread, I agree with Hans that the current situation is messy, and that we generally should not package git snapshots or have patches in our fedora package. Of course, in some exceptional situations this can happen, in which case I'd rather we go with tarball+patches. But I agree with Hans that we currently are a bad upstream to work with from a distro point of view, and that we need to improve on that... Christophe pgpy_4nE1obpu.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Jan 23, 2013 at 10:29 AM, Christophe Fergeau cferg...@redhat.com wrote: But I agree with Hans that we currently are a bad upstream to work with from a distro point of view, and that we need to improve on that... The fedora package was updated in fedora/koji for the reporter to check if it solves his problem, before doing the release which was planned to come quickly after, as it did. There was only a few days between the two releases, and it was Christmas break. -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
On Wed, Jan 23, 2013 at 01:48:32PM +0100, Marc-André Lureau wrote: On Wed, Jan 23, 2013 at 10:29 AM, Christophe Fergeau cferg...@redhat.com wrote: But I agree with Hans that we currently are a bad upstream to work with from a distro point of view, and that we need to improve on that... The fedora package was updated in fedora/koji for the reporter to check if it solves his problem Such tests are generally done with a scratch build, not by pushing a git snapshot to Fedora. before doing the release which was planned to come quickly after, as it did. There was only a few days between the two releases, and it was Christmas break. You are ignoring what Hans has pointed out, that most of the time Fedora is not using a pristine upstream release, but an arbitrary git snapshot, so this is not only about this specific release. If you mean that from now on, fedora packages will only be based on official release tarballs with no additional patches, then all is good, and I think this should be fine with Hans as well. Christophe pgpiKnSfBnxaA.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi, On 01/23/2013 03:18 PM, Christophe Fergeau wrote: On Wed, Jan 23, 2013 at 01:48:32PM +0100, Marc-André Lureau wrote: On Wed, Jan 23, 2013 at 10:29 AM, Christophe Fergeau cferg...@redhat.com wrote: But I agree with Hans that we currently are a bad upstream to work with from a distro point of view, and that we need to improve on that... The fedora package was updated in fedora/koji for the reporter to check if it solves his problem Such tests are generally done with a scratch build, not by pushing a git snapshot to Fedora. before doing the release which was planned to come quickly after, as it did. There was only a few days between the two releases, and it was Christmas break. You are ignoring what Hans has pointed out, that most of the time Fedora is not using a pristine upstream release, but an arbitrary git snapshot, so this is not only about this specific release. If you mean that from now on, fedora packages will only be based on official release tarballs with no additional patches, then all is good, and I think this should be fine with Hans as well. Ack. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi - Mensaje original - Hi all, Marc-André just did a new Fedora build fixing the SSL issues we we're having with 0.15 (thanks for that), but this is based on a git snapshot, and because of the way our buildsys code generates git snapshot tarbals is numbered 0.15.3 There are several problems with this: 1. If we've a serious bug like this, we should just do a new tarbal release with official announcements, updating of the download page, etc. Fedora / RHEL are not our only downstreams. Other distributions are packaging spice-gtk too, and we should behave as a good upstream for them. Doing an official 0.15.1 bugfix release would clearly indicate to those other upstreams that that is the version to use, rather then them having to pick a random git snapshot. If we want a new release, let's just do 0.16 0 is major - bump only for API break 16 is minor - new releases of spice-gtk For ABI break, each library (spice-gtk/glib/controller) has independent visioning. 2. The way our make dist generates git snapshot tarbals, makes it impossible to do a 0.15.1 release now, since we now already have a 0.15.3 in Fedora. Because we don't need to with the scheme above. Each update in git is a third revision field getting bump after each commit. I would like to propose the following to resolve this: 1. Change make dist to add a .0 after the last official release, so that the git snapshot which was just generated would have been called 0.15.0.3. 2. Whenever we believe some bugfixes are important enough to warrant a new Fedora build, also do an official bugfix release, *and* use that for the Fedora packages, ie the 0.15.3 snapshot would have been an official 0.15.1 release I was waiting a couple more testing day before releasing 0.16 However, I'll do a couple of RC releases before making official releases next time. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi Nor can we realistically expect other distros to go and figure out which magic combination of fixes to apply! Therefor we *must* do bugfix releases, to make stable, well-working, versions of spice-gtk available to as wide an audience as possible. We only stick to a specific version in RHEL. Upstream doesn't have maintained older releases. What I understand you are complaining about is that upstream doesn't have sticky releases with only bugfixes. This is by choice, not by mistake. Now, if we want to share the bugfixes in an official way, we can maintain the RHEL branches upstream. If other distros have different schedule they will have to deal with their own release maintainance, as we don't do it for every releases. 0.16 will be releases as planned, so people following upstream will get the fix. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi, On 01/02/2013 05:02 PM, Marc-André Lureau wrote: Hi Nor can we realistically expect other distros to go and figure out which magic combination of fixes to apply! Therefor we *must* do bugfix releases, to make stable, well-working, versions of spice-gtk available to as wide an audience as possible. We only stick to a specific version in RHEL. Upstream doesn't have maintained older releases. The problem is upstream does not have maintained releases *at all*, you can leave out the older part, we are not even maintaining the current release, iow we suck. What I understand you are complaining about is that upstream doesn't have sticky releases with only bugfixes. This is by choice, not by mistake. This is by *your*, *personal* choice, not something we've decided as a team, and I say it is about time we change it, and I know for a fact I'm not the only one with the opinion that this should be changed. 0.16 will be releases as planned, so people following upstream will get the fix. They will get the fix *this time* because I complained. Doing a band-aid extra release is not the answer. You conveniently did not respond to me pointing out that all spice-gtk versions in F-15 to F-18 currently are not gold releases but all gold + patches, showing that the current scheme is simply broken. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fixing the spice-gtk version scheme mess
Hi - Mensaje original - Hi, On 01/02/2013 05:02 PM, Marc-André Lureau wrote: Hi Nor can we realistically expect other distros to go and figure out which magic combination of fixes to apply! Therefor we *must* do bugfix releases, to make stable, well-working, versions of spice-gtk available to as wide an audience as possible. We only stick to a specific version in RHEL. Upstream doesn't have maintained older releases. The problem is upstream does not have maintained releases *at all*, you can leave out the older part, we are not even maintaining the current release, iow we suck. Well, we do maintain upstream: I fixed the last regression just a few days after the release for instance. Ie, the bare minimum is to maintain upstream. As I said, I was planning to release 0.16 shortly after for more widespread distribution. Currently from the two reporters, only one did review the patches. The second in fedora bugzilla, didn't check it yet. It's been only 10 days since the last release, and we had christmas break. What I understand you are complaining about is that upstream doesn't have sticky releases with only bugfixes. This is by choice, not by mistake. This is by *your*, *personal* choice, not something we've decided as a team, and I say it is about time we change it, and I know for a fact I'm not the only one with the opinion that this should be changed. You suggested a different version scheme, I try to help pointing out what is the real problem, which is we are not maintaining older release in upstream. The versioning comes after, and doesn't need to be changed. 0.16 will be releases as planned, so people following upstream will get the fix. They will get the fix *this time* because I complained. Doing a band-aid extra I was going to release 0.16 because we had an important fix, not because of you complaining. release is not the answer. You conveniently did not respond to me pointing out that all spice-gtk versions in F-15 to F-18 currently are not gold releases but all gold + patches, showing that the current scheme is simply broken. Because some of us decided to maintain older release *in Fedora*. They are welcome to do so upstream and make releases tarball instead of cherry-picking from upstream. You are blaming ourself, it's a bit ironic. Making a branch such as 0.10 and making a tarball such as 0.10.0.3 should be fine, but I was told management doesn't like tarball and prefer individual patches. That's why I propose we maintain the branches upstream instead of doing it in Fedora rhel. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Fixing the spice-gtk version scheme mess
Hi all, Marc-André just did a new Fedora build fixing the SSL issues we we're having with 0.15 (thanks for that), but this is based on a git snapshot, and because of the way our buildsys code generates git snapshot tarbals is numbered 0.15.3 There are several problems with this: 1. If we've a serious bug like this, we should just do a new tarbal release with official announcements, updating of the download page, etc. Fedora / RHEL are not our only downstreams. Other distributions are packaging spice-gtk too, and we should behave as a good upstream for them. Doing an official 0.15.1 bugfix release would clearly indicate to those other upstreams that that is the version to use, rather then them having to pick a random git snapshot. 2. The way our make dist generates git snapshot tarbals, makes it impossible to do a 0.15.1 release now, since we now already have a 0.15.3 in Fedora. I would like to propose the following to resolve this: 1. Change make dist to add a .0 after the last official release, so that the git snapshot which was just generated would have been called 0.15.0.3. 2. Whenever we believe some bugfixes are important enough to warrant a new Fedora build, also do an official bugfix release, *and* use that for the Fedora packages, ie the 0.15.3 snapshot would have been an official 0.15.1 release Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
