[Printing-architecture] OpenPrinting code repositories in GIT format

[Printing-architecture] OpenPrinting code repositories in GIT format

[Till Kamppeter]

Hi,

with the Google Summer of Code 2017 we got three new free software 
projects added to OpenPrinting. Nilanjana Lodh (CCed) wrote two of these 
projects to improve the print dialogs of GUI applications.

The projects do not provide any GUI, but they make it possible to 
separate the the dialog's interaction with local printing systems (like 
CUPS) or network print services (like Google Cloud Print) from the 
dialog itself using a frontend/backend architecture with the dislog 
being the frontend and for each print technology (currently CUPS, Google 
Cloud Print, ...) a backend. All print dialogs (currently GTK, Qt, 
LibreOffice) will use the same backends and so adding a print technology 
in the future will be much easier, in the ideal case the print service 
provider supplies the appropriate backend for his service.

One of the projects is a pair of frontend and backend libraries to make 
it easy to write backends and supporting print dialogs. The libraries 
hide away the D-Bus interface between frontend and backend and the 
mechanisms to find and invoke all the backends.

The other project is the CUPS backend without which the whole effort 
would be worthless.

See Nilanjana's work here:

https://nilanjanalodh.github.io/common-print-dialog-gsoc17/

Abhijeet Dubey (also CCed) has implemented the Google Cloud Print 
backend, making Google Cloud Print available to all supporting print 
dialogs.

His work you can find here:

https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-%7C-Common-Printing-Dialog

These three projects need to be hosted as pat of OpenPrinting and, as 
GIT turned to be the standard VCS in GIT format. And once thinking about 
project hosting I am also thinking about converting cups-filters from 
BZR to GIT and also move ippusbxd into OpenPrinting. ippusbxd is 
currently hosted in my personal GitHub:

https://github.com/tillkamppeter/ippusbxd

Now my question is how to do all this hosting to also have it somehow 
unified and not each project hosted in a different way.

There are two approaches:

Hosting on the OpenPrinting/Linux Foundation web site
-----------------------------------------------------

Pros:

- OpenPrinting is part of the Linux Foundation, and the LF has the 
hosting facilities, without any commercial interests.
- All code on the web sites of the Linux Foundation (or at least what is 
used by OpenPrinting) is free software
- The Bugzilla bug tracker is an established system with a lot of 
functionality, especially allows binary attachments (very important for 
printing)

Cons:

- A new project GIT repo needs to get created by the sys admins of the LF.
- There is a large community of GitHub users, for whom contributing to 
projects on GitHub is easy (report bugs, post pull requests, ...), but 
projects outside GitHub are not that easy (need to create LF account, ...).


Hosting on GitHub
-----------------

Pros:

- Using the de-facto standard of hosting with a large user community
- As a user one can easily create a new repository for a new project
- Pull requests allow easy contributing

Cons:

- Site software is proprietary
- Run by a commercial company which could easily cease the service
- The issue tracker only allows plain-text attachments. How to attach 
print sample files or similar.

Now I would like to hear some opinions of you all on how we should host 
the OpenPrinting projects.

    Till

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Michael Sweet]

Till,

Personally I think Github is the way to go.  Yes, it is run by a company but that company has many major clients (including Apple) so I think they are going to be around for a good long time.  Also, every Git clone of the repository creates a backup (should something catastrophic happen).  Finally, the issue tracker *does* allow you to attach binary files - I think the only restriction is HTML files (but I'm sure they'll be happy to clarify that...)

A third alternative is to put something like Gitlab on the openprinting.org VM you have - then you get the benefits of a Github-like environment that is hosted on your own server.  But I'd only do that if you are willing to do the admin tasks...


