• Debian doesn't have a "core team", should it? can it?

    From Peter Michael Green@21:1/5 to All on Sun Apr 10 22:50:01 2022
    This is a multi-part message in MIME format.
    Recently andreas-tille sent the following message about libzstd to
    debian-devel

    I'd like to repeat that I'm really convinced that libzstd should *not*
    be maintained in the Debian Med team but rather some core team in
    Debian. It is here for historic reasons but should have moved somewhere
    more appropriately since it became its general importance.

    It ended up being transferred to the rpm team, which got it out of the
    med team's
    hair but I'm not convinced the rpm team satisfies "some core team" any
    better
    than the med team does.

    As far as I can tell Debian has broadly 3 types of teams.

    1. Teams focussed on an application area, for example the med team, the
    science team, the games team.
    2. Teams focussed on a programming language, for example the python
    team, the perl team, the rust team. There is however no such team for
    software written in C, C++ or shell script.
    3. Teams focussed on a particular piece of software

    As far as I can tell this means that there are a bunch of packages that
    "fall between the gaps", packages
    that are of high importance to Debian as a whole but are not a great fit
    for any team. They either end up not associated with a team at all or
    sometimes associated with a team who happened to be the first to
    use the library.

    I decided to get a sample of packages that could be considered "core", obviously different people have different ideas of what should be
    considered core but I decided to do the following to get a list of
    packages that hopefully most people would consider core.

    debootstrapped a new sid chroot
    ran tasksel install standard (a bit less spartan than just the base system)
    ran apt-get install build-essential (we are an opensource project,
    development tools are essential to us)
    ran apt-get install dctrl-tools (arguablly not core, but I needed it to
    run the test commands and it's only one package)

    There were 355 packages installed, built from 223 source packages. I got
    a list of source packages with
    the command

    grep-dctrl installed /var/lib/dpkg/status -n -ssource:package | cut -d '
    ' -f 1 | sort | uniq > sourcepks.txt

    I then extracted the source stanzas with.

    grep-dctrl -e -F Package `sed "s/.*/^&$/" sourcepks.txt | paste -s -d
    '|'`
    /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources > sourcestanzas.txt

    Then wrote a little python script to extract teams from those stanzas.

    #!/usr/bin/python3
    from debian import deb822
    import collections
    import sys
    f = open(sys.argv[1])
    counts = collections.defaultdict(int)
    for source in deb822.Sources.iter_paragraphs(f):
        maintainers = [source['maintainer']]
        if 'uploaders' in source:
            maintainers += source['uploaders'].split(',')
        maintainers = [s.strip() for s in maintainers if s.strip() != '']
        teams = [s for s in maintainers if ('team' in s.lower()) or
    ('lists' in s.lower()) or ('maintainers' in s.lower()) or ('group' in s.lower())]
        teams.sort()
        counts[tuple(teams)] += 1
        #print(repr(maintainers))
        #print(repr(teams));

    for teams , count in sorted(counts.items(), key = lambda x: x[1]):
        if len(teams) == 0:
            teamtext = 'no team'
        else:
            teamtext = ', '.join(teams)
        print(str(count) + ' ' + teamtext)

    This confirms my suspiscions, of the 223 source packages responsible
    for the packages installed in my "reasonablly but not super minimal" environment more than half of them were not associated with a team at all.

    I also saw a couple of packages in there maintained by the science team
    and the med team. two source packages telnet and apt-listchanges
    were orphaned.

    I do not know what the soloution is, whether a "core team" is a good idea
    or even whether one is possible at all but I feel this is an elephant that should have some light shone on it.


    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Recently andreas-tille sent the following message about libzstd
    to debian-devel<br>
    <br>
    <blockquote type="cite">
    <pre>I'd like to repeat that I'm really convinced that libzstd should *not*
    be maintained in the Debian Med team but rather some core team in
    Debian. It is here for historic reasons but should have moved somewhere
    more appropriately since it became its general importance.</pre>
    </blockquote>
    <br>
    It ended up being transferred to the rpm team, which got it out of
    the med team's<br>
    hair but I'm not convinced the rpm team satisfies "some core team"
    any better<br>
    than the med team does.<br>
    <br>
    As far as I can tell Debian has broadly 3 types of teams.<br>
    <br>
    1. Teams focussed on an application area, for example the med
    team, the science team, the games team.<br>
    2. Teams focussed on a programming language, for example the
    python team, the perl team, the rust team. There is however no
    such team for software written in C, C++ or shell script.<br>
    3. Teams focussed on a particular piece of software<br>
    <br>
    As far as I can tell this means that there are a bunch of packages
    that "fall between the gaps", packages<br>
    that are of high importance to Debian as a whole but are not a
    great fit for any team. They either end up not associated with a
    team at all or sometimes associated with a team who happened to be
    the first to<br>
    use the library.<br>
    <br>
    I decided to get a sample of packages that could be considered
    "core", obviously different people have different ideas of what
    should be considered core but I decided to do the following to get
    a list of packages that hopefully most people would consider core.<br>
    <br>
    debootstrapped a new sid chroot<br>
    ran tasksel install standard (a bit less spartan than just the
    base system)<br>
    ran apt-get install build-essential (we are an opensource project,
    development tools are essential to us)<br>
    ran apt-get install dctrl-tools (arguablly not core, but I needed
    it to run the test commands and it's only one package)<br>
    <br>
    There were 355 packages installed, built from 223 source packages.
    I got a list of source packages with<br>
    the command<br>
    <br>
    grep-dctrl installed /var/lib/dpkg/status -n -ssource:package |
    cut -d ' ' -f 1 | sort | uniq &gt; sourcepks.txt<br>
    <br>
    I then extracted the source stanzas with.<br>
    <br>
    grep-dctrl -e -F Package `sed "s/.*/^&amp;$/" sourcepks.txt |
    paste -s -d '|'`
    /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources
    &gt; sourcestanzas.txt<br>
    <br>
    Then wrote a little python script to extract teams from those
    stanzas.<br>
    <br>
    #!/usr/bin/python3<br>
    from debian import deb822<br>
    import collections<br>
    import sys<br>
    f = open(sys.argv[1])<br>
    counts = collections.defaultdict(int)<br>
    for source in deb822.Sources.iter_paragraphs(f):<br>
        maintainers = [source['maintainer']]<br>
        if 'uploaders' in source:<br>
            maintainers += source['uploaders'].split(',')<br>
        maintainers = [s.strip() for s in maintainers if s.strip() !=
    '']<br>
        teams = [s for s in maintainers if ('team' in s.lower()) or
    ('lists' in s.lower()) or ('maintainers' in s.lower()) or ('group'
    in s.lower())]<br>
        teams.sort()<br>
        counts[tuple(teams)] += 1<br>
        #print(repr(maintainers))<br>
        #print(repr(teams));<br>
    <br>
    for teams , count in sorted(counts.items(), key = lambda x: x[1]):<br>
        if len(teams) == 0:<br>
            teamtext = 'no team'<br>
        else:<br>
            teamtext = ', '.join(teams)<br>
        print(str(count) + ' ' + teamtext)<br>
    <br>
    This confirms my suspiscions, of the 223 source packages
    responsible<br>
    for the packages installed in my "reasonablly but not super
    minimal"<br>
    environment more than half of them were not associated with a team
    at all.<br>
    <br>
    I also saw a couple of packages in there maintained by the science
    team<br>
    and the med team. two source packages telnet and apt-listchanges<br>
    were orphaned.<br>
    <br>
    I do not know what the soloution is, whether a "core team" is a
    good idea<br>
    or even whether one is possible at all but I feel this is an
    elephant that<br>
    should have some light shone on it. <br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Peter Michael Green on Mon Apr 11 00:50:01 2022
    On Sun, 2022-04-10 at 21:23 +0100, Peter Michael Green wrote:
    Recently andreas-tille sent the following message about libzstd to debian-devel

    I'd like to repeat that I'm really convinced that libzstd should
    *not*
    be maintained in the Debian Med team but rather some core team in
    Debian.  It is here for historic reasons but should have moved
    somewhere
    more appropriately since it became its general importance.

    It ended up being transferred to the rpm team, which got it out of
    the
    med team's
    hair but I'm not convinced the rpm team satisfies "some core team"
    any
    better
    than the med team does.

    As far as I can tell Debian has broadly 3 types of teams.

    1. Teams focussed on an application area, for example the med team,
    the
    science team, the games team.
    2. Teams focussed on a programming language, for example the python
    team, the perl team, the rust team. There is however no such team for software written in C, C++ or shell script.
    3. Teams focussed on a particular piece of software

    As far as I can tell this means that there are a bunch of packages
    that
    "fall between the gaps", packages
    that are of high importance to Debian as a whole but are not a great
    fit
    for any team. They either end up not associated with a team at all or sometimes associated with a team who happened to be the first to
    use the library.

    I decided to get a sample of packages that could be considered
    "core",
    obviously different people have different ideas of what should be
    considered core but I decided to do the following to get a list of
    packages that hopefully most people would consider core.

    debootstrapped a new sid chroot
    ran tasksel install standard (a bit less spartan than just the base
    system)
    ran apt-get install build-essential (we are an opensource project, development tools are essential to us)
    ran apt-get install dctrl-tools (arguablly not core, but I needed it
    to
    run the test commands and it's only one package)

    There were 355 packages installed, built from 223 source packages. I
    got
    a list of source packages with
    the command

    grep-dctrl installed /var/lib/dpkg/status -n -ssource:package | cut -
    d '
    ' -f 1 | sort | uniq > sourcepks.txt

    I then extracted the source stanzas with.

    grep-dctrl -e -F Package `sed "s/.*/^&$/" sourcepks.txt | paste -s -d
    '|'`
    /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Source
    s >
    sourcestanzas.txt

    Then wrote a little python script to extract teams from those
    stanzas.

    #!/usr/bin/python3
    from debian import deb822
    import collections
    import sys
    f = open(sys.argv[1])
    counts = collections.defaultdict(int)
    for source in deb822.Sources.iter_paragraphs(f):
         maintainers = [source['maintainer']]
         if 'uploaders' in source:
             maintainers += source['uploaders'].split(',')
         maintainers = [s.strip() for s in maintainers if s.strip() !=
    '']
         teams = [s for s in maintainers if ('team' in s.lower()) or ('lists' in s.lower()) or ('maintainers' in s.lower()) or ('group' in s.lower())]
         teams.sort()
         counts[tuple(teams)] += 1
         #print(repr(maintainers))
         #print(repr(teams));

    for teams , count in sorted(counts.items(), key = lambda x: x[1]):
         if len(teams) == 0:
             teamtext = 'no team'
         else:
             teamtext = ', '.join(teams)
         print(str(count) + ' ' + teamtext)

    This confirms my suspiscions, of the 223 source packages responsible
    for the packages installed in my "reasonablly but not super minimal" environment more than half of them were not associated with a team at
    all.

    I also saw a couple of packages in there maintained by the science
    team
    and the med team. two source packages telnet and apt-listchanges
    were orphaned.

    I do not know what the soloution is, whether a "core team" is a good
    idea
    or even whether one is possible at all but I feel this is an elephant
    that
    should have some light shone on it.

    +1 for team maintainership, especially of core packages.

    To walk the walk, I've asked the Kernel Team to have iproute2
    (Priority: important) moved under the team, and they've accepted, so
    it's now done: https://salsa.debian.org/kernel-team/iproute2

    It's a low-hanging fruit given there's an existing team it clearly fits
    into, but it's a start.

    --
    Kind regards,
    Luca Boccassi

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmJTXtIACgkQKGv37813 JB5oeBAAg1/WRjAcb8O2Iwb3S0QlGeUDwA5sbDPrh7cQAsHXrLx/a8zuf+x45zCk P6VdZprd7jOYAWyST/EYu/GPwv4mMAe6H8Lt8YGzl5cOV9Q+/NxJ6of+Y9/zyq7K a8ew6oTpjxUWYIiICxSqyns8zm7FjntV4HupTG4IWWFaOir7wr3kAmGxuHUp9YMU RYpxLW4vZYFY54JngSFMOFrHE5Hc+nGgjl+NvbbM11FhrVMgwo2/nco0usYxGzO7 4xl7uFdCfIXGdc7P51nkO1FlXp2Ug3ylWnV7EI7hQWTnqjCZIGTjd9jfnnLsfa0I Dyop+kUoYYqzSSxl9Wsiz4rlstqK9wsfd98UhwCkLMD2wbqPPJFcMu+6YZyLN3t7 OPLbMxfilxRepNEs/MZmHTFC8FjjuSaelwilTvcoflnIdtvYk1CQ8361ZTyXlC6O mSFp3M8bxkileJcmkLodDQJf3QkqlUzJ/QrFFOptQSrvgEqxrtuEgfkVx8Kwxera olkFHUPl/hnuUrIa4KpsllrQcxqeFBeTM4Y9nrZRyjllcgRGIr5Qv15qyMO6zsZQ gtZzKKAp9gLaZEa0rkOgSP1blrZxe4gfoXluF+rN8VWuZAIk+HNzTDPl3IUyTFO6 P+siL5BY9iyrfsCiBeU0SwT9tMh4pXhlI45Yidob43likdjipZ0=
    =S9Kw
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From M. Zhou@21:1/5 to Peter Michael Green on Mon Apr 11 07:50:01 2022
    Hi,

    "Core team" is already ambiguous enough. I'd suggest leave it alone and do not try to define it. Attempts to define it are likely lead to nowhere other than
    a definition hell. Unless there is such need in Debian constitution, I think Debian should not try to do that.

    The intention of that post is simply transferring some packages to more suitable maintainers. As long as the new maintainer (rpm team as you mentioned) feels suitable to take over, I don't see any problem here.

    I'm even ok with non-debian member being maintainers for critical packages
    as long as the work goes through some kind of peer review.

    On Sun, 2022-04-10 at 21:23 +0100, Peter Michael Green wrote:
    Recently andreas-tille sent the following message about libzstd to debian-devel
     
    I'd like to repeat that I'm really convinced that libzstd should *not*
    be maintained in the Debian Med team but rather some core team in
    Debian. It is here for historic reasons but should have moved somewhere more appropriately since it became its general importance.
     
     It ended up being transferred to the rpm team, which got it out of the med team's
     hair but I'm not convinced the rpm team satisfies "some core team" any better
     than the med team does.
     
     As far as I can tell Debian has broadly 3 types of teams.
     
     1. Teams focussed on an application area, for example the med team, the science team, the games team.
     2. Teams focussed on a programming language, for example the python team, the perl team, the rust team. There is
    however no such team for software written in C, C++ or shell script.
     3. Teams focussed on a particular piece of software
     
     As far as I can tell this means that there are a bunch of packages that "fall between the gaps", packages
     that are of high importance to Debian as a whole but are not a great fit for any team. They either end up not
    associated with a team at all or sometimes associated with a team who happened to be the first to
     use the library.
     
     I decided to get a sample of packages that could be considered "core", obviously different people have different
    ideas of what should be considered core but I decided to do the following to get a list of packages that hopefully
    most people would consider core.
     
     debootstrapped a new sid chroot
     ran tasksel install standard (a bit less spartan than just the base system)  ran apt-get install build-essential (we are an opensource project, development tools are essential to us)
     ran apt-get install dctrl-tools (arguablly not core, but I needed it to run the test commands and it's only one
    package)
     
     There were 355 packages installed, built from 223 source packages. I got a list of source packages with
     the command
     
     grep-dctrl installed /var/lib/dpkg/status -n -ssource:package | cut -d ' ' -f 1 | sort | uniq > sourcepks.txt
     
     I then extracted the source stanzas with.
     
     grep-dctrl -e -F Package `sed "s/.*/^&$/" sourcepks.txt | paste -s -d '|'` /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources > sourcestanzas.txt
     
     Then wrote a little python script to extract teams from those stanzas.
     
     #!/usr/bin/python3
     from debian import deb822
     import collections
     import sys
     f = open(sys.argv[1])
     counts = collections.defaultdict(int)
     for source in deb822.Sources.iter_paragraphs(f):
         maintainers = [source['maintainer']]
         if 'uploaders' in source:
             maintainers += source['uploaders'].split(',')
         maintainers = [s.strip() for s in maintainers if s.strip() != '']      teams = [s for s in maintainers if ('team' in s.lower()) or ('lists' in s.lower()) or ('maintainers' in
    s.lower()) or ('group' in s.lower())]
         teams.sort()
         counts[tuple(teams)] += 1
         #print(repr(maintainers))
         #print(repr(teams));
     
     for teams , count in sorted(counts.items(), key = lambda x: x[1]):
         if len(teams) == 0:
             teamtext = 'no team'
         else:
             teamtext = ', '.join(teams)
         print(str(count) + ' ' + teamtext)
     
     This confirms my suspiscions, of the 223 source packages responsible
     for the packages installed in my "reasonablly but not super minimal"  environment more than half of them were not associated with a team at all.  
     I also saw a couple of packages in there maintained by the science team  and the med team. two source packages telnet and apt-listchanges
     were orphaned.
     
     I do not know what the soloution is, whether a "core team" is a good idea  or even whether one is possible at all but I feel this is an elephant that  should have some light shone on it.
     

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)