Package: wnpp
Severity: wishlist
Owner: James Page <james.page@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110608075852.7359.53240.reportbug@hendrix.shouse .local">http://lists.debian.org/20110608075852.7359.53240.reportbug@hendrix.shouse .local

Hi James,

On Wed, 08 Jun 2011 08:58:52 +0100, James Page <james.page@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=6395&view=markup

Cheers,
--
Damien


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8541fc45837971611ec1e90c2de4044b@drazzib.com">http ://lists.debian.org/8541fc45837971611ec1e90c2de4044b@drazzib.com

Hi James,

On Wed, 08 Jun 2011 08:58:52 +0100, James Page <james.page@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=6395&view=markup

Cheers,
--
Damien


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8541fc45837971611ec1e90c2de4044b@drazzib.com">http ://lists.debian.org/8541fc45837971611ec1e90c2de4044b@drazzib.com

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

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

On Wed, 08 Jun 2011 15:10:06 +0100, James Page <james.page@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-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 84f8fe5d8bf3ca95d1b2788954c46ee1@drazzib.com">http ://lists.debian.org/84f8fe5d8bf3ca95d1b2788954c46ee1@drazzib.com

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.page@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

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