[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: creating a bison-announce list

From: Simon Richter
Subject: Re: RFC: creating a bison-announce list
Date: Thu, 27 Dec 2018 04:29:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0


On 24.12.18 18:00, Akim Demaille wrote:

> Recent history has shown that bugs are discovered too late, in a rather 
> incremental fashion (I'm about to release 3.2.4), mostly revealed when Bison 
> is finally updated in the main distros.  I believe that much of this could 
> have been avoided if Bison users were given a chance to try a beta before the 
> final release, or even if Bison users were warned about a new release earlier.

I think the problem is that most users use bison through the
distributions and are just updating when new packages turn up.

For Debian, there'd be the option of making pre-releases available as
"experimental" packages that the package manager will not select
automatically unless being explicitly instructed to. Not sure how other
distributions handle this.

Ideally, what we'd want is for users to test new Bison versions before a
new release is tagged, and give feedback early on. Setting up a CI
system that pulls "experimental" Bison into a chroot and test-compiles a
project there is doable with medium effort, but we'd have to actively
convince people to do that, and package maintainers would have to be on

I'd possibly be interested in prerelease tags in git that match a
certain regex (/*rc*/ would probably work), so I can have Jenkins
monitor that, that is more useful to me than a mail.

I'm not sure there are many people left who build Bison from source
packages and use it themselves -- those would be the target audience of
the announce mailing list. On the other hand, if there is a prerelease
tag, writing a mail about that might still be useful to someone.

What would also be possible would be a CI system that test-compiles a
number of prominent open source projects with HEAD Bison and feature
branches before merging, but that would also require volunteers to
actually do this. On the upside, these don't need to be distribution
package maintainers, and it might even be feasible to do this as a
(somewhat boring) GSoC project.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]