[Pkg-cups-devel] RFC: Forming a Printing Task Force (was RFA: cups -- Common UNIX Printing System)

Jonas Smedegaard dr at jones.dk
Sat Jul 3 12:16:12 UTC 2010


On Sat, Jul 03, 2010 at 01:11:46PM +0200, Didier 'OdyX' Raboud wrote:
>Hi all,
>
>Le samedi 3 juillet 2010 12:09:14, vous avez écrit :
>> It is still undecided how to handle packages.  Please help contribute 
>> with your preferences rather than assume that others are working 
>> against you :-)
>>
>> Personally I would prefer to have them in collab-maint too.

>Bad timing: I'm leaving out in VAC for two weeks, until the 18., with 
>no internet nor computer access.

I'm going (mostly) silent too for the next 2 weeks - for (fun and 
exciting) work, however, not vacation.

>Anyway, the wiki page now lists the proposal: I don't want to require 
>anything from anybody: feel free to discuss and/or amend everything 
>from that page. You don't need me to implement things, form the team or 
>anything.
>
>It's not necessary to have an alioth group, or an IRC channel or 
>anything to handle packages in common: the idea (I have) behind a team 
>is that the forces are shared and spread across the packages put under 
>the team umbrella. This does _not_ mean that work in the packages 
>happens without communication and coordination. (Having a common (and 
>unique) mailing list used in "Maintainer:" fields is still better 
>IMHO.)
>
>Technically, I still think that an alioth group with shared 
>repositories (across all VCS'es if needed) makes things clearer. But 
>I'm fine with collab-maint too: I'll do with what "we" decide to use.

Own Alioth team:

  + Easiest to enter for non-DDs (we can approve ourselves)
  + Best protected (only our approved members can write to VCSes)

Collab-maint team:

  + Easiest to enter for DDs (are already members)

No team (just a list):

  + Least restructuring for existing teams


In my (minor) experience (from the Sugar team) it is not really 
difficult to instruct new non-DDs to a) request membership at the 
collab-maint team and mention as reason that they need it to work on 
printing packages.  And I would really want to make it easiest possible 
for existing Debian Developers to ccollaborate with us, even without 
formally joining a team.

I see little risk in allowing write-access for all Debian developers to 
VCSes - if needed we can simply roll back changes or reset to a 
non-polluted mirror from somewhere else.  Hmm - maybe this actually is 
an added burden for those using non-distributed VCSes like SVN...


I am personally very hesitant joining a team that I do not know which 
policies will emerge from, and I guess I am not alone in that.

Therefore I suggest we move in the following steps, to both make room 
for early adopters and scepticism:

  0) Create a wiki page (done already: awesome!)
  1) Decide on a mailinglist
  2) Let early adopters switch to use ML as package maintainer
  3) Discuss ideas for more tight collaboration than that
  4) Let more join - and perhaps some leave if not liking team evolution


Kind regards,

  - Jonas

P.S.

I have an interest in profesional grade desktop publishing, and am quite 
skilled in packaging routines, but not in C og PostScript coding, and am 
also involved in quite a few packaging projects, which limits my 
abilities debugging.

P.P.S.

I am not in charge of the ghostscript package - formally I am simply a 
"helping hand" although in reality it has unfortunately been somewhat 
the only active "hand" for some time, as can be seen in the packaging 
changelog.  So my being interested in this shared team is speaking for 
myself, not (yet) on behalf of the ghostscript "team".

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20100703/c202b161/attachment.pgp>


More information about the Pkg-cups-devel mailing list