There is one thing I would recommend different that the standard Debian model. Release only the right amount of packages to create a working operating system under a complete installation, and dedicate the rest of all packages to Debian friendly build scripts for packages of the non-sequitur ranks to keep anything and everything optional, as that, optional.
This might help other non-Linux distributions like kfreebsd and killumos (Dyson) formulate strategies for packages. Any thoughts on this? Sent from my Windows Phone ________________________________ From: Stephanie Daugherty<mailto:sdaughe...@gmail.com> Sent: 7/16/2015 10:37 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [DNG] devuan LTS ILTS just doesn't make sense with a release cycle that's already set to be one of the slowest in the Linux world. Debian, and now Devuan releases are extremely conservative. N+1 cycles are good enough. The manpower that would be required to maintain 4, 5, or more more supported "released" branches is manpower that could be better spent elsewhere - improving the release engineering and working through the backlog of bugs. <rant> IMHO the enterprise mindset does more harm than good, because deferring change creates a vicious cycle, where the accumulated breakage of half a decade between each release prompts cries for even more time, and more breakage, meanwhile more dirty hacks and accumulated cruft build up within that organization's infrastructure, adding to the fragility and breakage. Meanwhile, developers demand newer libraries, runtimes, and components for applications - as the "solution" to any problem from upstream maintainers is ALWAYS to run the latest stable upstream version come hell or high water, and the first time that developer tries to use a feature that's the documentation says is there but's not in the decade-old version that happens to be available, they demand updates - which then get compiled from source or installed from packages obtained from god knows where, along with a slew of dependencies. A reasonable, conservative release cycle, coupled with the 4 branch (unstable, testing, stable, oldstable) and a FIRM n+1 support policy minimizes the cost of support, sets firm expectations for EOL, and provides more than enough time to test, qualify, and migrate, while forcing organizations to address their infrastructure's growing technical debt while they still have the institutional memory to understand how. If you can't do this in the 2 years that typically go between releases, then your problem is not that the releases are too fast, it's that your organization is institutionally incompetent. </rant> On Fri, Jul 17, 2015 at 12:57 AM James Powell <james4...@hotmail.com> wrote: > An LTS branch isn't needed if you do version controlled releases and > sponsor support for versioned releases for at least 3-4 versions back. > > To be fair, I've used Slackware long enough to see how maintaining a > versioned release can go right, and seen enough of Ubuntu to see how it can > go horribly wrong. > > Devuan should have at least 3 branches. > > Versioned releases released on annual cycles as packages mature. > > Unstable but tested branch similar to Slackware-Current in which Versioned > releases are established. > > Experimental branch for new packages that aren't tested or just slightly > tested for buildability in a working environment that will determine what > goes into Unstable. This branch should also NOT be part of the mainline > availability but accessible through a git/svn/cvs client only for safety > reasons, namely preventing someone from blowing their system to Hell. > > As releases mature, 1.0 would be maintained until the fourth or fifth > release year following, then pastured, regardless of version number. The > only time the main number should be changed is IF and ONLY IF glibc is > updated, otherwise 1.0 would transmigrate to 1.1. > > How does that sound? > > Sent from my Windows Phone > ------------------------------ > From: Adam Borowski <kilob...@angband.pl> > Sent: 7/16/2015 9:44 PM > To: dng@lists.dyne.org > Subject: Re: [DNG] devuan LTS > > On Thu, Jul 16, 2015 at 09:39:41PM -0700, Gregory Nowak wrote: > > the recent discussions here have made me think about what features I > > would like devuan to have which debian doesn't currently have. One > > feature that comes to mind is a long term support branch like what > > ubuntu has. > > Since squeeze, every release has amd64+i386-only long term support. > > -- > ⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀ > ⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠀⠀⠀⠀⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠀⠀⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀ > (https://github.com/kilobyte/braillefont for this hack) > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