> On Aug 30, 2017, at 6:10 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Hi,
> 
> with the Google Summer of Code 2017 we got three new free software projects added to OpenPrinting. Nilanjana Lodh (CCed) wrote two of these projects to improve the print dialogs of GUI applications.
> 
> The projects do not provide any GUI, but they make it possible to separate the the dialog's interaction with local printing systems (like CUPS) or network print services (like Google Cloud Print) from the dialog itself using a frontend/backend architecture with the dislog being the frontend and for each print technology (currently CUPS, Google Cloud Print, ...) a backend. All print dialogs (currently GTK, Qt, LibreOffice) will use the same backends and so adding a print technology in the future will be much easier, in the ideal case the print service provider supplies the appropriate backend for his service.
> 
> One of the projects is a pair of frontend and backend libraries to make it easy to write backends and supporting print dialogs. The libraries hide away the D-Bus interface between frontend and backend and the mechanisms to find and invoke all the backends.
> 
> The other project is the CUPS backend without which the whole effort would be worthless.
> 
> See Nilanjana's work here:
> 
> https://nilanjanalodh.github.io/common-print-dialog-gsoc17/
> 
> Abhijeet Dubey (also CCed) has implemented the Google Cloud Print backend, making Google Cloud Print available to all supporting print dialogs.
> 
> His work you can find here:
> 
> https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-%7C-Common-Printing-Dialog
> 
> These three projects need to be hosted as pat of OpenPrinting and, as GIT turned to be the standard VCS in GIT format. And once thinking about project hosting I am also thinking about converting cups-filters from BZR to GIT and also move ippusbxd into OpenPrinting. ippusbxd is currently hosted in my personal GitHub:
> 
> https://github.com/tillkamppeter/ippusbxd
> 
> Now my question is how to do all this hosting to also have it somehow unified and not each project hosted in a different way.
> 
> There are two approaches:
> 
> Hosting on the OpenPrinting/Linux Foundation web site
> -----------------------------------------------------
> 
> Pros:
> 
> - OpenPrinting is part of the Linux Foundation, and the LF has the hosting facilities, without any commercial interests.
> - All code on the web sites of the Linux Foundation (or at least what is used by OpenPrinting) is free software
> - The Bugzilla bug tracker is an established system with a lot of functionality, especially allows binary attachments (very important for printing)
> 
> Cons:
> 
> - A new project GIT repo needs to get created by the sys admins of the LF.
> - There is a large community of GitHub users, for whom contributing to projects on GitHub is easy (report bugs, post pull requests, ...), but projects outside GitHub are not that easy (need to create LF account, ...).
> 
> 
> Hosting on GitHub
> -----------------
> 
> Pros:
> 
> - Using the de-facto standard of hosting with a large user community
> - As a user one can easily create a new repository for a new project
> - Pull requests allow easy contributing
> 
> Cons:
> 
> - Site software is proprietary
> - Run by a commercial company which could easily cease the service
> - The issue tracker only allows plain-text attachments. How to attach print sample files or similar.
> 
> Now I would like to hear some opinions of you all on how we should host the OpenPrinting projects.
> 
>   Till

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Aveek Basu]

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

Till \ Mike,

I think if Git Lab gives us the facilities of Github like environment even
after hosting in some one's own server, probably that will be the best
option. It will be good to have Till do the admin task. In case he is not
available or is busy, I can assist him out if required.


Regards,
Aveek


On Thu, Aug 31, 2017 at 5:47 AM, Michael Sweet <msweet@apple.com> wrote:

