Am 11.01.2016 um 21:37 schrieb Emmanuel Bourg:
> Le 11/01/2016 16:52, Markus Koschany a écrit :
>
>> I presume
>> jenkins-cli and jenkins-slave would be affected by the same short three
>> month support release cycle.
>
> jenkins-cli consists in only 9 classes and requires 4 dependencies
> (commo
Le 11/01/2016 16:52, Markus Koschany a écrit :
> I presume
> jenkins-cli and jenkins-slave would be affected by the same short three
> month support release cycle.
jenkins-cli consists in only 9 classes and requires 4 dependencies
(commons-codec, jenkins-remoting, localizer and trilead-ssh2. It d
Is there possibly involve upstream in some way? Maybe with a Sprint?
You would together find out how to automate the generation of
upload-ready packages and also pass the credentials.
Best,
Steffen
On 11/01/16 16:56, Ioan Eugen Stan wrote:
> Hi,
>
> I also think a clean cut is a good solution.
>
Hi,
I also think a clean cut is a good solution.
I've deployed Jenkins on a couple of machines and I used exclusively the
upstream packages. I try to keep to a minimium the number of non-oficial
packages but sometimes it's not doable.
Also, having a mix of officially supported and some not suppo
Am 11.01.2016 um 16:04 schrieb Emmanuel Bourg:
> Hi all,
>
> I'm pondering what we should do about Jenkins in Debian.
[...]
> 2. Package a subset of Jenkins.
>We could keep only the jenkins-cli and jenkins-slave package as they
>provide a real added value over the upstream .deb package.
Hi all,
I'm pondering what we should do about Jenkins in Debian. For the
reminder Jenkins development moves too fast and LTS releases are not
supported long enough to make it suitable for Debian stable. Security
fixes end up being almost impossible to backport properly. Moreover
upstream already p
6 matches
Mail list logo
