[Spice-devel] Fixing the spice-gtk version scheme mess

[Hans de Goede]

Hi,

On 01/02/2013 11:46 AM, Marc-André Lureau wrote:
> Hi
>
> ----- Mensaje original -----
>>> If we want a new release, let's just do 0.16
>>
>> This is what we've been doing so far, and *it is not working*
>>
>> We keep on packaging git snapshots in Fedora and RHEL left and
>> right, showiing this scheme is broken.
>
> Please explain what is broken.

1) We've bugs + fixes (all good sofar)
2) We deem these fixes so important that we want to distribute
    them right away
3) We do so dark magic (be it git snapshots or adding patches
    to the packages) to get these fixes into Fedora / RHEL
4) Other downstreams which are not following upstream as
    closely as us, will be missing these fixes making them and
    us look bad!

Or iow: "There are other downstreams then RH, not doing bugfix
releases makes us a BAD upstream"

 > Btw, we do have release + patches in RHEL. And in Fedora, when we can't take a git snapshot (or when someone want to update with patches). If the tarball + patches is the same as git, we can take a git snapshot. No?

<sigh>, see above, we should never have any patches in Fedora,
if a bug is important enough to warrant a new Fedora package,
we should do a bugfix release so as to distribute the fix to
as wide an audience as possible. And, NO we cannot expect
other downstreams to follow git.


>
>> AFAIK we try to follow gnome / gtk / glib in how we deal
>> with most things. All of these have bugfix releases,
>> so has the kernel, so has spice[-server], and almost
>> any other free software project under the sun!
>
> No, spice-gtk doesn't follow gnome release cycle, version scheme etc.

Right, and that is a problem, I'm not saying we should do
bi-annual releases. But bugfix releases is a very common
practice all over the software ecosystem, and we should
follow it.

> I really try to keep git as stable as possible so we can release at any time. Bug or regressions can always occur no matter how you do. Then a new release is needed.

Right, because we all know how stable (any piece of) software is ...

I've been a packager for Fedora for 10+ years now, packaging
countless pieces of software. and your current practices
make us a shitty upstream to work with for distros. That is
not something to debate, that is a simple fact.

So I suggest we fix things and stop being a shitty upstream.

Also note that simply increasing our release frequency is not
a good answer. Distros like Debian will want to not jump on
the next release all the time, offering them older releases
with cherry-picked fixes is also part of why we need bug-fix
releases, so that when disruptive changes land, like the ABI
breakage of recent, they can still get bugfixes.

I'm not advocating to maintain older stuff for ages, but
at a minimum we must maintain the last release while developing
the next one.

>> Please stop stubbornly pushing your own versioning scheme,
>> AFAIK others have had this same discussion with you already
>> and told you we need bug fix releases.
>
> I still fail to see what problem we have by making releases this way.

1)

# cd ~/projects/fedora/spice-gtk/master
# fedpkg pull
# ls *.patch | wc -l
21

Now these seem to be dead never cleaned up patches, but they do
nicely illustrate my problem.

2)

Looking at the last 10 Fedora builds, not counting mass-rebuilds,
we have:
-3 rebase to latest release builds
-7 bugfix builds on top of those

3)

Looking at the latest spice-gtk version available for F-15, F-16,
F-17 and F-18, none of them has a "gold" release of spice-gtk.
All of them have some bugfixes on top. So apparently our "gold"
releases are NOT good enough for ourselves to distribute directly
to our users through Fedora, then how can we expect them to be good
enough for other distros?

Let me answer that for you: We should not and cannot expect them
to be good enough for other distros.

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.

Regards,

Hans