Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
On Wed, 2011-06-08 at 17:30 +0200, Damien Raude-Morvan wrote: On Wed, 08 Jun 2011 15:10:06 +0100, James Page james.p...@canonical.com wrote: [...] If changes made by JenkinsCI team are not too intrusive maybe we can merge them - as patches - into existing debian packages ? Might be the best option for inactive upstream projects like dom4j, trilead-ssh2 or commons-jexl. That approach might work; I'll review my current list of variants for patchsets that could be applied (and document it somewhere so it can easily be reviewed). Most changes either seem to be adding new distinct features or fixing minor bugs that where impacting Jenkins. Is there any specific policy on taking this approach? In effect Debian would be branching from the original upstream - this is in principle the same as what jenkins are doing upstream although it would reduce the code duplication in the distro. [...] Code duplication is always a bad thing (tm) from a distribution POV : increase maintenance overhead, imply some security issues have to be fixed multiple times... YMMV, but I don't consider this a blocking issue or a no-go for JenkisCI but I think we should at least describe this case explicitly : http://wiki.debian.org/EmbeddedCodeCopies http://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup Thanks for the feedback and for pointing me at the above Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
Le jeudi 09 juin 2011 10:41:24, James Page a écrit : That approach might work; I'll review my current list of variants for patchsets that could be applied (and document it somewhere so it can easily be reviewed). Most changes either seem to be adding new distinct features or fixing minor bugs that where impacting Jenkins. Ok, fine for me. Is there any specific policy on taking this approach? In effect Debian would be branching from the original upstream - this is in principle the same as what jenkins are doing upstream although it would reduce the code duplication in the distro. AFAIK, generic policy regarding patches in Debian package is linked to Debian Social Contract, section 2 We will give back to the free software community. Main goal is to submit most patches upstream to also improve FOSS ecosystem in general. But it's a bit complicated to apply to inactive upstream, so we can just include patches inside Debian and send them to upstream bugtracker (so at least other Linux dist can benefit from it. Cheers, -- Damien signature.asc Description: This is a digitally signed message part.
Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
Package: wnpp Severity: wishlist Owner: James Page james.p...@canonical.com * Package name: jenkins-htmlunit-core-js Version : 2.6-hudson-1 * URL : http://github.com/jenkinsci/core-js * License : MPL-1.1 or GPL-2 (+ misc others) Programming Lang: Java Description : Jenkins branch of the HtmlUnit Core JS Interpreter HtmlUnit is a GUI-Less browser for Java programs. It models HTML documents and provides an API that allows you to invoke pages, fill out forms, click links, etc... just like you do in your normal browser. . This package contains the Jenkins branch of the HtmlUnit adaptation of Mozilla Rhino Javascript engine for Java with supports HtmlUnit. . HtmlUnit Changes are documented by a diff (rhinoDiff.txt) contained in the generated jar files. This package is required to support packaging of jenkins and is one of a number of branches that the jenkinsci project maintains. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
Hi James, On Wed, 08 Jun 2011 08:58:52 +0100, James Page james.p...@canonical.com wrote: [...] This package contains the Jenkins branch of the HtmlUnit adaptation of Mozilla Rhino Javascript engine for Java with supports HtmlUnit. . HtmlUnit Changes are documented by a diff (rhinoDiff.txt) contained in the generated jar files. This package is required to support packaging of jenkins and is one of a number of branches that the jenkinsci project maintains. So, JenkisCI is using a fork (jenkins-htmlunit-core-js) of the fork (htmlunit-core-js [1]) of Rhino package... JenkisCI upstream seems a love code (and effort...) duplication. /with my rhino package maintainer hat/ Rhino is - now - an active project again (at least, they made a new release on 2011-06-03 [2]). You should try to convince JenkisCI team to merge back its changes [3] (and htmlunit changes [4]) back into Rhino [1] http://thread.gmane.org/gmane.comp.java.htmlunit.devel/7915 [2] http://www.mozilla.org/rhino/download.html [3] https://github.com/jenkinsci/core-js/blob/master/rhinoDiff.txt [4] http://htmlunit.svn.sourceforge.net/viewvc/htmlunit/trunk/core-js/rhinoDiff.txt?revision=6395view=markup Cheers, -- Damien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
Hi Damien On Wed, 2011-06-08 at 15:48 +0200, Damien Raude-Morvan wrote: So, JenkisCI is using a fork (jenkins-htmlunit-core-js) of the fork (htmlunit-core-js [1]) of Rhino package... JenkisCI upstream seems a love code (and effort...) duplication. I don't disagree that this is pretty ugly; Jenkins CI upstream does fork other projects frequently - here's a short list of the ones I'm being impacted by during packaging: dom4j commons-jexl json-lib htmlunit xstream commons-jelly winstone trilead-ssh2 and ones I intend to avoid: jcifs jinterop Although some of these forks may be due to upstream inactivity I think this reflects the ~weekly release schedule of the project and the ease at which they can fork and upstream and maintain it to resolve their immediate issues. The introduction of a 3 monthly stable release should help reduce the impact of the standard release velocity but it does not necessarily remove the forked dependencies. I have seen forks disappear and the project revert back to mainstream upstream (jmdns was an example of this but I just noticed they forked it again - doh!). /with my rhino package maintainer hat/ Rhino is - now - an active project again (at least, they made a new release on 2011-06-03 [2]). You should try to convince JenkisCI team to merge back its changes [3] (and htmlunit changes [4]) back into Rhino Absolutely; I'll endeavour to work on making this happen. I appreciate that this upstream behaviour does increase the effort required to support packaging of jenkins. I have the packaging in place so the additional effort is not really on me in the short term (although I expect to have to deal with updates and bug fixes) - it will be whomever sponsors these packages for me. Do you think this will block entry into Debian? Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
On Wed, 08 Jun 2011 15:10:06 +0100, James Page james.p...@canonical.com wrote: I don't disagree that this is pretty ugly; Jenkins CI upstream does fork other projects frequently - here's a short list of the ones I'm being impacted by during packaging: dom4j commons-jexl json-lib htmlunit xstream commons-jelly winstone trilead-ssh2 If changes made by JenkinsCI team are not too intrusive maybe we can merge them - as patches - into existing debian packages ? Might be the best option for inactive upstream projects like dom4j, trilead-ssh2 or commons-jexl. [...] The introduction of a 3 monthly stable release should help reduce the impact of the standard release velocity but it does not necessarily remove the forked dependencies. Yeah. I have seen forks disappear and the project revert back to mainstream upstream (jmdns was an example of this but I just noticed they forked it again - doh!). [...] I appreciate that this upstream behaviour does increase the effort required to support packaging of jenkins. I have the packaging in place so the additional effort is not really on me in the short term (although I expect to have to deal with updates and bug fixes) - it will be whomever sponsors these packages for me. Do you think this will block entry into Debian? Code duplication is always a bad thing (tm) from a distribution POV : increase maintenance overhead, imply some security issues have to be fixed multiple times... YMMV, but I don't consider this a blocking issue or a no-go for JenkisCI but I think we should at least describe this case explicitly : http://wiki.debian.org/EmbeddedCodeCopies http://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup Cheers, -- Damien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