> Till,
>
> Personally I think Github is the way to go.  Yes, it is run by a company
> but that company has many major clients (including Apple) so I think they
> are going to be around for a good long time.  Also, every Git clone of the
> repository creates a backup (should something catastrophic happen).
> Finally, the issue tracker *does* allow you to attach binary files - I
> think the only restriction is HTML files (but I'm sure they'll be happy to
> clarify that...)
>
> A third alternative is to put something like Gitlab on the
> openprinting.org VM you have - then you get the benefits of a Github-like
> environment that is hosted on your own server.  But I'd only do that if you
> are willing to do the admin tasks...
>
>
> > On Aug 30, 2017, at 6:10 PM, Till Kamppeter <till.kamppeter@gmail.com>
> wrote:
> >
> > Hi,
> >
> > with the Google Summer of Code 2017 we got three new free software
> projects added to OpenPrinting. Nilanjana Lodh (CCed) wrote two of these
> projects to improve the print dialogs of GUI applications.
> >
> > The projects do not provide any GUI, but they make it possible to
> separate the the dialog's interaction with local printing systems (like
> CUPS) or network print services (like Google Cloud Print) from the dialog
> itself using a frontend/backend architecture with the dislog being the
> frontend and for each print technology (currently CUPS, Google Cloud Print,
> ...) a backend. All print dialogs (currently GTK, Qt, LibreOffice) will use
> the same backends and so adding a print technology in the future will be
> much easier, in the ideal case the print service provider supplies the
> appropriate backend for his service.
> >
> > One of the projects is a pair of frontend and backend libraries to make
> it easy to write backends and supporting print dialogs. The libraries hide
> away the D-Bus interface between frontend and backend and the mechanisms to
> find and invoke all the backends.
> >
> > The other project is the CUPS backend without which the whole effort
> would be worthless.
> >
> > See Nilanjana's work here:
> >
> > https://nilanjanalodh.github.io/common-print-dialog-gsoc17/
> >
> > Abhijeet Dubey (also CCed) has implemented the Google Cloud Print
> backend, making Google Cloud Print available to all supporting print
> dialogs.
> >
> > His work you can find here:
> >
> > https://github.com/dracarys09/gcp-backend/wiki/1.-Google-
> Summer-of-Code-2017-%7C-Common-Printing-Dialog
> >
> > These three projects need to be hosted as pat of OpenPrinting and, as
> GIT turned to be the standard VCS in GIT format. And once thinking about
> project hosting I am also thinking about converting cups-filters from BZR
> to GIT and also move ippusbxd into OpenPrinting. ippusbxd is currently
> hosted in my personal GitHub:
> >
> > https://github.com/tillkamppeter/ippusbxd
> >
> > Now my question is how to do all this hosting to also have it somehow
> unified and not each project hosted in a different way.
> >
> > There are two approaches:
> >
> > Hosting on the OpenPrinting/Linux Foundation web site
> > -----------------------------------------------------
> >
> > Pros:
> >
> > - OpenPrinting is part of the Linux Foundation, and the LF has the
> hosting facilities, without any commercial interests.
> > - All code on the web sites of the Linux Foundation (or at least what is
> used by OpenPrinting) is free software
> > - The Bugzilla bug tracker is an established system with a lot of
> functionality, especially allows binary attachments (very important for
> printing)
> >
> > Cons:
> >
> > - A new project GIT repo needs to get created by the sys admins of the
> LF.
> > - There is a large community of GitHub users, for whom contributing to
> projects on GitHub is easy (report bugs, post pull requests, ...), but
> projects outside GitHub are not that easy (need to create LF account, ...).
> >
> >
> > Hosting on GitHub
> > -----------------
> >
> > Pros:
> >
> > - Using the de-facto standard of hosting with a large user community
> > - As a user one can easily create a new repository for a new project
> > - Pull requests allow easy contributing
> >
> > Cons:
> >
> > - Site software is proprietary
> > - Run by a commercial company which could easily cease the service
> > - The issue tracker only allows plain-text attachments. How to attach
> print sample files or similar.
> >
> > Now I would like to hear some opinions of you all on how we should host
> the OpenPrinting projects.
> >
> >   Till
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>


-- 
Regards,
Aveek

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

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[James Cloos]

I prefr bugzilla, gitolite and cgit.

Gitolite works perfectly well for managing rw access, cgit is fine for
web access to the git tree, and bugzilla is vastly better than github.

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

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Sahil Arora]

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

Hi there,
Github vs Gitlab vs Bugzilla vs others is a very important problem
considering the fact that changing version control systems is very
difficult, as we are facing now. Even as I was doing my GSoC project with
OpenPrinting this year, I felt it easier to use Git rather than any other
version control system(VCS).

Here are some points which I think are noteworthy:
1. Most of the modern IDEs and Code Editors support git out of the box. Not
only that, people are now shifting to git aware shells like zsh and fish.
In this case, using git will make the life of a developer far more easier
than any other VCS or bug tracking system.
2. Both Github and Gitlab support continuous integration, which I think is
missing in other tools. It will make the life of a maintainer extremely
easy once these continuous integration / continuous delivery pipelines are
integrated with the code base for the projects we would be working in the
future.

I believe platforms which run on git will be more future proof and
developer friendly than any other platform for code / bug tracking. My
personal preference would be gitlab since provides more features out of the
box even on the free version than github, but it would not matter if it's
github or gitlab unless and until it is git.

Thanks.
--
Sahil Arora

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

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Till Kamppeter]

Hi,

another suggestion is Launchpad (launchpad.net), the service created by 
Canonical, mainly for Ubuntu, but any other independent project can use 
it (like for example HPLIP from HP).

Launchpad supports so-called project groups to join projects (would be 
OpenPrinting" in our case). The projects would be the upstream sources: 
cups-filters, foomatic-db, foomatic-db-engine, ippusbxd, ... and 
Nilanjana's new projects. As a Launchpad user (and the owner of the 
OpenPrinting project group) I can create projects and add them to the 
project group.

GIT as VCS is supported. There is also a way that users can suggest 
branches to get merged into the upstream repo, like GitHub's pull requests.

The bug tracker is much more sophisticated, and it supports attaching 
all kinds of files.

There are also many other development helpers: Blueprints, translations, 
questions, ...

For code series, milestones, and releases can be defined.

Bugs can get linked with all of this.

WDYT about hosting on Launcpad?

    Till



