public inbox for bzip2-devel@sourceware.org
 help / color / mirror / Atom feed
From: Federico Mena Quintero <federico@gnome.org>
To: "Mark Wielaard" <mark@klomp.org>,
	"Santiago Ruano Rincón" <santiago@debian.org>
Cc: bzip2-devel@sourceware.org,
	Anibal Monsalve Salazar <anibal@debian.org>,
	Anthony Fok <foka@debian.org>
Subject: Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <784d581eb491e4d6a5cb3acc28dd0cd47e49cc33.camel@gnome.org> (raw)
In-Reply-To: <c7957e5d2135cb1430ea335d825f453dee1b5924.camel@klomp.org>

On Tue, 2019-06-25 at 20:09 +0200, Mark Wielaard wrote:

> With that I think we are ready to do a bzip2 1.0.7 release simply by
> running
> ./prepare-release.sh 1.0.7 and ./update-release.sh 1.0.7.

I like this script!  Thanks for writing it!

> So if the above sounds like a good plan, then we can execute it now.
> Push out bzip2 1.0.7 and put the 1.0.x branch in hibernation, just
> for
> security or major bug fixes. Then we can concentrate on making sure
> that a bzip2 1.1.X (or maybe even call it 2.0?) has a modern build
> system and adds things like O_CLOEXEC support, etc.

I'm sorry for not replying to your mails earlier.  At work they just
moved us to another email provider, and I've had some trouble fixing my
email setup (SMTP servers, etc.) to make everything work as before.

I am... also ready to release 1.0.7 :-P  The work you've done in
updating the release scripts is valuable, and I'd like to propose this
instead:

* Put prepare-release.sh in the gitlab repository, and adjust it for
the changes there.

* Release 1.0.7 from the gitlab repo (it already has the NEWS file with
updates, while I think your repo needs a CHANGES to be written?).  I've
already tested that this works; "ninja dist" takes care of it.

* Keep the soname changes from the gitlab repo.  I think the original
Makefile-libbz2_so is incorrect in how it sets the soname (or at least
libtool thinks so), and both openSUSE and Fedora managed to change it
to a single digit instead of "1.0".  I *think* Debian, and distros
which picked up their patches from there, simply never changed this and
that's why they kept the "1.0" in place.

Whatever we change the soname to, it's going to be incompatible with
some distros - and they are already used to patching things, anyway. 
Maybe purely for my own convenience I'd like to remove the patches from
openSUSE - the current soname in the gitlab repo allows for that.

I would be fine with releasing 1.0.7 from the sourceware repo, and then
a subsequent 1.1 with all the changes from gitlab - but I think this
will cause extra work for the distros.  First they'll have to see which
of their patches need to be removed, and they'll still need to patch
the build system.  And with 1.1 released, they'll need to do it all
over again.

I think we can minimize the work for distros if we update the patches
and the build system in a single release.  They already know how to
handle Meson more or less automatically, while leaving the original
bzip2 Makefiles in place means that each distro has to patch to their
own hand-rolled build system all over again.

[I've sent a few subscribe requests to this mailing list as
federico@gnome.org, but it's not sending me the confirmation mail... do you know who may be able to kick the list software?]

  Federico

  reply	other threads:[~2019-06-25 19:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 Mark Wielaard
2019-01-01  0:00 ` Santiago Ruano Rincón
2019-01-01  0:00   ` Mark Wielaard
2019-01-01  0:00     ` Releasing bzip2 1.0.7 and 1.1.0 ? Was: " Mark Wielaard
2019-01-01  0:00       ` Mark Wielaard
2019-01-01  0:00         ` Federico Mena Quintero [this message]
2019-01-01  0:00           ` Mark Wielaard
2019-01-01  0:00             ` Federico Mena Quintero
2019-01-01  0:00               ` Mark Wielaard
2019-01-01  0:00                 ` Mark Wielaard
2019-01-01  0:00                   ` Federico Mena Quintero
2019-01-01  0:00                     ` Mark Wielaard
2019-01-01  0:00     ` Some cherry-picks (Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.) Mark Wielaard
2019-01-01  0:00       ` Federico Mena Quintero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=784d581eb491e4d6a5cb3acc28dd0cd47e49cc33.camel@gnome.org \
    --to=federico@gnome.org \
    --cc=anibal@debian.org \
    --cc=bzip2-devel@sourceware.org \
    --cc=foka@debian.org \
    --cc=mark@klomp.org \
    --cc=santiago@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).