From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17214 invoked by alias); 26 Jun 2019 10:56:03 -0000 Mailing-List: contact bzip2-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Sender: bzip2-devel-owner@sourceware.org Received: (qmail 17078 invoked by uid 89); 26 Jun 2019 10:56:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Continue, head!, voice, IT X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Message-ID: <3b31bd0d2d1119ce7ded04b383a0db7f0576c50b.camel@klomp.org> Subject: Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q. From: Mark Wielaard To: Federico Mena Quintero , Santiago Ruano =?ISO-8859-1?Q?Rinc=F3n?= Cc: bzip2-devel@sourceware.org, Anibal Monsalve Salazar , Anthony Fok Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: <28b061f6f1e5ea10de587c99b02817036b6f934e.camel@gnome.org> References: <1561362056-4393-1-git-send-email-mark@klomp.org> <20190624083116.GN6125@bartik> <784d581eb491e4d6a5cb3acc28dd0cd47e49cc33.camel@gnome.org> <28b061f6f1e5ea10de587c99b02817036b6f934e.camel@gnome.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2019-q2/txt/msg00014.txt.bz2 On Tue, 2019-06-25 at 21:22 -0500, Federico Mena Quintero wrote: > What do you think of me doing this: >=20 > - Create a "bzip2-1.0" branch with the commits and contents of the > sourceware repo. >=20 > - Sync the sources? Are there any changes in the gitlab master > branch > that you *don't* want? >=20 > - 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. >=20 > - 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. >=20 > - 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=20 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