From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.152.206.36 with SMTP id ll4mr3891302lac.6.1428396436043; Tue, 07 Apr 2015 01:47:16 -0700 (PDT) X-BeenThere: voidlinux@googlegroups.com Received: by 10.152.182.138 with SMTP id ee10ls14071lac.44.gmail; Tue, 07 Apr 2015 01:47:15 -0700 (PDT) X-Received: by 10.112.51.68 with SMTP id i4mr2637714lbo.13.1428396435585; Tue, 07 Apr 2015 01:47:15 -0700 (PDT) Return-Path: Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com. [2a00:1450:400c:c05::22e]) by gmr-mx.google.com with ESMTPS id gd5si117129wib.0.2015.04.07.01.47.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 01:47:15 -0700 (PDT) Received-SPF: pass (google.com: domain of chneuk...@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) client-ip=2a00:1450:400c:c05::22e; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of chneuk...@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) smtp.mail=chneuk...@gmail.com; dkim=pass head...@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Received: by mail-wi0-x22e.google.com with SMTP id js5so5399580wid.1 for ; Tue, 07 Apr 2015 01:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=zxAqT+pf2PYUrPLVyGl+dbECYUGlKgZ1PhTZmuAShJY=; b=y5mosaZRo3EaoKed34FPFT8eqnFLZRR+o+IEXqrkHOmqFrb1/oAEy60TTSFLoj7r6M +emm0aNsqO3u+f5vWw936grsbXMByuQk3dqz3DuBjTm9v19HcKW2/1bFLtcavi3I7aqG xB4J2gOAjvoqfku83SIY4cfG5wBA02rAk7rrINFdVgtmv8jtwXkeR78nwGuLPzSjuH2r AjxGUSQPLngBElH7f/DMNAFx9wg1vHqnERWduNCsw9YkAAHAp2OAR9Va6tiA7W0HF/nl Q1oJ5YblBBRl/Ediil/AVfH1D8WKJosypLkXSfAUBDoUcZFZ4OJPSjcZNThpmemZnGWO y1qw== X-Received: by 10.194.19.166 with SMTP id g6mr38246711wje.150.1428396435433; Tue, 07 Apr 2015 01:47:15 -0700 (PDT) Return-Path: Received: from juno.home.vuxu.org (host121-2.natpool.mwn.de. [138.246.2.121]) by mx.google.com with ESMTPSA id gt4sm9978927wib.21.2015.04.07.01.47.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 01:47:14 -0700 (PDT) Received: from localhost (juno.home.vuxu.org [local]); by juno.home.vuxu.org (OpenSMTPD) with ESMTPA id 9017f70f; Tue, 7 Apr 2015 08:47:14 +0000 (UTC) From: Christian Neukirchen To: bougyman Cc: void...@googlegroups.com Subject: Re: Void-Stable? References: Date: Tue, 07 Apr 2015 10:47:14 +0200 In-Reply-To: (bougyman@rubyists.com's message of "Mon, 6 Apr 2015 16:16:05 -0700 (PDT)") Message-ID: <87mw2kqq99.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain bougyman writes: > With the existence of the void daily package archive, I've been bouncing > around an idea about how someone (some admin/architect/enterprise) could > maintain > their own 'stable' release cycle of void. If upon initial configuration the > repos are set to an archive with a date stamp, and the user has a way to > validate that moving > from that datestamp to ### future datestamp doesn't (potentially) break any > functionality, they can safely choose an upgrade path. for instance. > > I install on 2015-03-26 and lock the repository to the archive snapshot of > that date > > on 2015-04-26 I run *magic-command* and ask if upgrading to current > (2015-04-26) would (potentially) break any installed packages. > > I get output about any important breaking changes (to xbps, etc) which may > require an 'upgrade this first' action or 'remove these' actions. > I get output that may just say: 'Upgrade to 2015-04-01 first, then to > 2015-04-15, then 2015-04-26' (or does this automagically?) > > Thoughts? So, I think rolling release ala Void works because everyone uses the same versions of software, and bugs are found and fixed quickly due to that. A stable release will perhaps be used by 10% of the users (and mostly not the devs IME; this can be seen in Debian, OpenBSD, FreeBSD), thus this quick turnaround time will drastically slow down. -> stable is possibly more buggy than current, and takes longer to fix, and in general is considered to be a burden. I think having a stable void would be a good thing to have, but I don't see right now how we can do it given our limited peoplepower. One idea I once had, for a different distro, was to split the packages into two categories: A core system (kernel, compiler, essential libs ala png, zlib, libressl, essential utils, essential daemons), and applications (X11, GNOME, ...). The core system would be maintained in a very stable way (i.e. no major version bumps, bug+sec fixes only), while the application part would be rolling release (newest Firefox etc.). And every 6 months, the core system would be updated (probably resulting in a full system recompile...) (These major rebuilds probably would be quite messy, but upstream support for a 6 month old release should be possible.) I think we are still moving too fast for a proper stable environment. Just my 2ct, -- Christian Neukirchen http://chneukirchen.org