[sane-devel] XSane's future (was Re: [janitorial] post 1.0.28)

[Olaf Meeuwissen]

Hi Ralph,

Ralph Little writes:

> On Wednesday, August 7, 2019, 6:26:43 a.m. PDT, Olaf Meeuwissen <paddy-hack at member.fsf.org> wrote:
>
>> Apart from that, I don't think we want to wait another two years or so
>> for our next release. I would like to see our next release in four to
>> six months. And the ones after that in a similar time frame. How's
>> that sound?
>
> Sounds good!
> Perhaps we should be thinking about a future schedule for releasing a
> version of xsane.  There are a lot of changes in the pipeline.

I assume that would be the libpng fixes and compiler warning fixes,
mostly. Or did you have something else in mind as well?

> Who is the official maintainer of that now? It has not been released
> for a number of years.

To be honest, I'm not sure who's the official maintainer now.

The communication I had with Oliver Rauch, the author of XSane, while
preparing the frontend/xsane git repository we have now didn't give me
the impression that he was very eager to keep maintaining it.  He hasn't
applied to become a member of the project/group on GitLab.com (despite
me suggesting several times he do so) so I guess it's up to the SANE
Project members now.

@Oliver> If my impression's wrong, please say so!

> And perhaps it is time for a version 1.0?

I'm fine with a 1.0.0 and suggest using [semantic versioning][1] for
future releases.

 [1]: https://semver.org/

>> Next, squatting all the compiler warnings on Debian 10. I really
>> would like to keep the build "clean" on Debian's stable. Getting (and
>> keeping) it clean on Alpine and Fedora are secondary targets.
>
> I don't mind helping with that.

Great, but that means we have to hash out an approach to go about this
without duplicating work.  Also, I'm pretty sure there are warnings in
the same categories (but different places) that were fixed in 1.0.27.
It would be nice to fix the new ones in a similar way where possible for
consistency's sake.

I've added a ["place holder" issue][2] to try and coordinate this.

 [2]: https://gitlab.com/sane-project/backends/issues/120

> I will also be dealing with the compiler warnings from xsane. Many of
> those are warnings about ignoring return codes from I/O functions
> which seems like a pretty bad idea in general, and I assume many in
> the backends are going to be similar.

I don't remember seeing a lot of those but there are plenty about unused
variables/parameters as well as tautological assignments (meant to make
unused variable/parameter warnings go away).

>> For upstreaming of downstream patches, ditto.
>
> I also am happy to look into this.

I've added an [issue][3] to coordinate this as well.

 [3]: https://gitlab.com/sane-project/backends/issues/121

> I have started the process for xsane.

Good.

> If anyone could comment on my commit message style on the xsane repo,
> then I would welcome any suggestions, along with any pointers on what
> else should be included.

For generic advice, see the [Contributing to a Project section in the
Pro Git Book][4].  Sticking to the format described there is highly
recommended.  For the backends project, we often include the backend
name or component affected in the title.  Have a look at the git log and
you'll see plenty of commit message titles that are formatted like

 genesys: Split table into separate files

Whether the more detailed text after a blank line is warranted depends
on the complexity and intent of the commit and how well the title
already covers all of that.

FWIW, your xsane commit messages look fine to me.

 [4]: https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project

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