[sane-devel] sane-backends 1.0.19 Code Freeze

[René Rebe]

Hi,

On Wednesday 23 January 2008 15:38:26 m. allan noah wrote:
> On Jan 23, 2008 6:14 AM, René Rebe <rene at exactcode.de> wrote:
> > On 23.01.2008, at 02:47, m. allan noah wrote:
> > > Note #1:
> > > This will be (hopefully) the last release of the SANE 1.0 series. The
> > > next release of SANE will be extended (in a backwards compatible
> > > fashion) to support more features of modern scanners. Please join the
> > > sane-devel mailing list to take part in the ongoing discussions of the
> > > future of SANE.
> >
> > I find this alarming for two different reasons. First of all SANE
> > already
> > historically had a slow release cycle and it should not follow other
> > projects
> > into slow and ever breaking development.
> >
> > Additionally; How big can the changes be? IMHO SANE should rather
> > be incrementally and compatible changed for newer features, simillar
> > as POSIX standards or Linux develops. So that no fundamental
> > incompatibilities are created.
> 
> apparently you mis-read what i wrote, and/or mis-remember all the
> prior threads on this subject. we are specifically going to have
> backwards compatibility, with SANE 1.1.0 only adding some additional
> frame types, and perhaps clarifying some more well-known options. We
> are doing exactly what you wish, so I do not understand your
> objection.

I might not have read all, but remember that part. However your
text indeed sounded to me like a 1.0 is dead, something major
changes will follow.

Thanks for the clarifications, so that we are in sync .-)

> > For me it is not the feature set of SANE would require a major over-
> > haul. It would be rather nicer to changes the interna of SANE to avoid
> > code bloat, such as re-implementation of calibration, gamma table
> > use etc. pp. to not re-implement all this in every backend. However
> > that could be archived without breaking the API for frontends or
> > existing
> > backends.
> 
> i agree with this idea- but it has no real bearing on our release
> cycle, since sanei is not part of the public API. in fact, i have a
> sanei_gamma on my hard-drive right now :)

:-)

> > > Note #2:
> > > The epson backend has joined our growing list of unmaintained
> > > backends. As the SANE API matures in a future releases of SANE, these
> > > backends could be dropped due to lack of support. If you have access
> > > to scanners, documentation, or programming cycles, and are looking for
> > > an interesting project, picking up one of the unmaintained backends
> > > can be an easy way to get started with SANE.
> >
> > And this is exactly why Linux rocks, keeping supporting the even most
> > ancient ISA, Parport, etc. devices, SPARCs, etc. and why it should be
> > important to not break anything in the SANE world and instead gradually
> > evolve it.
> 
> your understanding of linux kernel and mine do not jive, as i
> routinely see old unmaintained hardware drivers dropped. i have
> several ancient scsi and ethernet cards which have not worked since
> 2.0/2.2. If you want those old drivers to be forward ported to API
> changes, then either we have to do it, or we have to get more
> developers. I am hoping for the latter :)

Ok, but that is rather seldom, with really many drivers even for
old stuff around. However, I also found it unnice that the specific
support for the Rise CPUs was just removed due to "not so many
devices in the wild".

However, with rather incremental changes chances should be
high we keep even not so much maintained drivers alife.

> but your desire to keep older hardware working does not seem to jive
> with the current state of the Avison bug reports...

That is not really true. I have both devices on my desk and they just work
for me. In fact I improved support for them in the last release cycle
(software line packing was off for both a little).

I have quite an aresenal of Avision based devices, and I even test my
first AV630 SCSI scanner I brought nearly 10 years ago on some
aging SCSI card like once a year :-)

> > I even would go as far and suggest rather release a incremental
> > SANE version every few month, so that new device support, features
> > go to the users in-time and developer actually get feedback quickly
> > when and if some device support broke.
> 
> yes- i agree. i will gladly hand over the release coordination to you :)

I know it is a hell of work, as I even run a whole Linux (and other stuff)
build system for years - that is kind of even more work:

  http://www.t2-project.org/

I really appreciate the work you put into SANE releases these days.

Yours,

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name