[Printing-architecture] Upstream future of ippusbxd

[Printing-architecture] Upstream future of ippusbxd

[Till Kamppeter]

Hi,

ippusbxd is a daemon to support IPP-over-USB printing, a standard for a 
packet-based USB protocol for printers, which especially adds full IPP 
and HTTP functionality to a USB-connected, non-networked printer: Web 
interface of the printer for configuration (especially also the 
printer's WiFi if it does not have a front panel) and for using the 
built-in scanner, IPP querying of printer properties, and even 
driverless printing via IPP Everywhere.

The daemon was developed by Daniel Dresssler as a GSoC project. Now 
Daniel has no time any more to maintain it and upstream maintainership 
is going over to me (and so to OpenPrinting).

I am thinking about joining it into the cups-filters upstream package to 
not have too many tiny packages to make up the complete printing stack 
and cups-filters contains all manufacturer-independent software for 
communication with printers which is not part of CUPS itself. It will 
usually be used with CUPS anyway as there are no other maintained 
printing environments. You will simply have as manufacturer-independent 
part of the printing stack CUPS, cups-filters, and at least one PDF 
renderer (currently Ghostscript or Poppler, in the future perhaps also 
MuPDF) plus the manufacturer-dependent drivers (foomatic-db, HPLIP, 
Gutenprint, ...).

WDYT?

    Till

Re: [Printing-architecture] Upstream future of ippusbxd

[Johannes Meixner]

Hello,

On Jul 6 22:15 Till Kamppeter wrote (excerpt):
> ippusbxd is a daemon to support IPP-over-USB printing
...
> I am thinking about joining it into the cups-filters
> upstream package to not have too many tiny packages
> to make up the complete printing stack

What would be a real drawback of "many tiny packages"?

Personally I would prefer "many tiny packages"
because I favour the traditional KISS principle
(to be read here as "keep it small and simple").

A consequence of the KISS principle is to keep separated
things separated.

"Keep separated things separated" is what I actually
would like to have. For me it does not matter how big
(or small) one single separated thing is.

The basic reason why I think that separated things
should be kept separated is that this makes it much
easier to maintain all of them.

I think it is easier to find volunteers who like to work
on a single piece of their current personal interest
when that piece of interest is provided as a separated
piece of software that is (relavtively) easy to understand.
In particular compile-time requirements are smaller for
separated things which makes it easier to work on them
(the edit->compile->install->test cycle is simpler).

In contrast a big (possibly convoluted) all-in-one monster
needs an universal genius who likes to tame such a beast.

When separated things are kept separated it requires that
interdependencies between those things are maintained.
This is more work but it ensures that interdependencies
are kept obvious. When separated things are kept separated
one cannot accidentally make convoluted code full of hidden
interdependencies that nobody understands after some time
(i.e. where a fix here lets it break there).

I assume ippusbxd is separated from the current cups-filters
software so that - from my point of view - ippusbxd should
be provided in its own "tiny package".

For example - as far as I know - also cups-browsed is
separated from the rest of the cups-filters software
so that cups-browsed should be split from cups-filters
into its own "tiny package".

Also the backends in cups-filters are probably separated
from the rest so that they could be split into their own
"cups-backends" package. Strictly speaking each backend is
separated from the other backends but having a separated
package for each of them would be stretching it too far
(cf. GNU coreutils).

Assume different separated things all need some common
funcionality (e.g. think about some common funcionality
how to interact with CUPS). Then it would be cleaner when
the common funcionality is not implemented independently
in each of the separated things but split out into a
separated "common funcionality" thing (e.g. a run-time
library or as common source like Gnulib).

Furthermore I assume that what starts as "tiny package"
will grow over the time because usually more and more
functionality will be added so that "tiny packages"
usually become "normal packages".
Imagine the final result when each of them would grow
inside a single "all-in-one package".


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)

Re: [Printing-architecture] Upstream future of ippusbxd

[James Cloos]

>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:


TK> I am thinking about joining [ippusbxd] into the cups-filters
TK> upstream package to not have too many tiny packages to make up the
TK> complete printing stack and cups-filters contains all
TK> manufacturer-independent software for communication with printers
TK> which is not part of CUPS itself.

Be sure, if you do, to note the licensing issues for all of those who
packages cups-filters for distributions.

