Re: SDL packaging team revival

2011-11-30 Thread Dominique Dumont
Le Monday 28 November 2011 15:59:27, Jon Dowland a écrit :
  - users of SDL libs may not be only games (*)
 
 I don't see the relevance here.  What difference does the
 Maintainer: field make to users?

It's not about the field. IMO, it's more about the mindset of a packager when 
he considers his users. I concede that's a minor point.

  - Since Game packaging members are focused on games, SDL libs
  
packages are more likely to become victim of bystander apathy [1]
 
 Thoroughly disagree here.

ok. 

 The games team is an active team with an existing infrastructure/set
 of conventions: active alioth team admins; mailing list conventions;
 tools and infrastructure to monitor bugs and perform QA checks; wiki
 pages etc.

Agreed. 

 Creating a new team means doing all of the above again from scratch.
 It also means any contributor needs to put work in to subscribe to
 a new set of lists; request admin on a new project; learn a whole new
 set of conventions for VCS or whatever: a total pain.

That's why I push for conventions which are shared by games teams (and debian-
perl team). Did I stray far from your practices ?

 Whilst it's true that not all SDL users (in a packaging sense) are
 games, and not all games use SDL; certainly the vast majority in both
 direction do.  And having the SDL packages maintained by an active
 team with the majority of participants having a vested interested in
 their well being, and giving SDL bugs more eyeballs is a great thing
 IMHO.

In theory, you're right. In practice, SDL packages were not updated.

 I'd encourage anyone with the time and motivation to work on SDL to
 consider this avenue as I really believe it's the most sensible.

I'd encourage anyone to work where they're more comfortable. I've got no 
problem if someone wants to take over a SDL lib package and maintain it within 
game team provided it's properly communicated. What matters to me is that 
packages are not left to rot and people time is not wasted. 

  Let's say folding SDL team is plan B. Let's see first if plan A (SDL
  team revival) is working.
 
 If you really feel that's the best way, I wish you the best of luck.

Thanks. 

  That said, Debian games team members are also welcome to join SDL
  packaging team.
 
 Whilst I'm no longer in the games team, the burden/barrier of joining
 a new team and learning a whole new set of conventions on how to do
 stuff etc. as briefly detailed above is too high for me to bother, I'd
 rather put that energy into useful work.

BTW, you were already part of SDL team when I joined. You still are.

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


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


Re: SDL packaging team revival

2011-11-28 Thread Jon Dowland
On Sun, Nov 20, 2011 at 09:46:47AM +0100, Dominique Dumont wrote:
 Le Sunday 20 November 2011 00:41:40, Paul Wise a écrit :
  What happened to the idea of folding the SDL team into the games
  team?
 
 Nothing. I first heard of this idea several months ago and nothing
 happened since.

Not strictly true.  Fabian and I spent a few hours working on
sdl-mixer, in particular:  I got the package into git and started
rebasing patches on top of a new upstream version; Fabian reviewed all
the patches. I can't remember right now where that work is. I  hope
anyone who cares builds on top of our work and it isn't wasted.

 This idea is good but has some drawbacks: 
 - packaging lib and packaging games is sometwhat different 

The games team already package libs.

 - users of SDL libs may not be only games (*) 

I don't see the relevance here.  What difference does the
Maintainer: field make to users?

 - Since Game packaging members are focused on games, SDL libs
   packages are more likely to become victim of bystander apathy [1]

Thoroughly disagree here.

The games team is an active team with an existing infrastructure/set
of conventions: active alioth team admins; mailing list conventions;
tools and infrastructure to monitor bugs and perform QA checks; wiki
pages etc.

Creating a new team means doing all of the above again from scratch.
It also means any contributor needs to put work in to subscribe to
a new set of lists; request admin on a new project; learn a whole new
set of conventions for VCS or whatever: a total pain.

Whilst it's true that not all SDL users (in a packaging sense) are
games, and not all games use SDL; certainly the vast majority in both
direction do.  And having the SDL packages maintained by an active
team with the majority of participants having a vested interested in
their well being, and giving SDL bugs more eyeballs is a great thing
IMHO.

I'd encourage anyone with the time and motivation to work on SDL to
consider this avenue as I really believe it's the most sensible.

 Let's say folding SDL team is plan B. Let's see first if plan A (SDL
 team revival) is working.

If you really feel that's the best way, I wish you the best of luck.

 That said, Debian games team members are also welcome to join SDL
 packaging team. 

Whilst I'm no longer in the games team, the burden/barrier of joining
a new team and learning a whole new set of conventions on how to do
stuff etc. as briefly detailed above is too high for me to bother, I'd
rather put that energy into useful work.


Thanks,

-- 
Jon Dowland



Re: SDL packaging team revival

2011-11-21 Thread Paul Wise
What happened to the idea of folding the SDL team into the games team?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


Re: SDL packaging team revival

2011-11-21 Thread Kartik Thakore
Is there interest from the games team to push and work on SDL packages? Or
would it get lost in a larger sea of packages to maintain.
Additionally, I feel SDL is not necessarily only games related.
On Nov 21, 2011 3:11 AM, Paul Wise p...@debian.org wrote:

 What happened to the idea of folding the SDL team into the games team?

 --
 bye,
 pabs

 http://wiki.debian.org/PaulWise