On 08/30/2017 06:10 PM, Till Kamppeter wrote:
> Hi,
> 
> with the Google Summer of Code 2017 we got three new free software 
> projects added to OpenPrinting. Nilanjana Lodh (CCed) wrote two of these 
> projects to improve the print dialogs of GUI applications.
> 
> The projects do not provide any GUI, but they make it possible to 
> separate the the dialog's interaction with local printing systems (like 
> CUPS) or network print services (like Google Cloud Print) from the 
> dialog itself using a frontend/backend architecture with the dislog 
> being the frontend and for each print technology (currently CUPS, Google 
> Cloud Print, ...) a backend. All print dialogs (currently GTK, Qt, 
> LibreOffice) will use the same backends and so adding a print technology 
> in the future will be much easier, in the ideal case the print service 
> provider supplies the appropriate backend for his service.
> 
> One of the projects is a pair of frontend and backend libraries to make 
> it easy to write backends and supporting print dialogs. The libraries 
> hide away the D-Bus interface between frontend and backend and the 
> mechanisms to find and invoke all the backends.
> 
> The other project is the CUPS backend without which the whole effort 
> would be worthless.
> 
> See Nilanjana's work here:
> 
> https://nilanjanalodh.github.io/common-print-dialog-gsoc17/
> 
> Abhijeet Dubey (also CCed) has implemented the Google Cloud Print 
> backend, making Google Cloud Print available to all supporting print 
> dialogs.
> 
> His work you can find here:
> 
> https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-%7C-Common-Printing-Dialog 
> 
> 
> These three projects need to be hosted as pat of OpenPrinting and, as 
> GIT turned to be the standard VCS in GIT format. And once thinking about 
> project hosting I am also thinking about converting cups-filters from 
> BZR to GIT and also move ippusbxd into OpenPrinting. ippusbxd is 
> currently hosted in my personal GitHub:
> 
> https://github.com/tillkamppeter/ippusbxd
> 
> Now my question is how to do all this hosting to also have it somehow 
> unified and not each project hosted in a different way.
> 
> There are two approaches:
> 
> Hosting on the OpenPrinting/Linux Foundation web site
> -----------------------------------------------------
> 
> Pros:
> 
> - OpenPrinting is part of the Linux Foundation, and the LF has the 
> hosting facilities, without any commercial interests.
> - All code on the web sites of the Linux Foundation (or at least what is 
> used by OpenPrinting) is free software
> - The Bugzilla bug tracker is an established system with a lot of 
> functionality, especially allows binary attachments (very important for 
> printing)
> 
> Cons:
> 
> - A new project GIT repo needs to get created by the sys admins of the LF.
> - There is a large community of GitHub users, for whom contributing to 
> projects on GitHub is easy (report bugs, post pull requests, ...), but 
> projects outside GitHub are not that easy (need to create LF account, ...).
> 
> 
> Hosting on GitHub
> -----------------
> 
> Pros:
> 
> - Using the de-facto standard of hosting with a large user community
> - As a user one can easily create a new repository for a new project
> - Pull requests allow easy contributing
> 
> Cons:
> 
> - Site software is proprietary
> - Run by a commercial company which could easily cease the service
> - The issue tracker only allows plain-text attachments. How to attach 
> print sample files or similar.
> 
> Now I would like to hear some opinions of you all on how we should host 
> the OpenPrinting projects.
> 
>     Till

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Michael Sweet]

Till,

No objections.


