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

2022-04-10 Thread M. Zhou
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. 
>  



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

2022-04-10 Thread Luca Boccassi
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


signature.asc
Description: This is a digitally signed message part


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

2022-04-10 Thread Peter Michael Green
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.