Re: Bug#799748: ITP: ember -- 3D client framework for the WorldForge project

[Simon McVittie]

On 22/09/15 06:22, Olek Wojnar wrote:
> This package is being reintroduced into Debian. It was previously maintained
> by the Games Team and will continue to be maintained that way. It was removed 
> by Bugs #797418, #563768, #682332, #760058 due to the GCC 5 transition. The
> problems that caused it to be removed will be corrected before it is uploaded
> again.

After those problems have been corrected, will you continue to maintain
ember and the rest of the WorldForge-related packages in the longer
term, and ensure that they do not become a burden to other developers? I
ask because in the 16 years that ember was in the archive, it had a
total of 7 uploads, of which 2 NMUs and at least 3 maintainer uploads
were to fix release-critical bugs. That isn't a particularly good ratio
of maintainer's time used : other people's time used.

This is not intended as a veto - hopefully you'll have more time for it
than its previous maintainers - but I felt that before it is
reintroduced, I should specifically point out that every time a package
fails to build from source or is otherwise RC-buggy, and every time it
blocks a transition, it is creating work for people other than its
maintainer.

While team maintenance is of course A Good Thing, I'm not sure that
having "the games team" as a co-maintainer mitigates this very much; the
wide range of game technologies and styles maintained by that team mean
that it is relatively unlikely that a random games-team member knows how
to fix and test a random games-team package (or indeed has any interest
in that random package).

Based on the history of ember and its dependencies, it seems fairly
likely that developers with an interest in the archive as a whole (QA
team, release team, ftpmasters) will respond to any RC bugs that aren't
fixed promptly by just removing it again.

S

Bug#799759: RFH: freerdp -- RDP client for Windows Terminal Services (X11 client)

[Mike Gabriel]

Package: wnpp
Severity: normal

It would be beneficial to the freerdp package in Debian to have more
people than me (i.e., just one person) involved in the package
maintenance.

The FreeRDP package currently is a low-prio package to me because:

  o I only rarely use it (more interested in Linux-based remote
desktops)
  o I have other packages with higher prio at the moment

Nonetheless, I am still interested in co-maintaining FreeRDP, because I
am quite involved in remote desktop / applications solutions for Linux
(also as upstream dev -> X2Go, Arctica Project).

light+love,
Mike

The package description is:
 FreeRDP is a libre client/server implementation of the Remote
 Desktop Protocol (RDP).
 .
 Currently, the FreeRDP client supports the following Windows Versions:
 .
  * Windows NT Server
  * Windows 2000 Terminal Server
  * Windows XP
  * Windows 2003 Server
  * Windows Vista
  * Windows 2008/2008r2/2011SBS Server
  * Windows 7
  * Windows 2012 Server
  * Windows 8
 .
 This package contains the X11 based client.

Re: DAK Commands for Bikesheds

[Tzafrir Cohen]

On Fri, Sep 18, 2015 at 06:41:53PM +0200, Jakub Wilk wrote:
> * Joerg Jaspert , 2015-09-17, 13:42:
> >I defined the possible commands for the upcoming bikeshed feature,
> 
> It's the first time I hear about the "bikeshed feature". Perhaps you should
> explain the term first.
> 
> (Believe it or not, most debian-devel readers were not at DebConf.)

The name was used in the following talk:

https://summit.debconf.org/debconf15/meeting/231/ppas-whats-next/

It has a link to the video of the talk.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Re: binNMU or reproducible builds (choose only one)

[Thorsten Glaser]

Wouter Verhelst  debian.org> writes:

> Everything needed to remedy that would be to not do so, and include the
> source to a binNMU with its upload instead.

No. The entire delta between the source in the archive and
the .deb generated from a binNMU upload is contained in the
.changes file as well, so it’s already there and just needs
to be extracted.

bye,
//mirabilos

promoting virtualbox-dkms to virtualbox pre-depends

[Gianfranco Costamagna]

As shown in policy 7.2