And also make sure that nothing which derrives from Mike's code ever
inter-links with anythig which derrives from Daniel's, since the
licenses are incompatible.  (GPL2 vs Apache2).

(As mentor, I advised Daniel that the licence should be compatible with
cups.  He refused.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Printing-architecture] Upstream future of ippusbxd

[Johannes Meixner]

Hello,

On Jul 7 08:10 James Cloos wrote (excerpt):
>>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
>
> TK> I am thinking about joining [ippusbxd] into the cups-filters
> TK> upstream package to not have too many tiny packages to make up the
> TK> complete printing stack and cups-filters contains all
> TK> manufacturer-independent software for communication with printers
> TK> which is not part of CUPS itself.
>
> Be sure, if you do, to note the licensing issues for all of those who
> packages cups-filters for distributions.
>
> And also make sure that nothing which derrives from Mike's code ever
> inter-links with anythig which derrives from Daniel's, since the
> licenses are incompatible.  (GPL2 vs Apache2).

As far as I know (but I am not a lawyer) the crucial terms here are
"mere aggregation" versus "combining two modules into one program"
in the GPL2, see
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

As far as I know (but I am not a lawyer) it does not make a difference
when GPL2 sources and sources with an incompatible license are in one
same tarball versus when they are in different tarballs.

As far as I know (but I am not a lawyer) one can have GPL2 sources
and sources with an incompatible license in one same tarball without
causing a GPL2 license issue when both parts are separate programs.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)

Re: [Printing-architecture] Upstream future of ippusbxd

[James Cloos]

>>>>> "JM" == Johannes Meixner <jsmeix@suse.de> writes:

>>>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:

TK> I am thinking about joining [ippusbxd] into the cups-filters
TK> upstream package to not have too many tiny packages to make up the
TK> complete printing stack and cups-filters contains all
TK> manufacturer-independent software for communication with printers
TK> which is not part of CUPS itself.

JC>> Be sure, if you do, to note the licensing issues for all of those who
JC>> packages cups-filters for distributions.

JC>> And also make sure that nothing which derrives from Mike's code ever
JC>> inter-links with anythig which derrives from Daniel's, since the

JC>> licenses are incompatible.  (GPL2 vs Apache2).

JM> As far as I know (but I am not a lawyer) the crucial terms here are
JM> "mere aggregation" versus "combining two modules into one program"
JM> in the GPL2, see
JM> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

JM> As far as I know (but I am not a lawyer) it does not make a difference
JM> when GPL2 sources and sources with an incompatible license are in one
JM> same tarball versus when they are in different tarballs.

JM> As far as I know (but I am not a lawyer) one can have GPL2 sources
JM> and sources with an incompatible license in one same tarball without
JM> causing a GPL2 license issue when both parts are separate programs.

The package managers all show each packages' licences.  So the
maintainers need to know about any changes so they can update those
lines when packaging a new version.

And a clearly pointed out *link*ing as the thing which needs avoidance.
If, after some time, anyone looks ast the code and thinks that something
can be merged or thst one set of code could be improved by incorporating
something from the other set, they need to know the legal limitations.

I never said “don't do it”; just “take care”.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Printing-architecture] Upstream future of ippusbxd

[Johannes Meixner]

Hello,

On Jul 7 12:02 James Cloos wrote (excerpt):
>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
> TK> I am thinking about joining [ippusbxd] into the cups-filters
> TK> upstream package to not have too many tiny packages
...
> JC>> licenses are incompatible.  (GPL2 vs Apache2).
...
> If, after some time, anyone looks ast the code and thinks
> that something can be merged or thst one set of code could
> be improved by incorporating something from the other set,
> they need to know the legal limitations.

This is a good example how it could happen that accidentally
convoluted code is made with unexpected interdependencies
(in this case there are legal interdependencies) and why
it is probably better to keep separated things separated.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)

Re: [Printing-architecture] Upstream future of ippusbxd

[Ira McDonald]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

Hi,

When Till and I talked about this on yesterday's OP monthly call,
we concluded that keeping ippusbxd in a separate package was
the best choice.  Till said that he would move the code to a Git
repository (I hope this pleases you Tim) and link it off the Open
Printing website.

