[sane-devel] autoconf and configure
paddy-hack at member.fsf.org
Sun Sep 29 04:49:40 BST 2019
Sorry for the belated reply. I've been travelling and catching up on my
SANE backlog in LIFO order :-/
> On 2019-09-01 5:54 a.m., Olaf Meeuwissen wrote:
>> But perhaps we should get xsane's !1 merged first.
> Yes indeed and that is well underway.
# For everyone's record, it has been merged on 2019-09-19.
> OK, some of my questions might seem like I'm jumping the gun a little,
> but I'm trying to put together a TODO list of things for the coming release.
> I'll use gitlab to put together something like a roadmap of items to
> work through. For that I do need to know a bit more about established
I see that you've already submitted a small pile of issues and added
some to a 1.0.0 release milestone :-) :+1:
> Currently, that's looking something like (though not necessarily in this
Looks like a plan to me! ;-)
> 1) Downstream patches
> 2) Compile warnings
I see you've started on those already.
> 3) autotools update:
> ?? a) Remove generated files
> ?? b) Update remaining files to conform with modern practice (e.g.
This can be done independently from the compile warnings.
> 4) Implement any remaining gitlab processes for release cycle
For the backends, we're using GitLab's CI to
- build on every push (for several distributions) and make a source
tarball available for successful builds for a limited time
- automate the release process
I suggest something similar for XSane.
> 5) Updates required on displayed and source copyright notices depending
> of what has been agreed with Oliver.
> 6) Requests for translation. (Perhaps I could reach out to the po patch
> authors to see if they're also interested.)
Good idea but note that most of the contact info is probably stale.
> 7) Confirm current minimum supported dependency versions (I'm not sure
> that much if anything is required here, but I will think about it. I'm
> thinking primarily about GIMP)
The configure script can/should check for those once you've made up your
mind about them. CI can be set up to test compilation on several
version combinations if desired.
> 8) Check internet links in source to make sure they point at the
> relevant gitlab and SANE web pages. Some of the downstream patches deal
> with this also.
> 9) Full regression testing, exploring all aspects of the application to
> ensure proper functioning. There is one compiler warning that signals a
> definite *serious* bug which I will have to deal with.
Definitely a good idea but probably an awful lot of work. Long term
plan, I guess.
> 10) How do we announce the release to downstream? Do we just hope they
> notice or is there a process?
At the moment, we just send mail to the sane-announce list (assuming
that downstreams subscribe).
> I suspect I will need some help from you for at least 4) above.
> A lot more pie-in-the-sky for *much* later on would be a move to GTK3.
> That's where my thinking is at the moment.
> Feedback always appreciated.
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
More information about the sane-devel