"You should not specify a Pre-Depends entry for a package before this has been 
discussed on the debian-devel mailing
list and a consensus about doing that has been reached. See Dependencies, 
Section 3.5."

the problem actually is that virtualbox-dkms should be configured *before* 
configuring virtualbox, otherwise
without a built kernel module, restarting VMs
will fail and lead to an half-configured package.

Please see bugs #798527 and #798979 as examples.

(this is a subpackage depending on another subpackage that belongs to the same 
src, I don't get why I should discuss such internal
changes, but well, policy is policy)



cheers,

Gianfranco

Re: promoting virtualbox-dkms to virtualbox pre-depends

[James Cowgill]

Hi,

On Tue, 2015-09-22 at 15:00 +, Gianfranco Costamagna wrote:
> As shown in policy 7.2
> 
> "You should not specify a Pre-Depends entry for a package before this
> has been discussed on the debian-devel mailing
> list and a consensus about doing that has been reached. See
> Dependencies, Section 3.5."
> 
> the problem actually is that virtualbox-dkms should be configured
> *before* configuring virtualbox, otherwise
> without a built kernel module, restarting VMs
> will fail and lead to an half-configured package.
> 
> Please see bugs #798527 and #798979 as examples.

This should work with a normal Depends relation (reread Policy 7.2).

This commit helped since it prevented a circular dependency involving
the two packages:
https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=68f57408199e304df63285910a360bc2f6ae2372

So after that commit, a normal Depends from virtualbox to virtualbox
-dkms should be all that's nessesary.

Thanks,
James

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

Re: promoting virtualbox-dkms to virtualbox pre-depends

[James Cowgill]

Hi,

On Tue, 2015-09-22 at 16:40 +, Gianfranco Costamagna wrote:
> Hi  James!
> 
> > This should work with a normal Depends relation (reread Policy 7.2).
> > 
> > This commit helped since it prevented a circular dependency involving
> > the two packages:
> > https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=68f57408199e304df63285910a360bc2f6ae2372
> > 
> > So after that commit, a normal Depends from virtualbox to virtualbox
> > -dkms should be all that's nessesary.
> 
> thanks for the useful pointer, I admit I get headache when I have to deal 
> with such things :)
> 
> however, according to the debdiff of the fix:
[...]
> prior the virtualbox-dkms | virtualbox-source was in Recommends, not in 
> Depends.
> 
> was it really a circular dependency?

No sorry I meant that if you had added a normal Depends without the
above commit, you would have created a circular dependency.

Before these changes, the dependency from virtualbox-dkms to virtualbox
was causing virtualbox to always be configured first.

James

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

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Gianfranco Costamagna]

Hi  James!


>This should work with a normal Depends relation (reread Policy 7.2).
>
>This commit helped since it prevented a circular dependency involving
>the two packages:
>https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=68f57408199e304df63285910a360bc2f6ae2372
>
>So after that commit, a normal Depends from virtualbox to virtualbox
>-dkms should be all that's nessesary.



thanks for the useful pointer, I admit I get headache when I have to deal with 
such things :)

however, according to the debdiff of the fix:
@@ -87,11 +87,9 @@


Package: virtualbox
Architecture: amd64 i386
-Pre-Depends: dpkg (>= 1.15.6~)
+Pre-Depends: dpkg (>= 1.15.6~), virtualbox-dkms (= ${source:Version}) | 
virtualbox-source (= ${source:Version})
Depends: adduser, ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Recommends: virtualbox-dkms (= ${source:Version}) | virtualbox-source (= 
${source:Version}),
-virtualbox-qt (= ${binary:Version}),
-${shlibs:Recommends}
+Recommends: virtualbox-qt (= ${binary:Version}), ${shlibs:Recommends}
Suggests: vde2, virtualbox-guest-additions-iso
Conflicts: virtualbox-2.0,
virtualbox-2.1,
@@ -132,7 +130,8 @@
Section: contrib/kernel
Architecture: all
Pre-Depends: dpkg (>= 1.15.6~)
-Depends: virtualbox (>= ${source:Version}), ${misc:Depends}
+Depends: ${misc:Depends}
+Recommends: virtualbox (>= ${source:Version})
Description: x86 virtualization solution - kernel module sources for dkms
VirtualBox is a free x86 virtualization solution allowing a wide range
of x86 operating systems such as Windows, DOS, BSD or Linux to run on a


prior the virtualbox-dkms | virtualbox-source was in Recommends, not in Depends.

was it really a circular dependency?

Now the package works, so I would like to avoid breaking it again :)

cheers,

Gianfranco

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Sune Vuorela]

On 2015-09-22, Gianfranco Costamagna  wrote:
> -Pre-Depends: dpkg (>= 1.15.6~)
> +Pre-Depends: dpkg (>= 1.15.6~), virtualbox-dkms (= ${source:Version}) | 
> virtualbox-source (= ${source:Version})

I don't see what it would fix to have virtualbox-source installed at any
point help in anything.

And note that one can run kernels that doesn't do dkms.

/Sune

Bug#799798: ITP: golang-github-xordataexchange-crypt -- Store and retrieve encrypted configs from etcd or Consul

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-xordataexchange-crypt
  Version : 0.0.2+git20150523.17.749e360-1
  Upstream Author : XOR Data Exchange, Inc.
* URL : https://github.com/xordataexchange/crypt
* License : MIT
  Programming Lang: Go
  Description : Store and retrieve encrypted configs from etcd or Consul

 "crypt" by XOR Data Exchange Inc. is both a stand-alone command-line tool
 and a Go library that can be used to store and retrieve encrypted configs
 from etcd or Consul.
 .
 It uses user-provided application-specific GPG keyring pairs for encryption
 and decryption.

Reason for packaging:
 "github.com/xordataexchange/crypt" is needed by
 "github.com/spf13/viper" (Go configuration with fangs), which is needed by
 "github.com/spf13/hugo" Hugo the static website generator.

To be maintained within the pkg-go team.

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Julien Cristau]

On Tue, Sep 22, 2015 at 15:00:35 +, Gianfranco Costamagna wrote:

> As shown in policy 7.2
> 
> "You should not specify a Pre-Depends entry for a package before this has 
> been discussed on the debian-devel mailing
> list and a consensus about doing that has been reached. See Dependencies, 
> Section 3.5."
> 
> the problem actually is that virtualbox-dkms should be configured *before* 
> configuring virtualbox, otherwise
> without a built kernel module, restarting VMs
> will fail and lead to an half-configured package.
> 
> Please see bugs #798527 and #798979 as examples.
> 
> (this is a subpackage depending on another subpackage that belongs to the 
> same src, I don't get why I should discuss such internal
> changes, but well, policy is policy)
> 
A pre-depends is very much the wrong hammer here, userspace can't
usefully rely on a kernel package or module through package
dependencies.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: DAK Commands for Bikesheds

[Julien Cristau]

On Tue, Sep 22, 2015 at 10:58:15 +0200, Tzafrir Cohen wrote:

> On Fri, Sep 18, 2015 at 06:41:53PM +0200, Jakub Wilk wrote:
> > * Joerg Jaspert , 2015-09-17, 13:42:
> > >I defined the possible commands for the upcoming bikeshed feature,
> > 
> > It's the first time I hear about the "bikeshed feature". Perhaps you should
> > explain the term first.
> > 
> > (Believe it or not, most debian-devel readers were not at DebConf.)
> 
> The name was used in the following talk:
> 
> https://summit.debconf.org/debconf15/meeting/231/ppas-whats-next/
> 
> It has a link to the video of the talk.
> 
The name was also used on this list a while ago,
https://lists.debian.org/518b7cf6.3080...@debian.org

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#799748: ITP: ember -- 3D client framework for the WorldForge project

[Tobias Frost]

