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
