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

Re: State of Jenkins in Debian



On 03/23/2014 02:20 AM, Guido Günther wrote:
> Hi Tony,
> On Tue, Mar 11, 2014 at 09:43:48PM -0700, tony mancill wrote:
> [..snip..] 
>> In any event, I can sympathize and am glad that you're opening the
>> discussion.  Not everything is going to fit the "stable" distribution
>> model - sometimes you need the "freshest bits."
> 
> We do have stable-backports for the freshness part. Because of the great
> work of the Debian Java Team it is becoming more and more possible to
> run popular Java based web applications like Jenkins on Debian with
> Debian's benefits attached (apt-get install, DFSG, Policy, Bug tracker,
> security support) and without having to resort to third party sources or
> to download heaps of artifacts of untrusted origin.
> 
> This might not be that important if you're a Java Shop (TM) and rely on
> latest versions (but then why would you run the version in Debian then
> anyway). But if you're only a consumer of the resulting Web Application
> (e.g. like Jenkins for CI) then Debian's Java packages in stable are
> _extremely_ valuable. Especially so if they cover the whole stack from
> the JDK to the web application and if they're part of a stable
> release because that's what got well integrated and tested during the
> freeze. PPAs don't have this kind of "integration gurantee" and might be
> a too fast moving target for mere "consumers" of the web appliation.
> What would be the benefit over getting the .deb from jenkins.org?
> 
> So to decide what version's should be shipped in stable please take into
> account whom you ship it for.

Hi Guido,

I agree with your distinction between users of stable/stable-backports
and shops that need to use the latest and greatest. Debian has developed
multiple mechanisms to fit a variety of levels of
risk-avoidance/tolerance for users.

My concern is not that we don't have the proper channels through which
to deliver, but that each means another release to support.  In this
model we have (at a minimum) unstable, stable-security (which requires
back-porting of security patches), and stable-backports (which means all
dependencies must also appear in stable-backports).

With the current participation in the Java Team, it often feels like
we're barely able (or not) to keep up with RC/FTBFS bugs and upstream
releases for unstable.  Supporting stable-backports is another ask that
is potentially very time-consuming.

Cheers,
tony

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: