Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #8869 > unrolled thread

Replace the TC power to depose maintainers

Back to article view | Back to linux.debian.project

Contents

  Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 16:50 +0100
    Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 17:20 +0100
      Re: Replace the TC power to depose maintainers Sean Whitton <spwhitton@spwhitton.name> - 2016-12-01 18:30 +0100
        Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 19:00 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 18:50 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 19:10 +0100
        Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 19:30 +0100
      Re: Replace the TC power to depose maintainers Sheetal Shalini <sheetalsh456@gmail.com> - 2016-12-03 11:40 +0100
      Re: Replace the TC power to depose maintainers Jérémy Bobbio <lunar@debian.org> - 2016-12-03 21:30 +0100
        Re: Replace the TC power to depose maintainers Andreas Tille <andreas@an3as.eu> - 2016-12-08 16:30 +0100
    Re: Replace the TC power to depose maintainers Vincent Bernat <bernat@debian.org> - 2016-12-01 19:10 +0100
    Re: Replace the TC power to depose maintainers Clint Adams <clint@debian.org> - 2016-12-01 19:30 +0100
      Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 19:40 +0100
    Re: Replace the TC power to depose maintainers Stefano Zacchiroli <zack@debian.org> - 2016-12-01 19:30 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 12:50 +0100
        Re: Replace the TC power to depose maintainers Johannes Schauer <josch@debian.org> - 2016-12-02 13:40 +0100
          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 14:00 +0100
          Re: Replace the TC power to depose maintainers Adam Borowski <kilobyte@angband.pl> - 2016-12-02 16:10 +0100
          Re: Replace the TC power to depose maintainers Iustin Pop <iustin@debian.org> - 2016-12-02 20:40 +0100
      Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-02 13:20 +0100
        Re: Replace the TC power to depose maintainers Johannes Schauer <josch@debian.org> - 2016-12-02 13:50 +0100
          Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-02 14:50 +0100
            Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-02 16:30 +0100
            Re: Replace the TC power to depose maintainers Raphael Hertzog <hertzog@debian.org> - 2016-12-02 23:30 +0100
              Re: Replace the TC power to depose maintainers Paul Wise <pabs@debian.org> - 2016-12-03 07:00 +0100
                Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-03 11:30 +0100
                  Re: Replace the TC power to depose maintainers Paul Wise <pabs@debian.org> - 2016-12-03 11:50 +0100
                    Re: Replace the TC power to depose maintainers Sheetal Shalini <sheetalsh456@gmail.com> - 2016-12-03 11:50 +0100
                      Re: Replace the TC power to depose maintainers David Bremner <david@tethera.net> - 2016-12-03 12:20 +0100
                    Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 12:40 +0100
                      Re: Replace the TC power to depose maintainers [and 1 more messages] Russ Allbery <rra@debian.org> - 2016-12-05 18:50 +0100
                        Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 19:10 +0100
                          Re: Replace the TC power to depose maintainers [and 1 more messages] Lars Wirzenius <liw@liw.fi> - 2016-12-05 19:20 +0100
                            Re: Replace the TC power to depose maintainers [and 1 more messages] Lars Wirzenius <liw@liw.fi> - 2016-12-05 20:10 +0100
                            Re: Replace the TC power to depose maintainers [and 1 more messages] Laura Arjona Reina <larjona@debian.org> - 2016-12-05 20:10 +0100
                            Re: Replace the TC power to depose maintainers [and 1 more messages] Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:10 +0100
                              Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:10 +0100
                                Re: Replace the TC power to depose maintainers [and 1 more messages] Tollef Fog Heen <tfheen@err.no> - 2016-12-06 05:30 +0100
                                Formal declaration of weak package ownership in source packages (was:  Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 09:20 +0100
                                  Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Adam Borowski <kilobyte@angband.pl> - 2016-12-06 10:20 +0100
                                    Re: Formal declaration of weak package ownership in source packages (was:  Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 15:00 +0100
                                      Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Adam Borowski <kilobyte@angband.pl> - 2016-12-06 15:20 +0100
                                        Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Holger Levsen <holger@layer-acht.org> - 2016-12-06 15:20 +0100
                                          Re: Formal declaration of weak package ownership in source packages (was:  Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 16:00 +0100
                                            Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Lars Wirzenius <liw@liw.fi> - 2016-12-06 16:10 +0100
                                              Re: Formal declaration of weak package ownership in source packages (was:  Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 16:20 +0100
                                                Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Lars Wirzenius <liw@liw.fi> - 2016-12-06 16:30 +0100
                                                  Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 16:50 +0100
                                                    Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Enrico Zini <enrico@enricozini.org> - 2016-12-11 19:50 +0100
                                                      Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:30 +0100
                                                        Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 02:40 +0100
                                                          Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 03:00 +0100
                                                            Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 03:20 +0100
                                                              Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 14:20 +0100
                                                                Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 15:30 +0100
                                                                  Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 18:20 +0100
                                                                  Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Philip Hands <phil@hands.com> - 2016-12-12 18:20 +0100
                                                                    Re: Formal declaration of weak package ownership in source packages Russ Allbery <rra@debian.org> - 2016-12-12 19:40 +0100
                                                          Re: Formal declaration of weak package ownership in source packages Vincent Bernat <bernat@debian.org> - 2016-12-12 09:30 +0100
                                                            Re: Formal declaration of weak package ownership in source packages Scott Kitterman <debian@kitterman.com> - 2016-12-12 13:50 +0100
                                                Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Holger Levsen <holger@layer-acht.org> - 2016-12-06 16:40 +0100
                                    Re: Formal declaration of weak package ownership in source packages  (was: Replace the TC power to depose maintainers) Christian Hofstaedtler <zeha@debian.org> - 2016-12-06 18:40 +0100
                                  Re: Formal declaration of weak package ownership in source packages (was:  Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 14:50 +0100
            Re: Replace the TC power to depose maintainers Andreas Tille <andreas@an3as.eu> - 2016-12-08 16:40 +0100
          Re: Replace the TC power to depose maintainers Rhonda D'Vine <rhonda@deb.at> - 2016-12-09 13:10 +0100
            Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:20 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 16:50 +0100
        Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-03 11:50 +0100
          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-03 18:40 +0100
            Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-03 23:30 +0100
              Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 12:10 +0100
                Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 19:30 +0100
                Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:20 +0100
                  Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:10 +0100
                    Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-05 23:20 +0100
                      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 00:20 +0100
                        Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-06 01:00 +0100
                          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 15:10 +0100
                    Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-06 05:40 +0100
        Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 15:20 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 15:30 +0100
        Re: Replace the TC power to depose maintainers Stefano Zacchiroli <zack@debian.org> - 2016-12-07 11:30 +0100
          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-07 12:00 +0100
          Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-08 07:40 +0100
            Re: Replace the TC power to depose maintainers Piotr Ożarowski <piotr@debian.org> - 2016-12-08 11:30 +0100
      Maintainerless Hive-Mind? (was Re: Replace the TC power to depose  maintainers) Guillem Jover <guillem@debian.org> - 2016-12-08 03:20 +0100
        Re: Maintainerless Hive-Mind? (was Re: Replace the TC power to  depose maintainers) Raphael Hertzog <hertzog@debian.org> - 2016-12-09 11:40 +0100
    Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 15:20 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 15:50 +0100
        Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 19:50 +0100
      Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 15:50 +0100
        Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 16:10 +0100
          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 18:50 +0100
            Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:30 +0100
              Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:00 +0100
        Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:20 +0100
          Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 22:10 +0100
            Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 22:20 +0100
              Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 22:50 +0100
            Re: Replace the TC power to depose maintainers Matthew Woodcraft <matthew@woodcraft.me.uk> - 2016-12-05 23:20 +0100
        Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-10 07:50 +0100
          Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:40 +0100
            Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-16 13:30 +0100
              Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-16 14:10 +0100
    Re: Replace the TC power to depose maintainers Russell Stuart <russell-debian@stuart.id.au> - 2016-12-07 00:10 +0100
      Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-07 09:40 +0100
        Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-07 12:00 +0100

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#8940

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead,

I was thinking about what Scott wrote, and also went back and read
some of the bug log he is referring to.  I wonder if there is an
underlying a useful observation about the merits of team maintenance.

Most of the really bad cases I have seen have been a single
maintainer.  In packages with more than one person involved, even if
there is someone in the team whose communication skils are not
brilliant, it is normally possible to work with the rest of the team.

There is of course a possibility that a whole team might get a kind of
groupthink.  I have indeed seen that in a few situations, but it is
obviously very rarely practical to replace a whole team, even if a
decision to do so could somehow be made.


Can we come up with some way whereby the maintainership authority is
always shared, somehow ?  Either with a team, or with the whole
project (QA-style), or with the first person who comes along and wants
to try to help ?

Is there a way to do this that would work in practice ?

Some ideas:

 * Document that all packages ought to have several maintainers, if
   there are people available to do that job.

 * A new rule that for a package where only one human being is named
   in Maintainer/Uploaders, any DD who wants to help the package
   SHOULD add themselves to Uploaders and thereby become a maintainer
   equal in standing to the existing maintainer.

   That is, discourage NMUing a sole-maintained package, in favour of
   joining its as a maintainer - importantly, to encourage joining as
   a maintainer without asking first.

   So the process would be:

   Alice sees that a package is solo-maintaineed, and there is
   something she wants to fix in it.  She uploads to NMU/DELAYED-7
   adding herself to Maintainers, and maybe fixing any easy RC bugs.
   She also simultaneously emails the maintainer to introduce herself,
   offer her help, and consult on plans for the future of the package.

   Something like:

      Hi, Bob.  I was looking at gnomovision, and saw that you seem to
      be dealing with it alone.  I would like to help so I have taken
      the liberty of becoming a maintainer, with my upload which I
      have just pushed to DELAYED-7.

      I also fixed #890123 (the RC bug) in what I hope is the right
      way.  Please let me know if I got it wrong.

      To be honest, I don't have a great deal of time for doing major
      work on gnomovision but I can help deal with obvious problems
      and help keep the package in tolerable shape.  As you will know,
      we (Debian) recently decided that it's better for me to formally
      become a maintainer of a package which would otherwise have only
      one person looking after it.

      I hope this all seems good to you and I look forward to working
      with you.

      Regards,
      Alice.

 * Change the dev ref so that if a package has only one maintainer,
   any upload should be considered a maintainer upload and the usual
   NMU rules do not need to be followed ?

   Probably bad because no-one will want to do such a hostile act.

 * Explicit authority for the MIA team to declare that someone is no
   longer a maintainer, to avoid Maintainer fields giving the
   appearance of multiple maintainers when actually there is only one
   maintainer right now.

 * Disputes within maintainership teams might have to end up in front
   of the TC, more often.  But then the question is much more "what is
   the best way to do X or Y".

 * Maintainership to be recorded elsewhere so that it is not
   neccessary to upload to change the maintainer.

   There could be a web UI in which SSO-logged-in DDs could see a
   "join team for this package" button which would automatically join
   the team if there was a sole maintainer, but would turn into an
   "apply to join the team" button if there were at least three
   existing maintainers.

Or something.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8950

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 06, 2016 at 02:29:13PM +0000, Ian Jackson wrote:
> Can we come up with some way whereby the maintainership authority is
> always shared, somehow ?

The net result of this would be that anyone who maintains packages in
Debian will do so as part of a team. Likely, people maintaining more
than one package will end up being part of several teams.

In such a hypothetical world you seem to be persuaded that, within all
those teams, people will generally learn to work together amicably and
find ways to avoid stepping on each other toes. This definitely matches
my teamwork experience in Debian --- Sometimes you, as a team member,
are confident you're doing the right thing, and will just go ahead and
make a change. Sometimes you'll have doubts and ask before acting.
Sometimes you'll screw things up, and either you'll clean up after
yourself or someone else will do so for you (when this happens, cursing
will be involved).

So my question here is: why would someone who has learned to work
amicably *within* the boundaries of several teams, will behave any
different *across* those boundaries, when contributing to packages that
belong to other teams? I think the behavior will be the same. So, if we
go down this path, I'm not sure why we should stop at teams, instead of
just having the de facto equivalent of "Maintainer: Debian" for all
packages.

*Of course* there will be conflicts, but it is absolutely not clear to
me why they would be any worse, or any more frequent, than the conflicts
we have today within (potentially very large) teams.

[ As a caveat: the "Maintainer" field currently acts as both a contact
  point for a given package, and as "fences" separating who is allowed
  to contribute without asking for permission and who should ask first.
  I'm advocating only against the latter meaning, not the former. But
  the former can be implemented in other ways. For instance, Nicolas
  Dandrimont pointed me to the fact that Fedora uses as contact point a
  list of the most recent N committers to any given package. Which
  sounds like a great solution. ]

Cheers.
-- 
Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[toc] | [prev] | [next] | [standalone]

#8952

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> So my question here is: why would someone who has learned to work
> amicably *within* the boundaries of several teams, will behave any
> different *across* those boundaries, when contributing to packages that
> belong to other teams? I think the behavior will be the same. So, if we
> go down this path, I'm not sure why we should stop at teams, instead of
> just having the de facto equivalent of "Maintainer: Debian" for all
> packages.

There is a big difference between a small(ish) team where you can
build and then rely on personal relationships, and the whole of
Debian, where that is much more difficult.

Also there are practical problems.  Different people have different
ideas about source code layout, preferred build system, vcs workflow,
and so on.  These questions don't have unambiguously right answers and
are largely matters of taste.  On the other hand they are very much in
your face when doing practical work.  Without the benefit of a clear
authority who can make these decisions, we would risk spending too
much time debating them.  (I think that we have too much difference in
workflows etc., but I don't think we want to try to force everyone
into a single way of doing things.)

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8954

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, December 07, 2016 11:21:23 AM Stefano Zacchiroli wrote:
> On Tue, Dec 06, 2016 at 02:29:13PM +0000, Ian Jackson wrote:
> > Can we come up with some way whereby the maintainership authority is
> > always shared, somehow ?
> 
> The net result of this would be that anyone who maintains packages in
> Debian will do so as part of a team. Likely, people maintaining more
> than one package will end up being part of several teams.
> 
> In such a hypothetical world you seem to be persuaded that, within all
> those teams, people will generally learn to work together amicably and
> find ways to avoid stepping on each other toes. This definitely matches
> my teamwork experience in Debian --- Sometimes you, as a team member,
> are confident you're doing the right thing, and will just go ahead and
> make a change. Sometimes you'll have doubts and ask before acting.
> Sometimes you'll screw things up, and either you'll clean up after
> yourself or someone else will do so for you (when this happens, cursing
> will be involved).
> 
> So my question here is: why would someone who has learned to work
> amicably *within* the boundaries of several teams, will behave any
> different *across* those boundaries, when contributing to packages that
> belong to other teams? I think the behavior will be the same. So, if we
> go down this path, I'm not sure why we should stop at teams, instead of
> just having the de facto equivalent of "Maintainer: Debian" for all
> packages.
> 
> *Of course* there will be conflicts, but it is absolutely not clear to
> me why they would be any worse, or any more frequent, than the conflicts
> we have today within (potentially very large) teams.
> 
> [ As a caveat: the "Maintainer" field currently acts as both a contact
>   point for a given package, and as "fences" separating who is allowed
>   to contribute without asking for permission and who should ask first.
>   I'm advocating only against the latter meaning, not the former. But
>   the former can be implemented in other ways. For instance, Nicolas
>   Dandrimont pointed me to the fact that Fedora uses as contact point a
>   list of the most recent N committers to any given package. Which
>   sounds like a great solution. ]

I feel a personal sense of responsibility towards the packages where I appear 
as Maintainer or in Uploaders.  In my mind, adding myself there represents 
both authority to make decisions and responsibilities.  

Take that away and I do believe I'll feel less responsible and less motivated.

For packages maintained by myself or in ~small teams, things like work flow 
and tools are tractable in a way they aren't for the project as a whole.

While our current system has disadvantages, I have yet to see a better 
alternative proposed.

Scott K

[toc] | [prev] | [next] | [standalone]

#8955

[Scott Kitterman, 2016-12-08]
> I feel a personal sense of responsibility towards the packages where I appear 
> as Maintainer or in Uploaders.  In my mind, adding myself there represents 
> both authority to make decisions and responsibilities.  
> 
> Take that away and I do believe I'll feel less responsible and less motivated.
> 
> For packages maintained by myself or in ~small teams, things like work flow 
> and tools are tractable in a way they aren't for the project as a whole.
> 
> While our current system has disadvantages, I have yet to see a better 
> alternative proposed.

+1

(/me will orphan all of his packages if Debian decides they're not his
anymore)
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#8953 — Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers)

On Thu, 2016-12-01 at 19:20:36 +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
> 
> This is the obviously right solution.

It is not only not obviously right to me, instead it seems obvious
it carries a set of different problems with it. I feel this carries
so many assumptions of how the proposers feel about how *they* work
or might like to work and ignores how *others* do that. :/

If Debian was operated by a hive-mind, this would be the obvious
solution. But Debian is not (and it should not become a hive-mind IMO),
instead its distributed, independent and diverse nature is one of its
greatest strengths. In addition Debian is in great part a volunteer
based project. The dynamics on a volunteer vs a paid environment can
be entirely different (they are for me, there are things I'm willing
to do or scenarios I'm willing to accept/tolerate on paid-basis, I'd
never do on a volunteer one).

Few problems that come to mind on a fully maintainerless project:

* Encourages one-off upload-and-forget for dependencies of stuff one
  might want to package.
* More difficult to track (in and outside of Debian) if there is
  supposedly someone taking care of those package (would require
  accessing subscribers from the PTS or tracker or similar?). Is
  someone supposedly taking care of orphaned packages? Well perhaps,
  no one know until there's an upload. Is someone maintaining a
  maintained packages, in the normal case, yes.
* No one will have a "vision" of where each of those packages is or
  should go? Will this vision need to be agreed by the whole project?
  For each package!?
* Assumes stable and interpersonal relationships with upstreams are
  perhaps not important? Everytime someone different might contact
  upstream with a different style, etc?
* Assumes that everyone enjoys working with the same tools, with the
  same workflows: what about cdbs vs dh vs dehelper, git vs the rest,
  VCS layouts (debian-only, full-upstream, pristine-tar), source format
  1.0 vs 3.0, etc, etc. (f.ex. there are several VCSs, source layouts,
  helpers, etc. I'm so uncomfortable working with, to the point I just
  don't feel like co-maintaining packages using those, or join teams
  that have those as their team policy).
* Assumes everyone is pulling Debian in the same direction, and that
  there are never potentially opposite goals (at least initially).
* Assumes everyone can work with everyone else on a close and personal
  level (f.ex. I'll accept technical contributions from anyone based
  on the merits of those contributions, but there are people I'd rather
  not have to work with closely).
* Assumes an extrovert worldview. Sole-maintainership is not necessarily
  about control, authority and power (inbalanace!?) it can also be a
  sanctuary of tranquility, having to coordinate with a team or the whole
  project can imply an additional overhead and energy toll for introverts,
  in addition to the required coordination and interactions we are
  supposed to carry on as normal duty towards others and the project.
  Or it can be a space of freedom where one can do (within the
  distro-wide technical and socual rules and policies) anything one
  can imagine.
* Assumes everyone has the same personal packaging policies and
  commitment of effort. For example whether to strive for 0-divergence
  against upstream, or whether to patch upstream with no remorse
  whenever it seems needed. (I'm on the latter camp, but I'd never
  impose that vision on people on the first camp, because that would
  imply I'm deciding on a work committment for them).
* Assumes everyone perceives and feels their time and effort involvement
  on tasks in the same way. While the motivations and rewards are so
  subtle and diverse, probably as the number of people we have involved.
* With less and less people checking central development communication
  channels, many global distribution-wide changes have no way to be
  considered by the majority of affected people. While being able to
  do distro-wide changes, in say, a mass upload, might be very
  convenient, having independent maintainers that *know* the details
  of the packages they maintain means there are more sanity checks in
  place, and that you need to convince people your ideas are correct.
* Could discourage experimentation, using new tools, helpers, techniques,
  workflows, because it might interfere with others wanting to work
  also on those packages (it would go against the hive-mind!).

I've worked on teams or group efforts that are great, with great peers
that I resonate with on an interpersonal level, where I might or might
not agree on the technical level, but technical discussions are still
very much enjoyable. I've also worked on teams that were such an
energy drain that they were very unpleasant to work in.

I think all of sole-maintainership, team maintainership, and even
maintainerless packages have their own merits and their own drawbacks.
Stating otherwise seems like an overly simplistic and naive view of how
projects of this size and how human interaction works, TBH.

If people want to go for any of them, they should! For maintainerless
we already have QA maintained packages, if that's not good enough just
create a new address or whatever and put it in the Maintainer field. But
the continuous messages that get through on the mailing lists that seem
to keep demonizing contributors that do not participate in
team-maintainer efforts are a bit tiresome and disrespectful.

Because, didn't we have a vote on diversity or something…?

Regards,
Guillem

[toc] | [prev] | [next] | [standalone]

#8960 — Re: Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers)

On Thu, 08 Dec 2016, Guillem Jover wrote:
> It is not only not obviously right to me, instead it seems obvious
> it carries a set of different problems with it. I feel this carries
> so many assumptions of how the proposers feel about how *they* work
> or might like to work and ignores how *others* do that. :/

I don't think that entirely abolishing maintainership is a good move.
But we should change our process so that by default we have no hard
lockin on most packages.

For packages where the persons doing the work have special requirements,
they should document those requirements in debian/README.maintainers (or
README.contributors).

In that file they could:
- ask to review changes prior to upload (and give some delay in which
  they usually respond)
- define some package-policy to follow (conventions, procedures)
- document upstream related things that are good to know
- explain their plan for the next upstream release wrt to Debian's release
- etc.

Team maintained packages could just add a pointer to the team policy.

With such a system, it makes sense to drop the Maintainer/Uploaders from
the package and have it dynamically generated from persons actually
working on the package.

We don't need a sole maintainer to make decisions, everyone is entitled to
make decisions provided that they follow the rules defined by the active
maintainers. And rules can be changed through discussion between active
contributors when reaching a consensus...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#8905

[Multipart message — attachments visible in raw view] — view raw

Le jeudi, 1 décembre 2016, 15.46:05 h CET Ian Jackson a écrit :
> There is a recent case where:
>  * The maintainer has done nothing to the package for many years,
>    other than infrequent (and usually short) emails to NAK
>    contributions from others;
>  * The package is years out of date compared to upstream, afflicted by
>    bitrot, and many users are asking for the new version;
>  * Several times, proposed updates have been prepared by contributors
>    but blocked by the maintainer;
>  * There are new maintainers ready and waiting, with a new package
>    ready for upload to sid for stretch;
>  * Now that the TC is involved the maintainer has written many emails
>    explaining their decisions to NAK uploads, but TC members are
>    clearly unconvinced on a technical level that those decisions were
>    right.
> Even in this extreme situation the TC has not seen fit to wrest the
> package away from the mainainer's deathgrip.

I think you're really jumping the gun here. While the TC is not known for 
acting rapidly, I (would like to) think it is becoming better. In the "recent 
case" you're using as trigger to this very discussion [0], although some TC 
members have already expressed opinions (mostly both ways, I feel), the TC 
hasn't taken a decision yet. It therefore feels quite premature to launch a 
"Replace the TC power to depose maintainers" discussion.

By launching the discussion through assuming the TC will not decide how you 
think is most fit, you are exercising unwarranted pressure on the TC members 
who will eventually need to take a decision.

You have been on the TC long enough to know how uneasy a TC members' job can 
be; what about letting those are now in charge with some room ?

    OdyX

[0] #841294, for those not following the tech-ctte pseudo-bug or the debian-
ctte@l.d.o list

[toc] | [prev] | [next] | [standalone]

#8906

Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
> I still don't understand why the TC is so crushingly slow to conter
> maintainer power in Debian.  As I say in my other emails, a result of
> the TC's inaction, maintainer power in Debian is nearly unassailable.

Didier, and Phil, now you're in this conversation: can you explain
this to me ?

I have a number of theories.  Mayber TC members are reluctant to make
_any_ decision for fear of making a mistake.  Maybe TC members are
reluctant to act without consensus.  Maybe TC members are reluctant to
upset maintainers.  Maybe TC members are uncomfortable, as technical
people, exercising hard power, and prefer to persuade.  Maybe
something else, which I don't understand.

If I understood _why_ TC members (other than me) behaved this way, it
might be possible to frame a GR where the whole project could indicate
whether they think this is right or wrong.

If I put forward such a GR and lose it, at least I'll know where I
stand.  There is no point me trying to push this years-long campaign
to weaken Debian maintainership (originally, by getting the TC to use
its power, but that doesn't seem to be getting much more likely) if
the rest of the project thinks that it is just fine that our
maintainers are almost completely unaccountable.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8914

[Multipart message — attachments visible in raw view] — view raw

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
>> I still don't understand why the TC is so crushingly slow to conter
>> maintainer power in Debian.  As I say in my other emails, a result of
>> the TC's inaction, maintainer power in Debian is nearly unassailable.
>
> Didier, and Phil, now you're in this conversation: can you explain
> this to me ?

I just replied to another of your mails -- in a mail started fairly soon
after you mail, and only just finished because my wife is in bed with a
temperature, both kids are coughing and spluttering, and I too have a
cold, so time's been a bit short today.

Hopefully my reply doesn't seem too much out of sequence -- I've not
been attempting to follow subsequent discussion until I got it sent.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[toc] | [prev] | [next] | [standalone]

#8907

Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> I think you're really jumping the gun here. While the TC is not
> known for acting rapidly, I (would like to) think it is becoming
> better. In the "recent case" you're using as trigger to this very
> discussion [0], although some TC members have already expressed
> opinions (mostly both ways, I feel), the TC hasn't taken a decision
> yet. It therefore feels quite premature to launch a "Replace the TC
> power to depose maintainers" discussion.

The bug was filed on the 19th of October.  That was nearly 7 weeks
ago.

That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
weeks during which members of the TC have been prevaricating.


As I wrote in my message to Phil earlier today:

  ISTM that in the current argument, the TC has given the position of
  the existing maintainer great weight.

  Imagine the roles were replaced.  Imagine the actual petitioners (P
  and W, for the same of argument) were the current maintainers, and the
  actual current maintainer (R) were a petitioner saying "please make me
  the maintainer".  Would the TC would spend months debating before
  dismissing such a manifestly unfounded petition ?

It takes very little time to review the history of this package and
conclude that, regardless of the technical merits of the new upstream:
 - the work put in both others over the past years, and blocked
    by the maintainer, far outweighs that put in by the maintainer
 - the maintainer has failed to communicate adequately
 - the maintainer has failed completely in their leadership role
 - in fact the maintainer has done /nothing/ but produce stop-energy

As I say, if P and W were already the maintainer, the TC would surely
have not blocked P and W from uploading the new version for weeks
while they carefully considered whether R might have a point about the
defects of the new upstream version.

> You have been on the TC long enough to know how uneasy a TC members' job can 
> be; what about letting those are now in charge with some room ?

I have been on the TC long enough to become incredibly frustrated with
the longstanding failure of the TC to challenge the unaccountable
authority of Debian maintainers.

Leaving aside the init systems discussion, I have always found that my
primary emotional difficulty as a TC member has been my
incomprehension at my colleagues' lack of gumption.


Over the years, I have tried calm reasoning; I have tried flowery
rhetoric; I have tried private emails; I have had numerous private
IRL conversations.

I still don't understand why the TC is so crushingly slow to conter
maintainer power in Debian.  As I say in my other emails, a result of
the TC's inaction, maintainer power in Debian is nearly unassailable.


Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8908

Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> The bug was filed on the 19th of October.  That was nearly 7 weeks
> ago.

Sure. I'm not saying the TC couldn't be better.

> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.

I agree with that.

> 6+ weeks during which members of the TC have been prevaricating.

I had to lookup prevaricate in a dictionary:
> to speak falsely or misleadingly; deliberately misstate or create an
> incorrect impression
> to deviate from the truth

This is not helping, really. Please tone down.

Frankly, with the timing, content and tone of your meta-interventions around 
the "recent case" we're talking about, you have just added two more weeks to 
the process. I now took some time to address these meta-concerns, while I 
could have have focused on gathering commitments from the actual and 
prospective maintainers of src:global instead, and drafted a ballot.

    OdyX

[toc] | [prev] | [next] | [standalone]

#8910

Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > 6+ weeks during which members of the TC have been prevaricating.
> 
> I had to lookup prevaricate in a dictionary:
> > to speak falsely or misleadingly; deliberately misstate or create an
> > incorrect impression
> > to deviate from the truth
> 
> This is not helping, really. Please tone down.

That's not what meant by "prevaricate".  I asked #chiark about the
meaning of the word and they said:

17:34 <Diziet> What does the channel think "prevaricate" means ?

17:34 <X> to put off, possibly while pretending not to

17:35 <Z> avoid a decision or question
17:35 <Z> "we'll tell you later"

17:35 <A> like procrastination but for speech

17:35 <B> to waver over a decision and postpone making it.

I certainly didn't mean to suggest dishonesty.  Apologies for the
offence.

> Frankly, with the timing, content and tone of your meta-interventions around 
> the "recent case" we're talking about, you have just added two more weeks to 
> the process. I now took some time to address these meta-concerns, while I 
> could have have focused on gathering commitments from the actual and 
> prospective maintainers of src:global instead, and drafted a ballot.

The decision to give the package to the prospective new maintainers
could and should have been made 4 weeks ago.  It's a complete
no-brainer.

The easy way to address my meta-concerns would have been to
demonstrate them wrong!  (Or at least to quickly rob me of this
absolutely excellent example.)

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8920

]] Ian Jackson 

> Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> > Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > > 6+ weeks during which members of the TC have been prevaricating.
> > 
> > I had to lookup prevaricate in a dictionary:
> > > to speak falsely or misleadingly; deliberately misstate or create an
> > > incorrect impression
> > > to deviate from the truth
> > 
> > This is not helping, really. Please tone down.
> 
> That's not what meant by "prevaricate".  I asked #chiark about the
> meaning of the word and they said:

They might want to consult a dictionary then,
http://www.dictionary.com/browse/prevaricate:

  verb (used without object), prevaricated, prevaricating.

  1. to speak falsely or misleadingly; deliberately misstate or create
  an incorrect impression; lie.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#8924

Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> They might want to consult a dictionary then,

I.

Chambers English Dictionary (1994 edition, which is what I have):

 prevaricate (vi)
   to avoid stating the truth or coming directly to the point;
   to quibble.

  [And a bunch of other meanings labelled `(obs)'.]

II.

You're a linguistic prescriptivist ?

III.

Anyway, I have explained what I meant.  I apologise for giving offence
by using a word that American dictionaries think means something much
more critical than I intended.


-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#8918

]] Ian Jackson 

> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
> weeks during which members of the TC have been prevaricating.

What are you accusing the TC of lying about?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#8921

[Multipart message — attachments visible in raw view] — view raw

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Ian Jackson 
>
>> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
>> weeks during which members of the TC have been prevaricating.
>
> What are you accusing the TC of lying about?

I think that British English has drifted into using that as a synonym
for procrastinate while American English seems to have stuck to its
earlier meaning (judging by the online dictionary entries I see).

I certainly didn't (and still wouldn't) assume that Ian was accusing
anyone of lying here.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[toc] | [prev] | [next] | [standalone]

#8922

]] Philip Hands 

> Tollef Fog Heen <tfheen@err.no> writes:
> 
> > ]] Ian Jackson 
> >
> >> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
> >> weeks during which members of the TC have been prevaricating.
> >
> > What are you accusing the TC of lying about?
> 
> I think that British English has drifted into using that as a synonym
> for procrastinate while American English seems to have stuck to its
> earlier meaning (judging by the online dictionary entries I see).

That doesn't match the reading of the Cambridge dictionary:
http://dictionary.cambridge.org/dictionary/english/prevaricate

  prevaricate
  verb [ I ] UK ​ /prɪˈvær.ɪ.keɪt/ US ​ /prɪˈver.ə.keɪt/ formal
​
  to avoid telling the truth or saying exactly what you think:

Or the Oxford dictionary,
https://en.oxforddictionaries.com/definition/prevaricate:

  prevaricate
  VERB

  [NO OBJECT]
  Speak or act in an evasive way:

> I certainly didn't (and still wouldn't) assume that Ian was accusing
> anyone of lying here.

Given his later apology, I'd assume so as well, but as a native speaker
of English, Ian should really know better than using the term in the
first place.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#8923

[Multipart message — attachments visible in raw view] — view raw

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Philip Hands 
>
>> Tollef Fog Heen <tfheen@err.no> writes:
>> 
>> > ]] Ian Jackson 
>> >
>> >> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
>> >> weeks during which members of the TC have been prevaricating.
>> >
>> > What are you accusing the TC of lying about?
>> 
>> I think that British English has drifted into using that as a synonym
>> for procrastinate while American English seems to have stuck to its
>> earlier meaning (judging by the online dictionary entries I see).
>
> That doesn't match the reading of the Cambridge dictionary:
> http://dictionary.cambridge.org/dictionary/english/prevaricate
>
>   prevaricate
>   verb [ I ] UK ​ /prɪˈvær.ɪ.keɪt/ US ​ /prɪˈver.ə.keɪt/ formal
> ​
>   to avoid telling the truth or saying exactly what you think:
>
> Or the Oxford dictionary,
> https://en.oxforddictionaries.com/definition/prevaricate:
>
>   prevaricate
>   VERB
>
>   [NO OBJECT]
>   Speak or act in an evasive way:
>
>> I certainly didn't (and still wouldn't) assume that Ian was accusing
>> anyone of lying here.
>
> Given his later apology, I'd assume so as well, but as a native speaker
> of English, Ian should really know better than using the term in the
> first place.

Jolly interesting.

It looks like I'll have to add the misuse of that to my list of pedantic
pet hates, which is currently topped by 'epicentre' and 'decimate' ;-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[toc] | [prev] | [next] | [standalone]

#8928

On 2016-12-05 20:57, Philip Hands wrote:
> Tollef Fog Heen <tfheen@err.no> writes:

>> ]] Ian Jackson 
>>> That is 6+ weeks' more stop-energy.  6+ weeks' more inaction.  6+
>>> weeks during which members of the TC have been prevaricating.

>> What are you accusing the TC of lying about?

> I think that British English has drifted into using that as a synonym
> for procrastinate while American English seems to have stuck to its
> earlier meaning (judging by the online dictionary entries I see).

There has evidently been drift in both languages.


The current full Oxford English Dictionary lists only two senses (when
used as an intransitive verb) as non-obsolete:

a. To deviate from straightforwardness; to speak or act in an evasive
way; to quibble, equivocate.
(with citations back to 1623)

b. To behave evasively or indecisively so as to delay action; to
procrastinate.
(with citations back to 1854)

It says that the second is "now the usual sense".


I can find some American dictionaries which strengthen sense 'a' to
include "deliberately mislead" or even "lie", but that is not standard
British usage.

-M-

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | linux.debian.project

csiph-web