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

Re: Proposal: Repository for fast-paced package backports



On 12/25/18 3:46 PM, Dominik George wrote:

[...]

> 
> Name of the new repository
> ==========================
> 
> In the past, the name “volatile” was used for a similar repository, but
> with a different scope (limited to data packages for things like virus
> scanners). I will thus use the working title volatile throughout this
> proposal, although this may change.
> 
> Other ideas: fastlane, unsupported
> 

"rolling" sounds like a good fit

[...]

> 
> Building packages and package dependencies
> ==========================================
> 
> Packages for volatile are built the same way as formal backports, only
> that the source is taken from unstable rather than testing. In
> particular:
> 
>  - Changes shall be kept as small as possible.
>  - The package is rebuilt against stable.
>  - The package may depend on packages in stable, stable-backports or stable-volatile.
> 

stable-rolling sounds more appropriate than stable-volatile.

> Dependencies on other packages in volatile should be avoided if
> possible. 
How to handle upgrades from stable to stable+1. Packages from backports
upgrade with no issues as stable+1 contains the same packages already
compiled for the stable+1.

How about LTS? As stable-rolling repository would be usable in
conjunction with stable-backports and stable, would then
oldstable-rolling continue to roll or just freeze in place at the moment
when the stable becomes oldstable?

[...]

> 
> 
> Implications for the situation at hand (gitlab)
> ===============================================
> 
> As there were quite a few concerns raised (some of which I share, and
> some I don’t): Of course, if a software intended for volatile has a ton
> of dependencies (intended to go into backports), all backports rules and
> powers of the ftp-masters apply. Repeating myself: volatile is not meant
> to ease the life of maintainers.
> 

Continuous delivery development model based upstream applications are
not quite a good fit for a stable release distribution.


Milan





Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: