[sane-devel] Git best practices for proper application of patches

Paul Menzel paulepanter at users.sourceforge.net
Mon Feb 11 23:26:39 UTC 2013

Am Montag, den 11.02.2013, 16:31 -0500 schrieb m. allan noah:
> Sane is an ancient project by FLOSS standards, and in those many
> years, has developed some bad habits. Some of these are by necessity,
> as it is difficult or impossible to properly review code for hardware
> you don't have. Some of these habits are by choice- most of us would
> rather use our limited hours to write code for hardware we do have,
> than write docs or sometimes even update tickets. We get enough
> 'proper' procedure in our day jobs :)  We also have a massive number
> of developers who have moved on to other interests, yet their backends
> are still (marginally) supported by the sane project. This increases
> the burden on the remaining devs somewhat.
> All-in-all, sane is a bit of a mess. I'll be the first to take the
> blame for that, as I have not done a good job recruiting new devs, and
> I have not kept up with all the housekeeping duties. Releases are
> sporadic, bugs are not assigned, known issues to core infrastructure
> are not fixed, and sometimes moderated emails sit for a day or two
> before I get a chance to review them. So, I am acutely aware of your
> concerns, and agree with some of them.

I am certainly in no position to tell you what to do. You should
consider my messages as a view point from some FLOSS user trying to fix
a thing a bug in SANE and while at it trying to improve the things I

If you get feedback from non SANE developers often, then fine. But
people will notice them again and again and get a bad first impression.

So to your points above, in my opinion one has to enforce some policy
nevertheless because in the end it will bite everyone later on.

Proper commit messages (summary, empty line, message body with
description) will even save time of writing that ChangeLog file, you can
easily generate from `git log --format=oneline` (plus some arguments) as
other projects are doing.

> However, I do NOT like your methods. It appears that you know very
> little about sane, its protocol, or it's history.

I am the first to admit that. Why should I need to know about that,
wanting to submit a bug fix?

> Yet you find it necessary to ask bug-reporting end users for an
> education (when their request is perfectly clear) [1],

As commented, I do not see a problem with asking questions. If you do, I
am sorry for violating some rule I do not know about. The reporter
always has the choice to answer or not to answer.

> you give incorrect information in the bug tracker [2][3],

As I already answered to Stef, my statement was not absolute and indeed
is partly true and in [3] I asked a question after searching for that on
the Web.

> and you waste the bug reporters time asking them to provide useless
> data like a description of the scanner or a pointless downstream bug
> report [4].

Are you involved in packaging stuff. I am involved in the Debian project
and having downstream and upstream reports is certainly appreciated
there. (That is another problem: communication between upstream and

> So, how about you talk less, and code more.

The same I could say to you, how about you accept criticism and not be
offended by it – as when people are offended, most of the time they know
the criticism is justified –, also talk less by writing these answers
and enforce some sane development guidelines for SANE living up to the
current standards in other projects so that people just wanting to
contribute some small fixes feel welcome and can use the methods they
are used to from other projects?

> Get the patches you submitted to completion (so otherwise busy folks
> like stef don't have to do it for you).

He never needed to complete it for me. He could also have told me, that
it is incomplete and I would have fixed it. It was his choice to do as
he did.

> Find some more bugs in the tracker to produce patches for. Be prepared
> to spend your own money to buy scanners just so you can verify your
> code. Then, consider picking up one of the unmaintained backends. That
> is how the rest of us got started. Once you reach that point, you will
> have a much better understanding about what the problems are with
> SANE, and you will be in a better position to help correct them.

I certainly never had and do not have any intention to become a SANE
developer. (And I guess that is also good for Stef, you and myself. ;-))

Seeing that my intended help causes more harm than good, I am going to
only find the cause of the Simple Scan crash my parents experience with
the HP Photosmart 2610 and will not disturb you any longer.

Good luck to you all and SANE.



> [1] https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=313734&group_id=30186
> [2] https://alioth.debian.org/tracker/index.php?func=detail&aid=314021&group_id=30186&atid=410366
> [3] https://alioth.debian.org/tracker/index.php?func=detail&aid=314019&group_id=30186&atid=410366
> [4] http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030902.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130212/5e9d185e/attachment.pgp>

More information about the sane-devel mailing list