My recent job involves working with Jenkins, these days. On 02/26/2015 02:08 PM, Daniel Pocock wrote: > In the past I've encountered two types of problem: > > a) upstream makes some change (e.g. leaving some new header out of their > distribution tarball) or something else that is only discovered after > they release a new version >
This would still be the same. If a build dependency is not added, your package would fail to build. And I think this step should be left as is, and should require human intervention. > b) something else changes in unstable (e.g. somebody uploaded a new > version of a reSIProcate dependency just a few days before I made a > reSIProcate release, this would have been a much easier thing to deal > with before I made the upstream tag) I guess this is where it fits the most. In Debian Sid, everything is a moving piece. With Jenkins, it'd help a lot > and I feel that making regular Jenkins builds of the packages, > possibly for every upstream commit and every dependency change in > unstable, would help detect problems sooner and usually at a point in > time when it is easier to resolve them. In my opinion, that is an overkill. You may instead want to track any point releases (including aplhas, betas and RCs). -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fea8sb-qad....@news.researchut.com
