[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