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