Am Dienstag, den 22.09.2015, 08:19 +0100 schrieb Simon McVittie:
> On 22/09/15 06:22, Olek Wojnar wrote:
> > This package is being reintroduced into Debian. It was previously 
> > maintained
> > by the Games Team and will continue to be maintained that way. It 
> > was removed 
> > by Bugs #797418, #563768, #682332, #760058 due to the GCC 5 
> > transition. The
> > problems that caused it to be removed will be corrected before it 
> > is uploaded
> > again.
> 
> After those problems have been corrected, will you continue to 
> maintain
> ember and the rest of the WorldForge-related packages in the longer
> term, and ensure that they do not become a burden to other 
> developers? I
> ask because in the 16 years that ember was in the archive, it had a
> total of 7 uploads, of which 2 NMUs and at least 3 maintainer uploads
> were to fix release-critical bugs. That isn't a particularly good 
> ratio
> of maintainer's time used : other people's time used.
> 
> This is not intended as a veto - hopefully you'll have more time for 
> it
> than its previous maintainers - but I felt that before it is
> reintroduced, I should specifically point out that every time a 
> package
> fails to build from source or is otherwise RC-buggy, and every time 
> it
> blocks a transition, it is creating work for people other than its
> maintainer.
> 
> While team maintenance is of course A Good Thing, I'm not sure that
> having "the games team" as a co-maintainer mitigates this very much; 
> the
> wide range of game technologies and styles maintained by that team 
> mean
> that it is relatively unlikely that a random games-team member knows 
> how
> to fix and test a random games-team package (or indeed has any 
> interest
> in that random package).
> 
> Based on the history of ember and its dependencies, it seems fairly
> likely that developers with an interest in the archive as a whole (QA
> team, release team, ftpmasters) will respond to any RC bugs that 
> aren't
> fixed promptly by just removing it again.
> 
> S
> 

Hi Simon,

Maybe I chime in.. 
I'm in contact with Olek since a while regarding the ecosystem around
ember and the wf libraries. I also volunteered to sponsor his work and
the first uploads are currently being prepared.

Yes, the former maintainer was, lets say, problematic, a kind of 51th
shade of MIA. (Responding to pings, promising actions soon, but in the
end nothing happened) This was the main blocker here and Olek didn't
want to offend the maintainer, despite that the packages were de-facto
unmaintained. 
So this is the right point of time to get those packages a good
restart, with Olek as maintainer, even if I see another 51th-shade of
MIA in the way -- down the road. (Therefore I would be interested in
general guidance how to handle such pseudo-MIA or selective-MIA: Cases
where the maintainer is active, but still nothing happens at least on
certain packages, even after prodding.)

I'm confident that Olek will maintain the packages adequately.
If not, removal bugs can still be filed, but I prefer to give him the
opportunity to show. 

--
tobi

Re: ITP: libnss-docker -- nss module for finding Docker containers

[Piotr Roszatycki]

* Package name: libnss-docker
  Version : 0.1-1
  Upstream Author : Piotr Roszatycki 
* URL : *https://github.com/dex4er/nss-docker
*
* License : LGPL
  Programming Lang: C
  Description : nss module for finding Docker containers

I'm switching to https://github.com/dex4er/nss-docker so this is updated
meta information about package.

Yes, now the upstream is also by myself.

