:: Re: [devuan-dev] Blocker/task list …
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Mason Loring Bliss
Fecha:  
A: devuan developers internal list
Asunto: Re: [devuan-dev] Blocker/task list for Beowulf?
On Mon, Oct 07, 2019 at 10:45:54AM -0500, golinux@??? wrote:

> Compiling a list of outstanding Beowulf-specific bugs from bugs.devuan.org
> would be very useful.


Here's an example of how Debian tracks these things:

    https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BusterCheckList


If we look at their bug tracker,

    https://www.debian.org/Bugs/


...we can see a list of tags, but we can also just search for parts of tags. I
can pop in "buster" and see a bunch of bugs related to Debian Buster. I don't
see a list of tags or results from searching for "beowulf" on the Devuan
tracker:

    https://bugs.devuan.org/
    https://bugs.devuan.org//cgi/pkgreport.cgi?which=tag&data=beowulf


I've talked to one person on IRC working on a particular issue, but ideally
we'd have a finite list we agree upon that would constitute the set of changes
we collectively agree are release blockers.


> One para on why systemd isn't in the spirit of free software and one on open
> source vs free software is still on my personal wish list.


Here you go:

    One of the unique attributes of the free software world historically has
    been the modular nature of system components. There was opportunity for
    anyone with an interest in doing so to write a replacement for a
    component, and if the software they wrote was reliable and presented novel
    features, it might become the preferred solution for that particular task.
    The end result of this was that a wide variety of code from a large,
    diverse group of free software developers saw use in many systems, giving
    free software users a choice in what software they used. Because of this,
    we have a number of excellent free software solutions to serve almost
    every function - mailers of various sorts, loggers, web servers, process
    monitors, domain name system software, with the list going on nearly
    indefinitely, and this flexibility and suitability has made free software
    the preferred platform for writing and running software services of all
    types.


    One of the issues with systemd is that, contrary to the Unix philosophy of
   "do one thing and do it well", systemd seeks to do all things, and to
    explicitly crowd out other software by offering tightly-integrated modules
    that are heavily dependent upon one another. As operating systems
    integrate systemd, the temptation exists to run more and more systemd
    code, with each piece being difficult to replace individually given
    systemd's lack of interest in portability or standards compliance. Systemd
    seeks to define a new, defacto standard, controlled by the relatively
    small and isolated group of systemd developers, rather than adhering to
    portable, proven, multi-vendor POSIX standards, honed through decades of
    experience running complex, critical, real-world computer systems.


Note: I'm fond of my commas and would prefer that if this is used, it remain
largely intact.

--
Mason Loring Bliss (( If I have not seen as far as others, it is because
mason@??? )) giants were standing on my shoulders. - Hal Abelson