Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.

[Mark Wielaard]

On Tue, 2019-06-25 at 21:22 -0500, Federico Mena Quintero wrote:
> What do you think of me doing this:
> 
> - Create a "bzip2-1.0" branch with the commits and contents of the
> sourceware repo.
> 
> - Sync the sources?  Are there any changes in the gitlab master
> branch
> that you *don't* want?
> 
> - Release 1.0.7 out of the bzip2-1.0 branch; deprecate that branch
> immediately.  Advertise it as targeting people who embed bzip2-1.0.6
> in
> their sources and probably already have customizations to the build
> system themselves.
> 
> - Continue with the current development in the master branch; I'll
> probably release 1.1.0 as an experimental release with the new build
> stuff and all the fixes.  Advertise this as targeted to distros and
> everything else.
> 
> - Rust goes in a separate branch as usual; it's going to need some
> big
> changes to the new build system anyway.

I would like to do the release from the sourceware.org git repo first
as is. And only then create a 1.0.x branch from it. That way we have
something that simply replaces the bzip.org releases and establishes 
https://sourceware.org/bzip2/ as new (or technically old) home for
bzip2, have an official download location, updated regenerated manuals,
etc. Then we can tweak the homepage through bzip2-htdocs.git to point
to a future development tree if you don't like to use the sourceware
bzip2.git repo as main development platform.

But I like to keep a (mirror) of the 1.0.x branch on sourceware so that
it is easy to keep making (emergency) releases from it if necessary. I
don't expect there to be many of those though. Given that the last 10
years provided 5 meaningful bug/security issues, there might be a bzip2
1.0.x release maybe once every 2 years.

I don't think we want any of the other changes from the gitlab tree
because they are all potential build issues, not purely bug fixes. e.g.
even the simple #if BZ_UNIX scares me a little.

I am sorry we didn't properly discuss and communicated what we expected
from resurrecting/maintaining bzip2. Especially since we seem to be
somewhat opposite developer/personalities. I am probably a conservative
minimalist, while you seem more of a maximalist modernist. But I hope
we can make cooperation work, because we probably need both types of
people/developers to maintain bzip2 for the next 20 years :)

For me the most important thing is that we provide a more stable home
for bzip2 than bzip.org was. And sourceware is that to me because it
existed even before bzip2, bzip2 had its home originally on
sourceware.org/bzip2, it is community managed and the site, git sources
and downloads/releases are widely mirrored. And that we don't break
anything, not even accidentally, which is why my 1.0.7 release really
only contains the minimal amount of changes just to update the
homepage, release number and fix any known bug/security issues, but
absolutely nothing more.

For you it is probably more important to have a modern build system, a
place to hack on it that makes it easy to exchange patches,
automagically mixes them with "pull requests" and issue tracking,
making the barrier to entry for people as low as possible, make it easy
to clean up and refactor the code, etc. all as long as it doesn't break
ABI of course. So that the code/community lives again to provide some
innovation.

Those things bite a little. Ideally they wouldn't of course, so we get
both stability and progress. But I would have never guessed someone
would pick a personal repo on a commercial (partially proprietary) run
platform. While you probably cannot imagine why someone would think a
place that offers bugzilla as issue tracker and primarily uses
mailinglists to exchange patches would be a good home for the project.
The conservative in me already freaks out about a simple change like
you just pushed to change the format of the version string returned by
BZ2_bzlibVersion (). What if someone parses it and expects that comma!
screams a little voice inside my head! Even though of course any code
that does that is obviously broken, and if we cannot even change that,
then what innovation can we do?

Anyway, I hope that explains why I care so deeply about what is there
now in the sourceware bzip2.git repo, and why I think we should keep
releasing that branch as is through sourceware.org. Even if we then
turn it into a branch that will never really change again and we point
the homepage repo sources links, to somewhere else for all future
development (in which case I would happily setup a mirror to make sure
the sources, releases and updated documentation are also available on
sourceware).

I do think you take the SONAME change too lightly though. But I don't
have a good answer for it. So my conservative reaction is DO NOT CHANGE
IT! Even though I think OpenSuse, Fedora and some other distros were
right to "fix" it to just contain one version digit. But sad fact is
that they were also wrong, because upstream is always right (even if it
is wrong) when it comes to compatibility. Changing the SONAME is
breaking ABI. And a lot of other distros didn't change it, and so
cannot without breaking ABI for the foreseeable future (I noticed even
the freedesktop flatpak runtime contains bzip2.so.1.0).

Cheers,

Mark