Void-Stable?

Void-Stable?

[bougyman]

[-- Attachment #1.1: Type: text/plain, Size: 1013 bytes --]


  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?

bougy

[-- Attachment #1.2: Type: text/html, Size: 1169 bytes --]

Re: Void-Stable?

[bougyman]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

I would also get output of 'these packages have security updates' in the
timeframe.

bougy

On Mon, Apr 6, 2015 at 6:16 PM, bougyman <boug...@rubyists.com> wrote:

>
>   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?
>
> bougy
>
> --
> You received this message because you are subscribed to the Google Groups
> "voidlinux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to voidlinux+...@googlegroups.com.
> To post to this group, send email to void...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/voidlinux/fb1ba803-267c-43eb-8805-88600b5d19a5%40googlegroups.com
> <https://groups.google.com/d/msgid/voidlinux/fb1ba803-267c-43eb-8805-88600b5d19a5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

[-- Attachment #2: Type: text/html, Size: 2649 bytes --]

Re: Void-Stable?

[Kevin Berry]

[-- Attachment #1.1: Type: text/plain, Size: 1462 bytes --]

I'd definitely like this sort of thing.  I love Void as a distro, but I 
can't sanely use a rolling release distribution for my production servers 
without some kind of safe upgrade path, similar to how Ubuntu snapshots 
every 6 months.  Ideally, support short exist for security updates for a 
year from a patch level, me thinks.

On Monday, April 6, 2015 at 6:16:05 PM UTC-5, bougyman wrote:
>
>
>   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?
>
> bougy
>

[-- Attachment #1.2: Type: text/html, Size: 1724 bytes --]

Re: Void-Stable?

[Stefan Mühlinghaus]

[-- Attachment #1.1: Type: text/plain, Size: 985 bytes --]

I suppose someone could maintain a series of "stable" repositories that are 
(at time of creation) essentially copies of the main void repositories. A 
simple shell script could be used switch releases on the users system. 
Security updates may then simply be backported into previous releases.

However, to ensure that updates between the releases do not break anything 
would be a HUGE commitment, very time-consuming and with limited resources 
(time, manpower) there is still always the possibility that some problems 
will be overlooked. An additional mechanism would probably need to be 
implemented to (semi)automatically deal with any update conflicts that 
cannot be avoided in the packages.

At that point you would need to update step by step, one release at a time, 
even if your systems current state is several releases back. Otherwise 
every new release has to be tested/fixed for all supported prior releases, 
which would multiply the effort to do so.

[-- Attachment #1.2: Type: text/html, Size: 1026 bytes --]

Re: Void-Stable?

[Christian Neukirchen]

bougyman <boug...@rubyists.com> 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  <chneuk...@gmail.com>  http://chneukirchen.org

Re: Void-Stable?

[Juan RP]

[-- Attachment #1.1: Type: text/plain, Size: 144 bytes --]


I agree with Christian :-)

But I waste enough time daily to even think on a periodic stable release, 
of course
help is always welcome.

[-- Attachment #1.2: Type: text/html, Size: 173 bytes --]