Packing needs - status to add to bugzilla and the dashboard?
Hello All - I'd like to have a chance to talk about the packing work flow at the next developers meeting or even the general meeting. My thoughts are that we need a status in Bugzilla that says something like "Needs package created" or something. Also add a little spot on the dashboard under the Bugs Statuses which has a canned search for that queue. I imagine the workflow being something like... 1. RM pushes code to master 2. RM changes status to "needs package created" 3. PackingManager creates package 4. PM changes the status to "Pushed to Master" The work flow is important and I'd like to make it as transparent as possible and make sure that we don't miss something. Robin, Galen, or others do you have any thoughts on this? Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
On 9 March 2016 6:25:18 am NZDT, Brendan Gallagher <info@bywatersolutions.com> wrote:
Hello All -
I'd like to have a chance to talk about the packing work flow at the next developers meeting or even the general meeting.
My thoughts are that we need a status in Bugzilla that says something like "Needs package created" or something. Also add a little spot on the dashboard under the Bugs Statuses which has a canned search for that queue.
I imagine the workflow being something like...
1. RM pushes code to master 2. RM changes status to "needs package created" 3. PackingManager creates package
I don't think it's fair to push this all on the package manager. If a dev introduces new dependencies that need packaging, it should be their responsibility to make sure this is done. Chris
4. PM changes the status to "Pushed to Master"
The work flow is important and I'd like to make it as transparent as possible and make sure that we don't miss something. Robin, Galen, or others do you have any thoughts on this?
Thanks, Brendan
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi, On Tue, Mar 8, 2016 at 12:30 PM, Chris Cormack <chrisc@catalyst.net.nz> wrote:
I don't think it's fair to push this all on the package manager. If a dev
introduces new dependencies that need packaging, it should be their
responsibility to make sure this is done.
Indeed. I am willing to build *some* packages (and submit them to Debian), but that willingness is decidedly not infinite. The first question that somebody who proposes to add a new dependency should ask themselves is this: is there a way to accomplish the task at hand without adding a new dependency? If not, can the task at hand be accomplished using packages that are already in Debian stable? If not, does the dependency at least have an active third-party ITP (intent to package) in the Debian bug tracker? Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Yup all good points. Not to put it all on the PM - but I think a way to track this in BZ is needed. A better workflow - perhaps based on Chris's point - a "failed QA - needs package" status (or some worded status)? Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?) On Tue, Mar 8, 2016 at 9:37 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Tue, Mar 8, 2016 at 12:30 PM, Chris Cormack <chrisc@catalyst.net.nz> wrote:
I don't think it's fair to push this all on the package manager. If a dev
introduces new dependencies that need packaging, it should be their
responsibility to make sure this is done.
Indeed. I am willing to build *some* packages (and submit them to Debian), but that willingness is decidedly not infinite.
The first question that somebody who proposes to add a new dependency should ask themselves is this: is there a way to accomplish the task at hand without adding a new dependency? If not, can the task at hand be accomplished using packages that are already in Debian stable? If not, does the dependency at least have an active third-party ITP (intent to package) in the Debian bug tracker?
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Hi, On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher < info@bywatersolutions.com> wrote:
Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?)
We do now, seeded with my view of the position: https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager On a side note, the overall page is new; I'm figuring that it might be a useful exercise to outline minimum role responsibilities for all of the named project positions. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Cool - I added some quick notes to the RM spot - I'd be interested in seeing others fluff that out. On Tue, Mar 8, 2016 at 3:03 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher < info@bywatersolutions.com> wrote:
Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?)
We do now, seeded with my view of the position:
https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager
On a side note, the overall page is new; I'm figuring that it might be a useful exercise to outline minimum role responsibilities for all of the named project positions.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Also, are you saying any newly packaged libraries *must* make it in to Debian? Can we not host our own packaged libraries on our apt server? Why must packages meet the Debian requirements? This seems like it's adding yet another barrier to entry for new Koha developers. Now we all need to be Debian package maintainers as well? It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules. Just a thought. http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Tue, Mar 8, 2016 at 6:03 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher < info@bywatersolutions.com> wrote:
Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?)
We do now, seeded with my view of the position:
https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager
On a side note, the overall page is new; I'm figuring that it might be a useful exercise to outline minimum role responsibilities for all of the named project positions.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Also, are you saying any newly packaged libraries *must* make it in to Debian?
No, I am not saying this. I said this: "Furthermore, such packages must meet Debian's licensing requirements." We cannot Debian to accept a package, and we obviously have no particular influence over Debian's release schedule. Consequently, hosting a package either temporarily or permanently on debian.koha-community.org is a valid option for us in case of technical disagreement with Debian or because we want to require a package before it is available on Debian stable. In the long run, however, it is better that such hosting be temporary; as it saves us work to have a dependency be part of Debian. Why must packages meet the Debian requirements?
So that they have a chance of actually getting into Debian — and so that Koha does not fall into the trap of requiring non-free dependencies for the sake of developer convenience. I should point out that this is not a new guideline. From the wiki [1]: "The Koha project is not going to redistribute a module just because it's in CPAN" At minimum, a CPAN module that is being considered for packaging must meet the Debian Free Software Guidelines [2]; in my opinion, that is non-negotiable given Koha's status as a GPL3+ project. Of course, there are a variety of technical requirements that a package must meet before it would get accepted by Debian, but we have more flexibility there: we can choose to host a package that is DFSG-complaint but is not quite yet ready for prime-time... if we absolutely need to.
This seems like it's adding yet another barrier to entry for new Koha developers.
Are new developers actually the primary source of suggestions that we add new CPAN dependencies to Koha? Regardless, there are a variety of competing aims at play here, and I submit that the convenience of new developers -- or not so new developers -- does not trump other considerations that include: * keeping the number of dependencies (and thus, potential vectors for bugs and security exposures) manageable. Each new dependency adds a maintenance cost the project; not necessarily large in and of itself, but it adds up. * ensuring Koha's stability for Debian users * having some assurance that new dependencies are likely to work; if a CPAN module is already packaged for Debian, there's at least some signal that this is the case * for that matter, easing the situation for folks running RHEL who are restricted from installing CPAN modules willy-nilly; there are at least a few such Koha users out there Now we all need to be Debian package maintainers as well?
No. Somebody who wants to add a CPAN dependency that is not yet packaged for Debian has several avenues to take (assuming that they've triple-checked that a new dependency is actually necessary): * they can package it themselves (and bluntly, in the case of paid development that is conducted by a commercial entity, I do not view that as an unreasonable expectation that they one way or another arrange to deal with packaging new dependencies that they propose) * they can make a request of various other developers in the Koha community who have experience building packages -- it's not just me who can do it -- although I note that a request works better than a demand. * they can make a request of the Debian Perl Group [3], who are, by all accounts, a pretty helpful bunch * they can find a Debian Developer to contract with to build the package
It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules.
CPAN, as with anything else, is subject to Sturgeon's law; using existing Perl packages helps provide a useful quality filter. As far as Debian is concerned, there are almost 3,500 CPAN modules that are already packaged for Jessie. Does this cover everything? No, of course not; but I submit that a project that already has over 150 CPAN dependencies should be cautious about adding new ones. [1] https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency... [2] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines [3] https://pkg-perl.alioth.debian.org/ Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I think this thread is starting to veer off course, so let's bring it back home. I simply want edto question our motives and methods. Barriers to entry should be a constant concern us. I think it's important that we stay vigilant and question new requirements for developers. If we never do that, we'll end up with an ecosystem where we have no new developers and our talent pool may dry up. I've reviewed all the wiki pages we have concerning packaging dependencies, and while there is plenty of information, there is no direction. I think URL::Encode is a great example, as it is a simple library with no dependencies other than Carp. I ran dh-make-perl --pkg-perl --build --cpan URL::Encode and it ran without errors, and now I have a debian package for the library. What now? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Mar 9, 2016 at 10:47 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Also, are you saying any newly packaged libraries *must* make it in to Debian?
No, I am not saying this. I said this: "Furthermore, such packages must meet Debian's licensing requirements."
We cannot Debian to accept a package, and we obviously have no particular influence over Debian's release schedule. Consequently, hosting a package either temporarily or permanently on debian.koha-community.org is a valid option for us in case of technical disagreement with Debian or because we want to require a package before it is available on Debian stable. In the long run, however, it is better that such hosting be temporary; as it saves us work to have a dependency be part of Debian.
Why must packages meet the Debian requirements?
So that they have a chance of actually getting into Debian — and so that Koha does not fall into the trap of requiring non-free dependencies for the sake of developer convenience.
I should point out that this is not a new guideline. From the wiki [1]:
"The Koha project is not going to redistribute a module just because it's in CPAN"
At minimum, a CPAN module that is being considered for packaging must meet the Debian Free Software Guidelines [2]; in my opinion, that is non-negotiable given Koha's status as a GPL3+ project. Of course, there are a variety of technical requirements that a package must meet before it would get accepted by Debian, but we have more flexibility there: we can choose to host a package that is DFSG-complaint but is not quite yet ready for prime-time... if we absolutely need to.
This seems like it's adding yet another barrier to entry for new Koha developers.
Are new developers actually the primary source of suggestions that we add new CPAN dependencies to Koha?
Regardless, there are a variety of competing aims at play here, and I submit that the convenience of new developers -- or not so new developers -- does not trump other considerations that include:
* keeping the number of dependencies (and thus, potential vectors for bugs and security exposures) manageable. Each new dependency adds a maintenance cost the project; not necessarily large in and of itself, but it adds up. * ensuring Koha's stability for Debian users * having some assurance that new dependencies are likely to work; if a CPAN module is already packaged for Debian, there's at least some signal that this is the case * for that matter, easing the situation for folks running RHEL who are restricted from installing CPAN modules willy-nilly; there are at least a few such Koha users out there
Now we all need to be Debian package maintainers as well?
No. Somebody who wants to add a CPAN dependency that is not yet packaged for Debian has several avenues to take (assuming that they've triple-checked that a new dependency is actually necessary):
* they can package it themselves (and bluntly, in the case of paid development that is conducted by a commercial entity, I do not view that as an unreasonable expectation that they one way or another arrange to deal with packaging new dependencies that they propose) * they can make a request of various other developers in the Koha community who have experience building packages -- it's not just me who can do it -- although I note that a request works better than a demand. * they can make a request of the Debian Perl Group [3], who are, by all accounts, a pretty helpful bunch * they can find a Debian Developer to contract with to build the package
It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules.
CPAN, as with anything else, is subject to Sturgeon's law; using existing Perl packages helps provide a useful quality filter. As far as Debian is concerned, there are almost 3,500 CPAN modules that are already packaged for Jessie. Does this cover everything? No, of course not; but I submit that a project that already has over 150 CPAN dependencies should be cautious about adding new ones.
[1] https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency... [2] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines [3] https://pkg-perl.alioth.debian.org/
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Hi, I think I'd add some steps before 1. to the suggested workflow: we should check before any patches are pushed if the dependencies introduced are absolutely needed and can be packaged, following the guidelines that Galen pointed out. I'd also agree that the load of packaging should be shared. About bugzilla: I have been using the keyword "dependency" on any bug I spot that adds a new one. I have created and shared a search "NewDependency" based on it: https://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&list_id=157609&namedcmd=NewDependency&remaction=run&sharer_id=13 Hope this helps! Katrin Am 08.03.2016 um 18:30 schrieb Chris Cormack:
On 9 March 2016 6:25:18 am NZDT, Brendan Gallagher <info@bywatersolutions.com> wrote:
Hello All -
I'd like to have a chance to talk about the packing work flow at the next developers meeting or even the general meeting.
My thoughts are that we need a status in Bugzilla that says something like "Needs package created" or something. Also add a little spot on the dashboard under the Bugs Statuses which has a canned search for that queue.
I imagine the workflow being something like...
1. RM pushes code to master 2. RM changes status to "needs package created" 3. PackingManager creates package
I don't think it's fair to push this all on the package manager. If a dev introduces new dependencies that need packaging, it should be their responsibility to make sure this is done.
Chris
4. PM changes the status to "Pushed to Master"
The work flow is important and I'd like to make it as transparent as possible and make sure that we don't miss something. Robin, Galen, or others do you have any thoughts on this?
Thanks, Brendan
participants (5)
-
Brendan Gallagher -
Chris Cormack -
Galen Charlton -
Katrin Fischer -
Kyle Hall