Re: [Gimp-print-devel] OSX support (Was Re: CITIZEN photo printers)

[Solomon P. <pi...@sh...>]

On Fri, Feb 16, 2018 at 10:34:42PM -0800, Alex G. wrote:
> I think it's of great value to have a vendor's support, and of even greater
> value for the vendor to use Gutenprint as its official solution.

Aye, but it's not all upsides.  :)
 
> From the user's perspective, a consistent experience across OSes is a huge
> benefit. I can vouch my frustrations with Epson's drivers and inconsistent
> results between their windows and escpr (linux) drivers. I think the
> consistent user experience is a great case for avoiding OS-specific
> features, unless the customers really request them.

Yes, I've already made this point.
 
> As far as OSX support itself is concerned, it is a very popular OS, and
> investing the upfront cost to ensure proper support is worthwhile. Every
> CITIZEN user on OSX is automatically a Gutenprint user. Financially
> motivated improvements for OSX users trickle down to Linux users,
> essentially for free.

Gutenprint arguably already has "good enough" OSX support.  The question 
is if Citizen agrees, and if not, what changes would be necessary.  
Unfortunately, in this specific case [1], the areas I suspect would need 
improvement would all be OSX-specific polish and thus not really lead to 
any trickle down to Linux..

(Due to Gutenprint's excellent support for OEM versions of the Citizen 
 printers, I expect that all that's needed for hadware enablement would 
 be a couple of minor bugfixes..)
 
> On the matter of CITIZEN providing its own packages, did they mention
> whether they want a compile time option to only enable drivers for CITIZEN
> products? Or are they okay with the generic Gutenprint package? I am certain
> CITIZEN wants an efficient way to fix bugs and push updates. 

This is an open question, and it raises the question of the need to have 
mutiple gutenprint[-derived] "packages" installed.  I'd really prefer to 
avoid this.

I think, at minimum, we would need to generate more frequent (point) 
releases for bugfixes.  I already do this for other commercial players I 
support, only for specific Linux targets.

> If they have a good understanding of the code quality requirements for 
> upstream Gutenprint.The key here is to work upstream directly. For 
> that to happen, expectations should be set as clear as possible, and a 
> reasonable release process exist, even if that release means "vendor 
> solved a bunch of pressing issues for their hardware".

I don't think Citizen (or at least the folks engaging with us) has the 
technical capability to work directly with us as a direct contributor.

But behind the scenes, Robert has put in a great deal of effort to 
improve our ability to spin (and QA) new releases rapidly, and I'm 
working towards setting up a CI system to run everything through 
nightly.  OSX packages aren't part of that yet, unfortunately.

> On the issue of ancient distros, such as RedHat, the key is not depend on
> newer libraries than those shipped with such distros. Sometimes this can be
> problematic for upstream, but if maintainers can normally compile on such
> distros, then they should be able to ship newer releases. DISCLAIMER: I am a
> Fedora package maintainer.

If we go the package-generation route, it would be using the 
appropriate distro's tools to generate native packages, so no newer 
stuff will ever get pulled in.

(My main frustration with distros has been with Ubuntu.  They shipped a 
 buggy pre-release snapshot with one LTS release, and refused to update 
 it.  I still get bug reports about that.  Bah.)

> Then there is the organizational issue of how much control CITIZEN wants to
> have. I imagine that they want a lot of say in tuning the hardware-specific
> bits applicable to their products, and that they would expect some
> flexibility in the generic parts for adding relevant features.

Gutenprint already has excellent mechanisms for tuning parameters on a 
per-device basis, but we don't envision a situation where core/generic 
changes would be necessary.  In any case, there'd be little point in 
having those tweaks live solely on a Citizen-specific release branch.

> There's also the question of whether autotools is the right tool to aid in
> all of the above. It can handle everything, but can it handle it
> effortlessly and painlessly such that developers won't want to throw
> themselves off the roof of the CITIZEN HQ on to the pavement below?

I get the feeling they don't want to (if not outright incapable of) 
getting their hands dirty here, instead wanting us to deal with all of 
that.  So in that sense autotools is fine.

(I've wanted to junk autotools in favor of something less 
 migrane-inducing, most likely cmake, but gutenprint's build is actually 
 pretty complicated, even by autotools' standards...)

> I hope I've been able to clarify some of the organizational questions that I
> think would have to be clarified. I have very positive thoughts about this,
> and would love to see a fruitful relationship develop with hardware vendors.

As I mentioned earlier, I'm not concerned about the core bits and the 
actual "driver" itself.  We already know that's solid, even under OSX.

Instead, I worry about our ability to meaningfully provide OSX-specific 
expertise and polish that I believe necessary to satisfy Citizen's 
needs.  

Of Gutenprint's active contributors, only one of us even has 
access to an OSX-capable system.  Even if Citizen tosses a pile of money 
our way so we can purchase the appropriate hardware, it's still going to 
take time to ramp up, and we all have dayjobs and families that come 
first.  :)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.