New upstream source is LGPL so now it is legally to link it with non-GPL
code. Another change is that this module does not depend on libglib and
connects to Docker API server directly by socket and not via
/usr/bin/docker command. Also autotools are used rather than simple
Makefile. The unit testing requires root privileges and modified
/etc/nsswitch.conf so probably won't be used in Debian package.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:piotr.roszaty...@gmail.com
`. `' mailto:dex...@debian.org
  `-

Bug#799812: ITP: golang-github-yosssi-gohtml -- HTML formatter for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-yosssi-gohtml
  Version : 0.0~git20141007.0.48cbef8-1
  Upstream Author : Keiji Yoshida
* URL : https://github.com/yosssi/gohtml
* License : MIT
  Programming Lang: Go
  Description : HTML formatter for Go

 GoHTML is an HTML formatter for Go.  You can format HTML source codes
 by using this package.
 .
 Documentation is available at https://godoc.org/github.com/yosssi/gohtml

Reason for packaging:
 "github.com/yosssi/gohtml" is needed by
 "github.com/yosssi/ace", which is needed by
 "github.com/spf13/hugo", i.e. Hugo the static website generator.

To be maintained within the pkg-go team.

Bug#799815: ITP: golang-github-yosssi-ace -- HTML template engine for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-yosssi-ace
  Version : 0.0.4+git20150515.41.78e48a2-1
  Upstream Author : Keiji Yoshida
* URL : https://github.com/yosssi/ace
* License : MIT
  Programming Lang: Go
  Description : HTML template engine for Go

 Ace is an HTML template engine for Go.  This is inspire by
 Slim (http://slim-lang.com/) and Jade (http://jade-lang.com/).
 This is a refinement of Gold (http://gold.yoss.si/).
 .
 Example:
 .
   ace = doctype html html lang=en
   head
 title Hello Ace = css
   h1 { color: blue; }
   body
 h1 {{.Msg}} #container.wrapper
   p..
 Ace is an HTML template engine for Go.
 This engine simplifies HTML coding in Go web application development.
 = javascript
   console.log('Welcome to Ace');

Reason for packaging:
 "github.com/yosssi/ace" is needed by
 "github.com/spf13/hugo", i.e. Hugo the static website generator.

To be maintained within the pkg-go team.

Bug#799816: ITP: golang-github-yosssi-ace-proxy -- Proxy for the Ace template engine (Go library)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-yosssi-ace-proxy
  Version : 0.0~git20141007.0.ecd9b78-1
  Upstream Author : Keiji Yoshida
* URL : https://github.com/yosssi/ace-proxy
* License : MIT
  Programming Lang: Go
  Description : Proxy for the Ace template engine (Go library)

 Ace Proxy is a proxy for the Ace template engine.  This proxy caches the
 options for the Ace template engine so that you don’t have to specify
 them every time calling the Ace APIs.

Reason for packaging:
 "github.com/yosssi/ace-proxy" is needed by
 "github.com/yosssi/ace", which is needed by
 "github.com/spf13/hugo", i.e. Hugo the static website generator.

To be maintained within the pkg-go team.

Re: DAK Commands for Bikesheds

[Wouter Verhelst]

On Fri, Sep 18, 2015 at 06:52:41PM +0200, Jakub Wilk wrote:
> * Robert Edmonds , 2015-09-17, 15:04:
> >Wookey wrote:
> [...]
> >>Bikeshed is an appropriate name, in the unix tradition of mildly
> >>amusing/punny names.
> >
> >Which tradition would that be?
> >
> >Out of the few hundred or so Unix [0] and GNU [1] commands listed on
> >Wikipedia, the only vaguely amusing/punning names I can find are tac
> >("cat" backwards) and pinky (a lightweight "finger").
> 
> "UNIX", "head", "tail", "kill", "nice", "finger", "bash", "less" are
> slightly humorous.

ITYM

unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; 
sleep

(yes, slightly inappropriate, but then again, maybe not)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: binNMU or reproducible builds (choose only one)

[Wouter Verhelst]

On Tue, Sep 22, 2015 at 12:22:28PM +, Thorsten Glaser wrote:
> Wouter Verhelst  debian.org> writes:
> 
> > Everything needed to remedy that would be to not do so, and include the
> > source to a binNMU with its upload instead.
> 
> No. The entire delta between the source in the archive and
> the .deb generated from a binNMU upload is contained in the
> .changes file as well, so it’s already there and just needs
> to be extracted.

Yes, but that would push complexity to the client side for no
particularly good reason.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#799830: ITP: dwgsim -- DWGSIM is an improved short read simulator

[Kevin Murray]

Package: wnpp
Severity: wishlist
Owner: Kevin Murray 

* Package name: dwgsim
  Version : 0.1.11
  Upstream Author : Nils Homer
* URL : https://github.com/nh13/DWGSIM
* License : GPLv2, MIT/X
  Programming Lang: C
  Description : DWGSIM: an improved short read simulator

DWGSIM is a whole-genome shotgun sequencing read simulator. It simulates
reads from Illuima, SOLiD and Ion Torrent platforms.

This package will be maintained by the Debian Med Packaging Team.

tyr-quake both quake1 & quakewolrd close to conservative engine stable-based

[PICCORO McKAY Lenz]

package: wnpp
severity: wishlist

  Version 0.62 (0.61+git)
  Upstream Author : Kevin Shanahan http://disenchant.net/about/
  URL : http://disenchant.net/tyrquake/
  License : GPLv2
  Description : Very conservative QuakeWorld and Quake1 engine

Very conservative engine that supports QuakeWorld and Quake1 both
client and server net, also quakeworld client and a server focused
too.

I have dsc files for packages on venenux close preliminary package,
that can be taken as started point removing the venenux patches that
only works for older debian versions (with --skip-patches)
here 
http://venenuxrepo.fundacite-aragua.gob.ve/mskcommon/games/quake1/tyrquake_0.61git0ca7766-1.dsc

the quakeworld provides was based on the older quakeworld packages
from upstream.

the quake1 provides are in syncwith quake engines in debian oficial.

i provide a previous bug whislist report about free data files
openquartz-plus tht also works with thi engine, providing a complete
free quake and quakeworld game (yes oq-plus provide qw too)

-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#799834: ITP: golang-github-opennota-urlesc -- Proper URL escaping as per RFC3986

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-opennota-urlesc
  Version : 0.0~git20150208.0.5fa9ff0-1
  Upstream Authors: The Go Authors, OpenNota
* URL : https://github.com/opennota/urlesc
* License : BSD-3-clause
  Programming Lang: Go
  Description : Proper URL escaping as per RFC3986 for Go

 Package urlesc implements query escaping as per RFC 3986
 for the Go Programming Language.
 .
 It contains some parts of the net/url package, modified so as to
 allow some reserved characters incorrectly escaped by net/url (see
 issue 5684 (https://github.com/golang/go/issues/5684)).

Reason for packaging:
 Needed by "github.com/PuerkitoBio/purell", which is needed by
 "github.com/spf13/hugo", i.e. Hugo the static website generator.

Note that Go1.5 has fixed its URL escaping to fully conform with RFC3986,
hence "github.com/opennota/urlesc" has finished its historic mission.
However, as @PuerkitoBio noted:

  Yeah, it is now fixed in Go1.5 but it's unlikely people will all
  upgrade that fast, so I'd be tempted to leave it in for a while,
  at least until Go1.6, maybe even another release after that.
  I think a conditional build tag could be used, I may take a look at
  that when I have a moment, so I'll leave that open.

-- from https://github.com/PuerkitoBio/purell/issues/14

so I think we should do the same with "github.com/opennota/urlesc"
and keep it around until Debian migrate to Go1.6 or even Go1.7.

To be maintained within the pkg-go team.

Re: Bug#799748: ITP: ember -- 3D client framework for the WorldForge project

[Olek Wojnar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Simon,

You bring up some very good points and those are very fair questions.

On 09/22/2015 12:45 PM, Tobias Frost wrote:
| Am Dienstag, den 22.09.2015, 08:19 +0100 schrieb Simon McVittie:
|> After those problems have been corrected, will you continue to
|> maintain
|> ember and the rest of the WorldForge-related packages in the longer
|> term, and ensure that they do not become a burden to other
|> developers? I

Yes, that is my intention.

|> ask because in the 16 years that ember was in the archive, it had a
|> total of 7 uploads, of which 2 NMUs and at least 3 maintainer uploads
|> were to fix release-critical bugs. That isn't a particularly good
|> ratio
|> of maintainer's time used : other people's time used.

That is very true, and I completely agree with you that Debian would be
unsustainable if all (or even a significant fraction of) packages had
this kind of track record.

|> This is not intended as a veto - hopefully you'll have more time for
|> it
|> than its previous maintainers - but I felt that before it is
|> reintroduced, I should specifically point out that every time a
|> package
|> fails to build from source or is otherwise RC-buggy, and every time
|> it
|> blocks a transition, it is creating work for people other than its
|> maintainer.

Yes, very true. I always try to do a quality job on anything I set my
mind to. I can't promise that all my uploads will be perfect, but I am
aware of the work that falls on others when a package is sub-standard
and I do not like others to have to do my work for me.

|> While team maintenance is of course A Good Thing, I'm not sure that
|> having "the games team" as a co-maintainer mitigates this very much;
|> the
|> wide range of game technologies and styles maintained by that team
|> mean
|> that it is relatively unlikely that a random games-team member knows
|> how
|> to fix and test a random games-team package (or indeed has any
|> interest
|> in that random package).

True, and the WorldForge packages are not exactly simple. I believe that
I can only safely count on Games Team support if an urgent fix is
required, the fix is simple, and I'm temporarily unavailable for
whatever reason. Obviously, anything more is a bonus. :) That's not
meant to be disparaging to my fellow Games Team members but I know that
they are all busy maintaining their own packages as well. I don't want
these packages to be a burden on the Games Team just like I don't want
them to be a burden on Debian resources at large.

|> Based on the history of ember and its dependencies, it seems fairly
|> likely that developers with an interest in the archive as a whole (QA
|> team, release team, ftpmasters) will respond to any RC bugs that
|> aren't
|> fixed promptly by just removing it again.

Well, I aim to maintain them in such a way that this does not become
necessary. :) It's not exactly a secret that I've had a strong interest
in Debian's success since I started using it in...oh, late 90s sometime.
Recently I have been trying to give back and I hope to apply to be a DM
soon... maybe a DD eventually, if my contributions are deemed
worthwhile. ;) I mention this to clarify that my involvement with the
WorldForge packages is not just a passing whim but part of my commitment
to help Debian overall.

I hope that assuages your concerns!

| Hi Simon,
|
| Maybe I chime in..
| I'm in contact with Olek since a while regarding the ecosystem around
| ember and the wf libraries. I also volunteered to sponsor his work and
| the first uploads are currently being prepared.
|
| Yes, the former maintainer was, lets say, problematic, a kind of 51th
| shade of MIA. (Responding to pings, promising actions soon, but in the
| end nothing happened) This was the main blocker here and Olek didn't
| want to offend the maintainer, despite that the packages were de-facto
| unmaintained.
| So this is the right point of time to get those packages a good
| restart, with Olek as maintainer, even if I see another 51th-shade of
| MIA in the way -- down the road. (Therefore I would be interested in
| general guidance how to handle such pseudo-MIA or selective-MIA: Cases
| where the maintainer is active, but still nothing happens at least on
| certain packages, even after prodding.)
|
| I'm confident that Olek will maintain the packages adequately.
| If not, removal bugs can still be filed, but I prefer to give him the
| opportunity to show.
|
| --
| tobi

Thanks for the support, Tobi! :)

- -Olek

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWAkUeAAoJEH2D1AagncHkoVkP/RzZFY5mQykl9Actw4LrTr/B
F2/XneXSIAd0vMz7SkKhYme6C5d9ozqAjU5vJkmjytLAWdw38JKCC+5tzI3CMkRd
B+GxgRDJ3zr8Lz7WjyA2FzIngh8EhP+9HW/8EJR2ftq93K+KXjtNpFwxuxiaNsvk
I5ONsY6e3JI3t0A6lBWyms5BcEkSmW99EoYbmnBL+n8mYt+TQGjdK4LZufZyJY7X
+xS0kcbeH2toq60rAFKIYpDNQawCj4eXGxWdAqph6OipXNaCZPrfzR4zkVwGZ0Jy
V614f7W4od5Tr8x504ETR9O3Xh55M9ywYLyR4hl/6nuDEAsoKxL7vHszZkaAAJL1
WDlNes2D5ZlUiSoLR1jjQQfpIY/X4YnEeIFQkX