[sane-devel] autoconf and configure

[Olaf Meeuwissen]

Hi Ralph,

Sorry for the belated reply.  I've been travelling and catching up on my
SANE backlog in LIFO order :-/

littlesincanada writes:

> On 2019-09-01 5:54 a.m., Olaf Meeuwissen wrote:
> [...]
>> But perhaps we should get xsane's !1 merged first[4].
>>
> 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
> process.

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
> order):

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.
> configure.in->configure.ac)

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.

Good!

> 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.

Just ask.

> 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