> On Sep 26, 2017, at 4:00 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Hi,
> 
> another suggestion is Launchpad (launchpad.net), the service created by Canonical, mainly for Ubuntu, but any other independent project can use it (like for example HPLIP from HP).
> 
> Launchpad supports so-called project groups to join projects (would be OpenPrinting" in our case). The projects would be the upstream sources: cups-filters, foomatic-db, foomatic-db-engine, ippusbxd, ... and Nilanjana's new projects. As a Launchpad user (and the owner of the OpenPrinting project group) I can create projects and add them to the project group.
> 
> GIT as VCS is supported. There is also a way that users can suggest branches to get merged into the upstream repo, like GitHub's pull requests.
> 
> The bug tracker is much more sophisticated, and it supports attaching all kinds of files.
> 
> There are also many other development helpers: Blueprints, translations, questions, ...
> 
> For code series, milestones, and releases can be defined.
> 
> Bugs can get linked with all of this.
> 
> WDYT about hosting on Launcpad?
> 
>   Till
> 
> 
> 
> On 08/30/2017 06:10 PM, Till Kamppeter wrote:
>> Hi,
>> with the Google Summer of Code 2017 we got three new free software projects added to OpenPrinting. Nilanjana Lodh (CCed) wrote two of these projects to improve the print dialogs of GUI applications.
>> The projects do not provide any GUI, but they make it possible to separate the the dialog's interaction with local printing systems (like CUPS) or network print services (like Google Cloud Print) from the dialog itself using a frontend/backend architecture with the dislog being the frontend and for each print technology (currently CUPS, Google Cloud Print, ...) a backend. All print dialogs (currently GTK, Qt, LibreOffice) will use the same backends and so adding a print technology in the future will be much easier, in the ideal case the print service provider supplies the appropriate backend for his service.
>> One of the projects is a pair of frontend and backend libraries to make it easy to write backends and supporting print dialogs. The libraries hide away the D-Bus interface between frontend and backend and the mechanisms to find and invoke all the backends.
>> The other project is the CUPS backend without which the whole effort would be worthless.
>> See Nilanjana's work here:
>> https://nilanjanalodh.github.io/common-print-dialog-gsoc17/
>> Abhijeet Dubey (also CCed) has implemented the Google Cloud Print backend, making Google Cloud Print available to all supporting print dialogs.
>> His work you can find here:
>> https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-%7C-Common-Printing-Dialog These three projects need to be hosted as pat of OpenPrinting and, as GIT turned to be the standard VCS in GIT format. And once thinking about project hosting I am also thinking about converting cups-filters from BZR to GIT and also move ippusbxd into OpenPrinting. ippusbxd is currently hosted in my personal GitHub:
>> https://github.com/tillkamppeter/ippusbxd
>> Now my question is how to do all this hosting to also have it somehow unified and not each project hosted in a different way.
>> There are two approaches:
>> Hosting on the OpenPrinting/Linux Foundation web site
>> -----------------------------------------------------
>> Pros:
>> - OpenPrinting is part of the Linux Foundation, and the LF has the hosting facilities, without any commercial interests.
>> - All code on the web sites of the Linux Foundation (or at least what is used by OpenPrinting) is free software
>> - The Bugzilla bug tracker is an established system with a lot of functionality, especially allows binary attachments (very important for printing)
>> Cons:
>> - A new project GIT repo needs to get created by the sys admins of the LF.
>> - There is a large community of GitHub users, for whom contributing to projects on GitHub is easy (report bugs, post pull requests, ...), but projects outside GitHub are not that easy (need to create LF account, ...).
>> Hosting on GitHub
>> -----------------
>> Pros:
>> - Using the de-facto standard of hosting with a large user community
>> - As a user one can easily create a new repository for a new project
>> - Pull requests allow easy contributing
>> Cons:
>> - Site software is proprietary
>> - Run by a commercial company which could easily cease the service
>> - The issue tracker only allows plain-text attachments. How to attach print sample files or similar.
>> Now I would like to hear some opinions of you all on how we should host the OpenPrinting projects.
>>    Till
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

Re: [Printing-architecture] OpenPrinting code repositories in GIT format

[Till Kamppeter]

Finally decided on setting up the repos on GitHub as Linux Foundation 
admins want to get rid of the BZR repos and suggested to move to GitHub. 
The site for the repos is

https://github.com/OpenPrinting

now.

The print-dialog-related projects, ippusbxd, and Snappy packaging of the 
printing stack are there now, cups-filters, Foomatic, ... will follow soon.

Thank you very much for all your answers.

    Till


On 09/26/2017 05:04 PM, Michael Sweet wrote:
> Till,
> 
> No objections.
> 
> 
>> On Sep 26, 2017, at 4:00 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> Hi,
>>
>> another suggestion is Launchpad (launchpad.net), the service created by Canonical, mainly for Ubuntu, but any other independent project can use it (like for example HPLIP from HP).
>>
>> Launchpad supports so-called project groups to join projects (would be OpenPrinting" in our case). The projects would be the upstream sources: cups-filters, foomatic-db, foomatic-db-engine, ippusbxd, ... and Nilanjana's new projects. As a Launchpad user (and the owner of the OpenPrinting project group) I can create projects and add them to the project group.
>>
>> GIT as VCS is supported. There is also a way that users can suggest branches to get merged into the upstream repo, like GitHub's pull requests.
>>
>> The bug tracker is much more sophisticated, and it supports attaching all kinds of files.
>>
>> There are also many other development helpers: Blueprints, translations, questions, ...
>>
>> For code series, milestones, and releases can be defined.
>>
>> Bugs can get linked with all of this.
>>
>> WDYT about hosting on Launcpad?