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