[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: