[sane-devel] No response to merge requests for the genesys backend

[Povilas Kanapickas]

Hey Olaf,

Thanks for reply!

On 09/11/2018 13:40, Olaf Meeuwissen wrote:
> Hi,
> 
> Povilas Kanapickas writes:
> 
>> Hi Gerhard,
>>
>> On 11/10/2018 08:44, Gerhard Jäger wrote:
>>> Hi Povilas,
>>>
>>> On 10.10.18 at 23:31 Povilas Kanapickas wrote:
> 
>>>> If there's lack of manpower, is there any way I could be more involved
>>>> in the project? I think sane serves an important mission by letting
>>>> people use very old scanner hardware indefinitely, even after the
>>>> proprietary drivers are no longer available for the operating systems
>>>> used at the time. Over time this will significantly reduce the amount of
>>>> perfectly good hardware thrown away at least in this sector.
>>>>
>>>> I have substantial experience developing low level systems software, so
>>>> I'm confident I could potentially be useful to the project.
>>>
>>> I have the feeling that every new developer who likes to contribute
>>> is welcome. Regarding pending and necessary work, Olaf has the overview.
> 
> The overview is up at https://gitlab.com/groups/sane-project/-/issues
> 
> Oh, and for SANE Project members with merge permissions, also at
> https://gitlab.com/groups/sane-project/-/merge_requests of course.
> 
>>> If you'd like to take over maintenance of a certain backend - no
>>> problem - I'd say.
> 
> As long as you work things out with the current maintainer(s), if any.
> They're listed in the AUTHORS file with a (*) behind their name.  If
> there are none ..., no-one's gonna object much ;-)

Will talk to Gerhard.

>> Maintaining a backend could be a long term goal. I'm mostly interested
>> in the genesys backend right now because I have access to more hardware.
>> Of course it all depends on the the plans of the current maintainer :-)
>>
>> If there's lack of interest and time, I could take over maintenance
>> sooner rather than later. The only issue in this case would be access of
>> hardware - I would not feel confident without a way to test most
>> configurations end to end and getting all the scanners would take some time.
> 
> That's a problem all of the backend maintainers have.  Most only have
> access to a very limited set of devices that are supported by the
> backend(s) they maintain.  Most of the time you just have to act in good
> faith and rely on people out in the field to test you didn't break
> things for their device.
> 
> Special casing code for a certain device migth be an option but doesn't
> scale very well for backends that support more than a handful of devices.
> 
> Still interested?  Just request access to the sane-project group as a
> whole at https://gitlab.com/groups/sane-project/-/group_members or just
> the backends project (if not interested in any of the other projects) at
> https://gitlab.com/sane-project/backends/project_members.
> 
> Hope this helps (and apologies for the belated follow-up).

Yes, I'm still interested. I've shopped around the local used hardware
market and got some scanners that cover most of the currently supported
chipsets. So even testing will be less of a problem for me.

I've opened the page for backends project
https://gitlab.com/sane-project/backends/project_members, but it does
not allow me to request access. According to
https://docs.gitlab.com/ee/user/project/members/, maybe request access
to projects is disabled?

One of the things that I'd like to do long term would be to create a
test framework that works at libusb layer, so that we could intercept
data what data is written where and how the code behaves depending on
what data is read. The we could compare that to known good replays. We
could run such tests on Gitlab and hopefully catch the majority of
regressions.

Also, it would be great if we could add hooks that capture live data
from scanning sessions and create tests based on that. We could ask
users with hardware that we don't access to, but which still works to
scan some blank page and send a log to us. This way we could create a
regression suite with which we could be reasonably sure that old device
support code does not bitrot.

Thanks!
Povilas

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