If anyone objects to keeping ippusbxd in a separate package,
please speak up now.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Wed, Jul 8, 2015 at 5:12 AM, Johannes Meixner <jsmeix@suse.de> wrote:

>
> Hello,
>
> On Jul 7 12:02 James Cloos wrote (excerpt):
>
>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
>>>>>
>>>> TK> I am thinking about joining [ippusbxd] into the cups-filters
>> TK> upstream package to not have too many tiny packages
>>
> ...
>
>> JC>> licenses are incompatible.  (GPL2 vs Apache2).
>>
> ...
>
>> If, after some time, anyone looks ast the code and thinks
>> that something can be merged or thst one set of code could
>> be improved by incorporating something from the other set,
>> they need to know the legal limitations.
>>
>
> This is a good example how it could happen that accidentally
> convoluted code is made with unexpected interdependencies
> (in this case there are legal interdependencies) and why
> it is probably better to keep separated things separated.
>
>
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
> Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>

[-- Attachment #2: Type: text/html, Size: 4211 bytes --]

Re: [Printing-architecture] Upstream future of ippusbxd

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

On Wed, 2015-07-08 at 08:40 -0400, Ira McDonald wrote:
> Till said that he would move the code to a Git
> repository (I hope this pleases you Tim) and link it off the Open
> Printing website.

That's great news, yes. :-)

Tim.
*/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Printing-architecture] Upstream future of ippusbxd

[Till Kamppeter]

Yes, I will maintain ippusbxd as a separate upstream package, and I will 
maintain it in a GIT repository. The only question is how to do it. 
There are two possibilities:

1. Create the GIT repo on the OpenPrinting web server, probably the 
Linux Foundation has already other problems under GIT. And they also 
have Bugzilla for bug tracking. In addition, move the other OpenPrinting 
projects to GIT.

2. Create an organization named OpenPrinting on GitHub and move ippusbxd 
to there. Move also the other projects to there converting them to GIT. 
And then keep Bugzilla on OpenPrinting or use the GitHub issue tracker 
instead?

WDYT? Which is the better method? And why?

    Till


On 07/08/2015 09:40 AM, Ira McDonald wrote:
> Hi,
>
> When Till and I talked about this on yesterday's OP monthly call,
> we concluded that keeping ippusbxd in a separate package was
> the best choice.  Till said that he would move the code to a Git
> repository (I hope this pleases you Tim) and link it off the Open
> Printing website.
>
> If anyone objects to keeping ippusbxd in a separate package,
> please speak up now.
>
> Cheers,
> - Ira

Re: [Printing-architecture] Upstream future of ippusbxd

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On Wed, 2015-07-08 at 15:59 -0300, Till Kamppeter wrote:
> 2. Create an organization named OpenPrinting on GitHub and move
> ippusbxd to there. Move also the other projects to there converting 
> them to GIT.

One very big advantage of using GitHub is that you get to use tools
like Travis CI/Jenkins for continuous integration easily, so that every
time a change is made or proposed you can see whether it will break the
build. If there was a test suite, it could also run that. You can also
link projects to coverity-scan for free usage. Here's an example using
both those things:
https://travis-ci.org/twaugh/patchutils/builds/70706661

(I think coverity defects are only visible to the project owner.)

GitHub also has a useful mini-patch-review system. When anyone submits
a pull request from their own repository or from a branch in the main
project, you can comment on individual lines that are changed.

> And then keep Bugzilla on OpenPrinting or use the GitHub issue 
> tracker instead?

If you wanted to stick with Bugzilla there's a GitHub webhook to
integrate with it. (I've never used it myself.)
https://github.com/github/github-services/blob/master/docs/bugzilla

I think all those things happen automatically with GitHub's issue
tracker.

Tim.
*/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Printing-architecture] Upstream future of ippusbxd

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Mon, 2015-07-06 at 22:15 -0300, Till Kamppeter wrote:
> I am thinking about joining it into the cups-filters upstream package
> to not have too many tiny packages to make up the complete printing
> stack and cups-filters contains all manufacturer-independent software 
> for communication with printers which is not part of CUPS itself.

I don't really have a strong opinion either way. Having it in its own
package would be fine for me, but if you want to put it in cups-filters
I'd be OK with that too.

What I would definitely prefer is to have it hosted in git not bzr. :-)

Tim.
*/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]