Joining the DPMT

2020-07-09 Thread Federico Ceratto
Hello,

I was in the DPMT back when it was on Alioth and I would like to join
it again to backport python-flasgger and help with other packages as
the need arises.
My Salsa login is "federico".

I have read the policy and I accept it:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Thank you!
--
Federico



Re: joining the DPMT.

2020-05-07 Thread Scott Kitterman
On Thursday, April 30, 2020 5:32:39 PM EDT peter green wrote:
> I would like to join the DPMT, there are a couple of reasons for this.
> 
> Firstly I have been making an effort to try and get broken
> build-dependencies in testing fixed, and this often ends up involving
> python module packages. It would be easier to fix such packages as a member
> of the team than working through patches and NMUs as I have done so far.
> 
> Secondly I maintain a couple of python modules, which it may make sense to
> bring into team maintainership, though I would have to figure out how to
> restructure the git repositories to fit the dpmt policy.
> 
> I have read and accept the DPMT policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/polic
> y.rst
> 
> my salsa username is plugwash

Welcome to the team.

Scott K

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


joining the DPMT.

2020-04-30 Thread peter green

I would like to join the DPMT, there are a couple of reasons for this.

Firstly I have been making an effort to try and get broken build-dependencies 
in testing fixed, and this often ends up involving python module packages. It 
would be easier to fix such packages as a member of the team than working 
through patches and NMUs as I have done so far.

Secondly I maintain a couple of python modules, which it may make sense to 
bring into team maintainership, though I would have to figure out how to 
restructure the git repositories to fit the dpmt policy.

I have read and accept the DPMT policy at 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

my salsa username is plugwash



Re: Joining the DPMT Team

2019-12-05 Thread Ondrej Novy
Hi,

st 4. 12. 2019 v 17:07 odesílatel Boyuan Yang  napsal:

> ... Can
> anyone add me into the DPMT Team? My Salsa account is @byang.
>

done.

-- 
Best regards
 Ondřej Nový


Joining the DPMT Team

2019-12-04 Thread Boyuan Yang
Hi all,

I have been working in the PAPT Team for quite some time and found that it's
not really easy to be working under PAPT without DPMT access, since fixes for
Python applications would often require changes in Python libraries. Can
anyone add me into the DPMT Team? My Salsa account is @byang.

Thanks very much in advance!

Regards,
Boyuan Yang


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


Re: Joining the DPMT

2019-08-04 Thread Ondrej Novy
Hi,

ne 4. 8. 2019 v 13:53 odesílatel Andreas Ronnquist 
napsal:

> Gah, I guess the package I would like to package is better suited for
> the PAPT - So, I would like to join the Debian Python Applications
> Packaging Team too.
>

done.

-- 
Best regards
 Ondřej Nový


Re: Joining the DPMT

2019-08-04 Thread Andreas Ronnquist
On Sat, 3 Aug 2019 22:13:23 +0200,
Ondrej Novy wrote:

>Hi,
>
>so 3. 8. 2019 v 13:14 odesílatel Andreas Ronnquist
> napsal:
>
>>  am a Debian Developer, and my salsa login is gusnan.
>>  
>
>welcome :)
>

Gah, I guess the package I would like to package is better suited for
the PAPT - So, I would like to join the Debian Python Applications
Packaging Team too.

I have read the PAPT policy at [1], and accept it.

Sorry for the confusion.
-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

[1]
https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst


pgpLXWnZlhX9F.pgp
Description: OpenPGP digital signatur


Re: Joining the DPMT

2019-08-03 Thread Ondrej Novy
Hi,

ne 28. 7. 2019 v 20:09 odesílatel Peter Wienemann 
napsal:

> My salsa login is wiene-guest.
>

welcome :)

-- 
Best regards
 Ondřej Nový


Re: Joining the DPMT

2019-08-03 Thread Ondrej Novy
Hi,

so 3. 8. 2019 v 13:14 odesílatel Andreas Ronnquist 
napsal:

>  am a Debian Developer, and my salsa login is gusnan.
>

welcome :)

-- 
Best regards
 Ondřej Nový


Joining the DPMT

2019-08-03 Thread Andreas Ronnquist
Hi

I would like to maintain lollypop [1], ITP at [2],
in the Debian Python Modules team.

I am a Debian Developer, and my salsa login is gusnan.

I have read the DPMT policy [3], and accept it.

Thanks in advance
-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net
gus...@debian.org

[1] https://wiki.gnome.org/Apps/Lollypop
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847937
[3] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


pgpnhNdNuwUxD.pgp
Description: OpenPGP digital signature


Joining the DPMT

2019-07-28 Thread Peter Wienemann
Hi,

I am one of the maintainers of the Charliecloud package [0]. The most
recent version of Charliecloud (0.10) has added new python dependencies
(lark [1] and its dependencies). Some of them are not yet available in
Debian.

My salsa login is wiene-guest.

I read the DPMT policy [2] and I accept it.

Peter

[0] https://tracker.debian.org/pkg/charliecloud
[1] https://github.com/lark-parser/lark
[2]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst



Re: Joining the DPMT team!

2019-07-07 Thread Piotr Ożarowski
[Louis-Philippe Véronneau, 2019-07-02]
> I would like to join the DPMT team.

welcome :)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Joining the DPMT team!

2019-07-02 Thread Louis-Philippe Véronneau
Hi!

I would like to join the DPMT team.

My current goal is to package ponyorm [1] to be able to package
supysonic [2] with the PAPT team (which I'm already part of).

I'm currently am  a non-uploading DD, but I've started packaging stuff
[3] [4] [5].

My Salsa login is: pollo

I have read the DPMT policy [6] and agree to it.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926459
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926457

[3]: https://salsa.debian.org/debian/firmware-tomu
[4]: https://salsa.debian.org/python-team/applications/rename-flac
[5]: https://salsa.debian.org/python-team/applications/membernator

[6]:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Joining the DPMT and PAPT teams

2018-06-07 Thread Ondrej Novy
Hi,

2018-06-06 12:19 GMT+02:00 Stephen Kitt :

> I would like to join the teams...
>

welcome :)

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B


Joining the DPMT and PAPT teams

2018-06-06 Thread Stephen Kitt
Hi,

I would like to join the teams, at least to maintain PyQtCharts
(https://bugs.debian.org/892198). I also maintain the Python modules
python-evdev and python-libevdev, and the Python applications solaar,
ratbagd/libratbag, and perhaps others I’m forgetting right now. Some of those
have an upstream branch which corresponds to the real upstream branch rather
than imported tarballs, which I understand goes against the Python team’s
policy, so I’m not sure whether they’d be suitable for migration to team
maintenance; but I’d be happy to discuss that.

I read the policy before Alioth was shut down, and accept it (for packages
which I would maintain under the team umbrella).

My Salsa login is skitt.

Regards,

Stephen


pgpofxW4Us4Nb.pgp
Description: OpenPGP digital signature


Re: Joining the DPMT

2018-03-26 Thread Piotr Ożarowski
[Ana C. Custura, 2018-03-06]
> I am writing about joining the DPMT.  I have a handful of prospective
> python packages which I would like to maintain within the team, and
> some existing ones to transition. 
> I have read and accepted the policy at
> https://python-modules.alioth.debian.org/policy.html and my name on
> salsa is ana-guest. 

welcome! :)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Joining the DPMT

2018-03-05 Thread Ana C. Custura
Hi,

I am writing about joining the DPMT.  I have a handful of prospective python 
packages which I would like to maintain within the team, and some existing ones 
to transition. 
I have read and accepted the policy at 
https://python-modules.alioth.debian.org/policy.html and my name on salsa is 
ana-guest. 

Thank you,
Ana



Re: Joining the DPMT

2015-07-13 Thread koanhead
On Mon, 06 Jul 2015 00:30:02 +0200, IOhannes m zmölnig wrote:

 On 07/05/2015 09:51 PM, Piotr Ożarowski wrote:
 
 PPS hint to others: my favourite join requests are signed, include
 I've read
 https://python-modules.alioth.debian.org/python-modules-policy.html and
 I accept it
 and mention previous Pyton/Debian work (package names? patches? bug
 reports?)
 
 
 as someone who has only recently joined DPMT, i have to admit that i
 subscribed to this list at the same time i applied for team membership.
 as such, i wouldn't have known about your favourites.
 maybe it would be good to add them to the wiki (right i could do that
 myself, but now i'm going to sleep :-))

I've added the cited quote directly to https://wiki.debian.org/Teams/
PythonModulesTeam/HowToJoin - I hope that's OK.

BTW I expect I'll be sending such a join request in a few weeks- but I've 
got a bunch of study and preparation to do first ☺


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mnvpd6$rbf$1...@speranza.aioe.org



Re: Joining the DPMT

2015-07-05 Thread Piotr Ożarowski
Hi,

[James Page, 2015-07-02]
 I've been skulking around on this ML and on the #debian-python IRC
 channel for a while now so thought it was about time I put in my
 request to join the DPMT.
 
 I've been working across Debian and Ubuntu for the last 4.5 years; I
 started doing Java packaging, then my job at Canonical changed and I
 now mainly work on packaging Python bits and pieces now - specifically
 OpenStack (I'm the tech lead of the OpenStack engineering team at
 Canonical).
 
 Corey Bryant and I have started working more closely with Thomas in
 the PKG OpenStack team in the last month or so - but its evident that
 we can make some valuable contribution across Python modules generally.

you're in, welcome :)

PS you didn't mention your Alioth account name, so I didn't know you're
a DD (we don't really need to check DDs previous work. I'm sure you will
not convert all packages from SVN to Git or start to add Perl packages
to our repo...)

PPS hint to others: my favourite join requests are signed, include
I've read https://python-modules.alioth.debian.org/python-modules-policy.html 
and I accept it
and mention previous Pyton/Debian work (package names? patches? bug
reports?)
-- 
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


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150705195141.gh9...@sar0.p1otr.com



Re: Joining the DPMT

2015-07-05 Thread IOhannes m zmölnig
On 07/05/2015 09:51 PM, Piotr Ożarowski wrote:
 
 PPS hint to others: my favourite join requests are signed, include
 I've read 
 https://python-modules.alioth.debian.org/python-modules-policy.html and I 
 accept it
 and mention previous Pyton/Debian work (package names? patches? bug
 reports?)
 

as someone who has only recently joined DPMT, i have to admit that i
subscribed to this list at the same time i applied for team membership.
as such, i wouldn't have known about your favourites.
maybe it would be good to add them to the wiki (right i could do that
myself, but now i'm going to sleep :-))

gfmasr
IOhannes



signature.asc
Description: OpenPGP digital signature


Joining the DPMT

2015-07-02 Thread James Page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

I've been skulking around on this ML and on the #debian-python IRC
channel for a while now so thought it was about time I put in my
request to join the DPMT.

I've been working across Debian and Ubuntu for the last 4.5 years; I
started doing Java packaging, then my job at Canonical changed and I
now mainly work on packaging Python bits and pieces now - specifically
OpenStack (I'm the tech lead of the OpenStack engineering team at
Canonical).

Corey Bryant and I have started working more closely with Thomas in
the PKG OpenStack team in the last month or so - but its evident that
we can make some valuable contribution across Python modules generally.

Cheers

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlUXXAAoJEL/srsug59jDoJ8P/3XY23D+uYzewKdWAnlpRT5K
LPaBPf8P4wJcn2plLtGWSRWnWD1sfLiJmqBCYfEqyxE6KO/mERf74j7SNkdHYiyp
kbBAMIOzLWd+EFCTpY/oAChS7y3fw/XnPwhQOsgoiZIRN5DZgjDja4F/LC3RZa/J
Nn/FkIs/pVlWeurc0tNr1IwgwbFKadFvR7wng3BHukQLVbJuprqzzCcMHq/QgV7t
6XNGIFvbqHsiNlMobzJf8AYMqvesiksJQDjngCSR+OzGpctWahEc743cZw0UMihG
1OWAT/HBM4nlVAx5mNxHr//V73DeWMND4Uef3ymWCDOgZ4vIQIqyFta1llPLNRtd
ieGwAhLZmAGMT9jgNTLBfkzcF5LIuKMIJNi9F9V+wsu5ApvNSt8AkqmBY1gVRuDV
xC6XHlMjTIyh4AhNG/kbtmpt2/gzm4p+IzxKs55zqwYiGRPaJZHzgldgiFn9E84p
Fryxpi4JKdkfRduwEKeG0o+GOKnvhrLh6oRM49as4i1ADv1/Xhlqtp2MXITZFMCm
C9VsBVeFpHNaT2TNEsOJPs31kL7fOxlR6djK/9xPfiFfrDwi6BYcNnZwMw12W4jW
2gE6u5oyPuKPARai1sWhSiWXW6oh8OfhlJvii+Kr0sjz/GVnKfBSYaWu/Ses5Xmd
76m+ao6Vu4PencHJMyoJ
=C8ji
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559545d7.7080...@ubuntu.com



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-22 Thread Matthias Klose
Am 22.01.2014 08:28, schrieb Thomas Goirand:
 On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It might
 indeed be so, we're all busy.  But let's hopefully all agree that the end 
 goal
 is to have all team-maintained packages in the same vcs.
 
 I can't answer this question, as I can't speak for the others, and I
 don't have time myself.

sure, so you are proposing something which you don't want to finish, just
pursuing a rather selfish interest of using git yourself.  You did try this with
the debian-java team as well.

 Well, if we decide to move slowly things to Git, then the packages that
 will stay in the SVN repo will be those largely unmaintained...

and these will be magically maintained when converted to Git?  please don't be
silly.  unmaintained packages are not a property of the used VCS. And you said
you don't have time to spend on these yourself.

 http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
 
 The only reason they are maintained within the OpenStack team is because
 I don't want to be forced to use SVN, and I think it's safer than in
 collab-maint where so many people have commit access (which means they
 can rm -rf...).

apparently these were first needed for openstack. so it seems to make sense to
maintain these over there.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dfadf0.9080...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-22 Thread Thomas Goirand
On 01/22/2014 07:39 PM, Matthias Klose wrote:
 Am 22.01.2014 08:28, schrieb Thomas Goirand:
 On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It 
 might
 indeed be so, we're all busy.  But let's hopefully all agree that the end 
 goal
 is to have all team-maintained packages in the same vcs.

 I can't answer this question, as I can't speak for the others, and I
 don't have time myself.
 
 sure, so you are proposing something which you don't want to finish, just
 pursuing a rather selfish interest of using git yourself.  You did try this 
 with
 the debian-java team as well.

I don't think so. I don't maintain any Java package.

 Well, if we decide to move slowly things to Git, then the packages that
 will stay in the SVN repo will be those largely unmaintained...
 
 and these will be magically maintained when converted to Git?

I guess, not more than with SVN...

 please don't be silly.

I don't think I have. You are making wrong assumptions here, I believe.

 unmaintained packages are not a property of the used VCS.

Agreed!!!

 And you said
 you don't have time to spend on these yourself.
 
 http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

 The only reason they are maintained within the OpenStack team is because
 I don't want to be forced to use SVN, and I think it's safer than in
 collab-maint where so many people have commit access (which means they
 can rm -rf...).
 
 apparently these were first needed for openstack. so it seems to make sense to
 maintain these over there.

That's truth only for a subset of them, not all of them. Many are of
general purpose.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dfca83.7020...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Dimitri John Ledkov
On 15 January 2014 02:29, Chow Loong Jin hyper...@debian.org wrote:
 On Tue, Jan 14, 2014 at 04:51:20PM +0100, Olivier Berger wrote:
 Now, if you both want to track upstream sources from origin/master on
 local upstream/ branch and svn's trunk on local master branch, then,
 yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges
 now and then.

 git import-orig --filter=debian helps to avoid nasty merges, as long as you
 don't make changes to the upstream sources directly inside your packaging 
 branch
 -- there shall be no conflicts if upstream does not touch debian and you do 
 not
 touch the upstream sources.

 gbp-pq is also wonderful for maintaining quilt patch series.

My preference lately is strongly with: dgit + git-dpm (for patch management).

git-dpm does not polute repository with branches of any sort, it
simply maintains a round-trip-safe conversion from debian/patches to a
branch and back again.
(Something very similar to Mercurial Queues but done nicer and more
specific to debian packaging)

I haven't yet found a way to use dgit/git-dpm against svn repository.
I'm thinking to simply do dsc-import on the svn side, after I generate
an upload with dgit/git-dpm.
Once the kinks are worked out, and some sort of forest (mr or repo)
management is in place we can start opening up an outstanding git
powered workflow.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhlugki6ptvmhd6qihm80hhgr0mbgypc2aa+cvpmjr9gp...@mail.gmail.com



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Thomas Goirand
On 01/14/2014 09:24 PM, Alexandre Rossi wrote:
 I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).

Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable, predicted, and unavoidable.

In fact, using collab-maint is something that I would advise right now
if nothing moves in this team.

On 01/14/2014 09:55 PM, Piotr Ożarowski wrote:
 I reported bug reports, thanks

Why doing this? It doesn't make sense. It seems obvious to me that the
person using collab-maint do want to use Git. Don't force them back to
SVN please, it wouldn't be nice to them, especially if our plan is to
migrate away from it at some point. I don't see this as a bug, I see it
as a problem in the Python team, unless the Git repo is reactivated, and
the person who deactivated it doesn't do it again.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 I need to spend more time playing with git-bp, but last time I looked at it
 (cannot remember which package), I had a lot of trouble unless the package
 repo was organized Just Right.  One nice thing about svn-bp is that it pretty
 much just works with a checked out working directory, even when you have local
 uncommitted changes (--svn-ignore-new).

Probably you're not used enough with Git, because for what I'm doing,
it pretty much just work with a checked out working directory with Git
as well.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 git-bp OTOH required a specific set of branches inside the repo to
 stitch everything together and if those were missing, it failed
 miserably.

It all depends how you do it. If you base your Git packaging on tags,
and not using branches, which means having a debian/gbp.conf that
configures this, then it's really strait forward.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
 I've mostly made my peace with git, so in theory I wouldn't be
 opposed to the team switching

There's been a vote that we should switch already. I don't think it's a
good idea to express oneself about liking or not Git: we agreed we
should switch to it.

, but I still think it's not a good idea
 to have some team packages in git and the bulk in svn.  I value the
 ability to use the same tools and workflows for all team maintained
 packages.

Now, this could be back on the table: it's been months that we've talked
about it, and nothing is happening, because nobody has time. So the only
way I see to switch is to do it slowly, having both SVN and Git for some
time. Other teams have reported that it worked for them, so I don't see
why it wouldn't for python modules.

By the way, something like mr (from Joey Hess) could help regarding
mass commits.

On 01/14/2014 11:09 PM, Hans-Christoph Steiner wrote:
 I'm a fan of a gradual transition like this, with people switching or
 setting up git repos as they can.

I'm not a fan of it (it'd be IMO better to completely switch), but I
don't see any other practical way to move forward right now.

On 01/14/2014 11:51 PM, Olivier Berger wrote:
 It more or less requires only 2 branches : upstream (when you
 want to track upstream sources) and master (or debian) for the
 packaging source.

Hum... I'd say that *your workflow* requires it, but git-buildpackage
itself doesn't. You don't have to do this way. Everything can be
contained in a single branch if you use tags. Also, if you don't use
tags, and prefer to use upstream tarballs, then I think you're much
better off using pristine tar (and git-import-orig).

Also, I don't like using debian and master for branch names. These
express nothing. It's much better to use unstable-debian and
upstream-debian for example.

As a reference, here's a debian/gbp.conf for tags:
[DEFAULT]
debian-branch = debian/unstable
upstream-tag = %(version)s

And here's one for pristine-tar:
[DEFAULT]
upstream-branch = upstream-unstable
debian-branch = debian-unstable
pristine-tar = True

I also always add in my debian/gbp.conf:
[git-buildpackage]
export-dir = ../build-area/

to make sure no contributors dirties the git with build files (yes, you
can do that in your ~/.gbp.conf, and the system configuration file in
/etc, but the point here is to make sure *everyone* uses the build-area).

Thomas

[1] I know who it is, though I don't think it is useful to tell who.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df4045.6080...@debian.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Steve Langasek
On Wed, Jan 22, 2014 at 11:51:33AM +0800, Thomas Goirand wrote:
 On 01/14/2014 10:31 PM, Barry Warsaw wrote:
  I need to spend more time playing with git-bp, but last time I looked at it
  (cannot remember which package), I had a lot of trouble unless the package
  repo was organized Just Right.  One nice thing about svn-bp is that it 
  pretty
  much just works with a checked out working directory, even when you have 
  local
  uncommitted changes (--svn-ignore-new).

 Probably you're not used enough with Git, because for what I'm doing,
 it pretty much just work with a checked out working directory with Git
 as well.

git-buildpackage has a few misbehaviors by default: the fact that it builds
in place by default instead of exporting to a separate dir is annoying
(--git-export-dir=../build-area/), and that you have to pass it extra
options when you're building from a branch named 'debian'
(--git-debian-branch=branch_name).  IIRC there are subtle differences in
behavior between --svn-ignore-new and --git-ignore-new, but I don't remember
now what they are.

Its pristine-tar handling is pretty solid, though.

 On 01/14/2014 10:31 PM, Barry Warsaw wrote:
  git-bp OTOH required a specific set of branches inside the repo to
  stitch everything together and if those were missing, it failed
  miserably.

 It all depends how you do it. If you base your Git packaging on tags,
 and not using branches, which means having a debian/gbp.conf that
 configures this, then it's really strait forward.

Yes, having to edit debian/gbp.conf on a per-branch basis to even get the
package to build is an annoying misfeature.

 Also, I don't like using debian and master for branch names. These
 express nothing. It's much better to use unstable-debian and
 upstream-debian for example.

 As a reference, here's a debian/gbp.conf for tags:
 [DEFAULT]
 debian-branch = debian/unstable
 upstream-tag = %(version)s

 And here's one for pristine-tar:
 [DEFAULT]
 upstream-branch = upstream-unstable
 debian-branch = debian-unstable
 pristine-tar = True

 I also always add in my debian/gbp.conf:
 [git-buildpackage]
 export-dir = ../build-area/

 to make sure no contributors dirties the git with build files (yes, you
 can do that in your ~/.gbp.conf, and the system configuration file in
 /etc, but the point here is to make sure *everyone* uses the build-area).

Right... these are things the end user (or the package maintainer) should
not have to configure :)

But I don't think the DPMT should wait for these buglets to be fixed in
git-buildpackage before switching to git.  (Not that my opinion matters
anyway. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Charles Plessy
Le Wed, Jan 22, 2014 at 11:51:33AM +0800, Thomas Goirand a écrit :
 
 And here's one for pristine-tar:
 [DEFAULT]
 upstream-branch = upstream-unstable
 debian-branch = debian-unstable
 pristine-tar = True

Bonus points if the Git repository on Alioth has its HEAD pointing to the
debian branch (that is, the one that contains debian/gbp.conr) instead of
master.  In that case, the command gbp clone will do the right thing by
tracking the relevant branches by default (which debcheckout will not).  This
is especially useful when using pristine-tar, because often the beginners are
surprised by the error message when this branch is not directly available.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140122041811.gd4...@falafel.plessy.net



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Barry Warsaw
Apologies for quoting out of order.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
, but I still think it's not a good idea
 to have some team packages in git and the bulk in svn.  I value the
 ability to use the same tools and workflows for all team maintained
 packages.

On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote:

Now, this could be back on the table: it's been months that we've talked
about it, and nothing is happening, because nobody has time. So the only
way I see to switch is to do it slowly, having both SVN and Git for some
time. Other teams have reported that it worked for them, so I don't see
why it wouldn't for python modules.

Do you really think that it's unfeasible for git proponents on this team to
find the necessary resources to plan an orderly en mass transition?  It might
indeed be so, we're all busy.  But let's hopefully all agree that the end goal
is to have all team-maintained packages in the same vcs.

So let's say we have to move packages slowly.  I want to make sure there's a
team commitment (and especially from the git proponents) that we'll have a
deadline at which all remaining packages will be switched.  I *really* want to
avoid the typical long tail where packages just linger under svn and bit rot.
(E.g. long tail conversions to dh_python2.)

So I would be in favor of an experiment.  Pick 5 packages that are
representative of team packages, that can be updated and uploaded by anyone on
the team, and that see regular but not too often new upstream releases.  I'd
happily volunteer one of my packages if that helps.

Now, conduct an experiment.  Convert those 5 packages to git + gbp and do some
uploads.  Let anyone on the team make changes just as they would in svn.  Ask
for reviewers.  Ask for sponsors.

The most important thing though is to *document* in detail *on the wiki* how
to work with those packages in git.  Be opinionated, like the way we are with
the LibraryStyleGuide.  Don't worry if others disagree with you - we can hash
out best practices in this mailing list over time, but it's really important
to put a stake in the ground.  If you can't decide which of two ways is
better, do one package one way and another the other way.

It's not good enough if the only instructions that exist are in mailing list
archives.  I don't want to force team members who come after us to have to
excavate through countless emails to find out the way we want things done.

On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote:

Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable, predicted, and unavoidable.

I don't know if my proposed experiment means re-enabling git on the team repo
or doing the experiment on collab-maint.  Obviously, like the long tail of svn
above, I want the end result to eventually be all the packages back in the
same place, but for now, if collab-maint is good enough for this experiment,
then that would be fine.

It all depends how you do it. If you base your Git packaging on tags,
and not using branches, which means having a debian/gbp.conf that
configures this, then it's really strait forward.

I know there will be many different ways to do it, just like today there are
many different ways to write your packaging.  Don't try to cover every
possibility.  That can come over time.  Tell me what *you* think are the best
ways to do it that will cover 80% of the packages we collectively maintain.
We can deal with outliers, options, and alternatives later.

On 01/14/2014 11:51 PM, Olivier Berger wrote:
 It more or less requires only 2 branches : upstream (when you
 want to track upstream sources) and master (or debian) for the
 packaging source.

Hum... I'd say that *your workflow* requires it, but git-buildpackage
itself doesn't. You don't have to do this way. Everything can be
contained in a single branch if you use tags. Also, if you don't use
tags, and prefer to use upstream tarballs, then I think you're much
better off using pristine tar (and git-import-orig).

I don't really have a good sense of what's better.  Upstream tarballs +
pristine tar seems more comfortable coming from the svn way, but tags and or
branches seems more like Ubuntu Distributed Development, which I very much
like despite the problems[*].  So I don't know, pick what you like and tell me
how to do it.

Is that doable and worthwhile?

Cheers,
-Barry

[*] which include:

- branch importer failures causing branches to be out of sync with the archive
- sort of working integration with quilt, but still kind of crappy in general
- not as awesome in practice as it *could* be
- choice of dvcs

But then my question is: how closely does your vision of the team git repo
overlap with general Debian initiatives like dgit and source branches?  It
might be nice if they align rather closely.


signature.asc
Description: PGP signature


Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Barry Warsaw
On Jan 21, 2014, at 08:05 PM, Steve Langasek wrote:

git-buildpackage has a few misbehaviors by default: the fact that it builds
in place by default instead of exporting to a separate dir is annoying
(--git-export-dir=../build-area/), and that you have to pass it extra
options when you're building from a branch named 'debian'
(--git-debian-branch=branch_name).  IIRC there are subtle differences in
behavior between --svn-ignore-new and --git-ignore-new, but I don't remember
now what they are.

That's my vague recollection too.

Right... these are things the end user (or the package maintainer) should
not have to configure :)

But I don't think the DPMT should wait for these buglets to be fixed in
git-buildpackage before switching to git.  (Not that my opinion matters
anyway. :)

Agreed.  We have precedence here too: there were annoying buglets in the
Python helpers, which we documented around until they were fixed[*].  We can
do the same thing here too, because wikis.

Cheers,
-Barry

[*] like having to explicitly loop through Python versions until pybuild came
along. :)


signature.asc
Description: PGP signature


Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-21 Thread Thomas Goirand
On 01/22/2014 12:24 PM, Barry Warsaw wrote:
 Do you really think that it's unfeasible for git proponents on this team to
 find the necessary resources to plan an orderly en mass transition?  It might
 indeed be so, we're all busy.  But let's hopefully all agree that the end goal
 is to have all team-maintained packages in the same vcs.

I can't answer this question, as I can't speak for the others, and I
don't have time myself.

 So let's say we have to move packages slowly.  I want to make sure there's a
 team commitment (and especially from the git proponents) that we'll have a
 deadline at which all remaining packages will be switched.  I *really* want to
 avoid the typical long tail where packages just linger under svn and bit rot.
 (E.g. long tail conversions to dh_python2.)

Well, if we decide to move slowly things to Git, then the packages that
will stay in the SVN repo will be those largely unmaintained...

 So I would be in favor of an experiment. Pick 5 packages that are
 representative of team packages, that can be updated and uploaded by anyone on
 the team, and that see regular but not too often new upstream releases.  I'd
 happily volunteer one of my packages if that helps.

Well, if the team decides to move to Git, then I would put *ALL* of the
python module packages I maintain for OpenStack directly within the
DPMT. That's a consequent list of about 50 python modules:

http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

The only reason they are maintained within the OpenStack team is because
I don't want to be forced to use SVN, and I think it's safer than in
collab-maint where so many people have commit access (which means they
can rm -rf...).

 The most important thing though is to *document* in detail *on the wiki* how
 to work with those packages in git.

I agree that documenting the workflow is very important. I have
described my workflow here for OpenStack:
http://openstack.alioth.debian.org/

I wish to continue using this git based workflow whenever possible, and
use the pristine-tar workflow when there's no upstream git.

 Be opinionated, like the way we are with
 the LibraryStyleGuide.  Don't worry if others disagree with you - we can hash
 out best practices in this mailing list over time, but it's really important
 to put a stake in the ground.  If you can't decide which of two ways is
 better, do one package one way and another the other way.

I do believe in freedom as well! :)

 On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote:
 Yes, because someone found it useful to disable the git area in the team
 repo on Alioth [1] !!! And this drove people to collab-maint. This was
 predictable, predicted, and unavoidable.
 
 I don't know if my proposed experiment means re-enabling git on the team repo

I believe it does.

 or doing the experiment on collab-maint.

Any non-DD will have to request for access to collab-maint. This is
unnecessary, potentially dangerous, and administratively heavy to do that.

 But then my question is: how closely does your vision of the team git repo
 overlap with general Debian initiatives like dgit and source branches?  It
 might be nice if they align rather closely.

I don't think this is related. I see dgit as a tool to use only if the
package isn't maintained using Git...

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df7328.8040...@debian.org



Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Piotr Ożarowski
[Alexandre Rossi, 2014-01-13]
 I'd like to join the Debian python modules team.
 
 My goal is to maintain sockjs-twisted (#735154).
 
 My alioth username is niol-guest.

the problem is... we don't use git, not yet at least (nobody had time to
propose a transition)
-- 
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


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114081902.gm4...@sts0.p1otr.com



Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Olivier Berger
Hi.

Alexandre Rossi alexandre.ro...@gmail.com writes:

 Hi,

 My goal is to maintain sockjs-twisted (#735154).

 the problem is... we don't use git, not yet at least (nobody had time to
 propose a transition)

 The Wiki page[1] suggests there are some git repositories, but I
 cannot find/see them. I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).

 Regarding the transition, the Java packaging team has both git and svn
 repositories. Maybe the DPMT can do the same starting with my package
 in the path suggested by the Wiki.

 Advice?

 Alex

 [1] https://wiki.debian.org/Teams/PythonModulesTeam/


Maybe I can share a bit of help by explaining what I've tried to do for
some recent contributions of mine.

I've used git-buildpackage with git-svn on submodules of the DPMT SVN
repo without too many difficulties so far.

The command line is usually of this kind :
 $ gbp buildpackage [--git-verbose] --git-cleaner= --git-overlay 
--git-export-dir=../build-area/ --git-tarball-dir=../tarballs [--git-pbuilder] 
[-us -uc --git-ignore-new]

This at least allows to work offline until the commit graph looks nice
with git, and push (dcommit) to SVN when the package has been uploaded
(or when you have a consistent state).

This may also allow keeping in the same git repo an upstream clone
together with the git-svn checkout.

I think [0] may offer some more details on that topic.

In a summary, we have SVN for some large scale operations and to please
the dinausors^Waddicted ones, and the power of git for the comfort of
the maintainer testing changes to the package locally.

Hope this helps.

Best regards,

[0] 
http://honk.sigxcpu.org/con/Using_git_svn_and_git_buildpackage_to_build_packages_maintained_in_Subversion.html
 

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3e2vfzh@inf-8660.int-evry.fr



Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Piotr Ożarowski
[Alexandre Rossi, 2014-01-14]
 The Wiki page[1] suggests there are some git repositories

I added the TEST TEST TEST part as soon as I noticed someone added it
(I was hoping that a mail to this mailing list with more details will follow).
I will remove it from wiki.

 cannot find/see them. I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).

I reported bug reports, thanks

 Regarding the transition, the Java packaging team has both git and svn
 repositories. Maybe the DPMT can do the same starting with my package
 in the path suggested by the Wiki.

https://lists.debian.org/debian-python/2013/02/msg00123.html
-- 
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


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114135527.go4...@sts0.p1otr.com



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Barry Warsaw
On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:

I've used git-buildpackage with git-svn on submodules of the DPMT SVN
repo without too many difficulties so far.

I need to spend more time playing with git-bp, but last time I looked at it
(cannot remember which package), I had a lot of trouble unless the package
repo was organized Just Right.  One nice thing about svn-bp is that it pretty
much just works with a checked out working directory, even when you have local
uncommitted changes (--svn-ignore-new).

git-bp OTOH required a specific set of branches inside the repo to stitch
everything together and if those were missing, it failed miserably.  I could
be totally wrong about that, or I could have just been using the tool
incorrectly.

I've mostly made my peace with git, so in theory I wouldn't be opposed to the
team switching, but I still think it's not a good idea to have some team
packages in git and the bulk in svn.  I value the ability to use the same
tools and workflows for all team maintained packages.

I'm not motivated enough to do any work on such a transition itself, so I
think those who really want to switch to git need to work out a plan.  That
would include test repos, documentation updates, transition plans, educating
team members, fielding questions, fixing problems, etc.  I would personally be
supportive, and would be willing to review material and test out recipes.  But
I think this is going to require a few committed people to do some heavily
lifting over an extended period of time to make sure such a transition was
smooth and so that everyone on this team was comfortable with the new way of
doing things.

That's just my opinion, of course.
-Barry


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114093100.3da46...@anarchist.wooz.org



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Hans-Christoph Steiner


On 01/14/2014 09:31 AM, Barry Warsaw wrote:
 On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:
 
 I've used git-buildpackage with git-svn on submodules of the DPMT SVN
 repo without too many difficulties so far.
 
 I need to spend more time playing with git-bp, but last time I looked at it
 (cannot remember which package), I had a lot of trouble unless the package
 repo was organized Just Right.  One nice thing about svn-bp is that it pretty
 much just works with a checked out working directory, even when you have local
 uncommitted changes (--svn-ignore-new).
 
 git-bp OTOH required a specific set of branches inside the repo to stitch
 everything together and if those were missing, it failed miserably.  I could
 be totally wrong about that, or I could have just been using the tool
 incorrectly.
 
 I've mostly made my peace with git, so in theory I wouldn't be opposed to the
 team switching, but I still think it's not a good idea to have some team
 packages in git and the bulk in svn.  I value the ability to use the same
 tools and workflows for all team maintained packages.
 
 I'm not motivated enough to do any work on such a transition itself, so I
 think those who really want to switch to git need to work out a plan.  That
 would include test repos, documentation updates, transition plans, educating
 team members, fielding questions, fixing problems, etc.  I would personally be
 supportive, and would be willing to review material and test out recipes.  But
 I think this is going to require a few committed people to do some heavily
 lifting over an extended period of time to make sure such a transition was
 smooth and so that everyone on this team was comfortable with the new way of
 doing things.
 
 That's just my opinion, of course.
 -Barry

I know what you mean about it having a brittle setup, but git-buildpackage has
improved a lot over the past couple of years.  One key thing that helps when
using git-buildpackage in a team setting (pkg-multimedia is a good example) is
having a standard debian/gbp.conf that configures everything in a standard way
for that team.

For example, it would be great to include a debian/gbp.conf that sets up the
git-svn stuff and check that into svn projects.  Then people can easily use
git-buildpackage and still commit to svn repos.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d55426.6030...@at.or.at



Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Hans-Christoph Steiner


On 01/14/2014 08:24 AM, Alexandre Rossi wrote:
 Hi,
 
 My goal is to maintain sockjs-twisted (#735154).

 the problem is... we don't use git, not yet at least (nobody had time to
 propose a transition)
 
 The Wiki page[1] suggests there are some git repositories, but I
 cannot find/see them. I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).
 
 Regarding the transition, the Java packaging team has both git and svn
 repositories. Maybe the DPMT can do the same starting with my package
 in the path suggested by the Wiki.
 
 Advice?
 
 Alex
 
 [1] https://wiki.debian.org/Teams/PythonModulesTeam/

I'm a fan of a gradual transition like this, with people switching or setting
up git repos as they can.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d55342.5060...@at.or.at



Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

2014-01-14 Thread Olivier Berger
Barry Warsaw ba...@debian.org writes:

 On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:

I've used git-buildpackage with git-svn on submodules of the DPMT SVN
repo without too many difficulties so far.

 git-bp OTOH required a specific set of branches inside the repo to stitch
 everything together and if those were missing, it failed miserably.  I could
 be totally wrong about that, or I could have just been using the tool
 incorrectly.


It more or less requires only 2 branches : upstream (when you
want to track upstream sources) and master (or debian) for the packaging
source.

But for repos of DPMT which won't track upstream code in the SVN, you
only need to manage the debian/ subdir on the master branch which
correspons to the trunk, so that means that git svn clone --std-layout
basically sets things up for you.

Now, if you both want to track upstream sources from origin/master on
local upstream/ branch and svn's trunk on local master branch, then,
yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges
now and then.

In any case, reading
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html
more or less covers all the cases I've played with so far, AFAICT.

YMMV ;-)

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877ga2v9xj@inf-8660.int-evry.fr



Joining the DPMT and git.debian.org access

2014-01-13 Thread Alexandre Rossi
Hi,

I'd like to join the Debian python modules team.

My goal is to maintain sockjs-twisted (#735154).

My alioth username is niol-guest.

Thanks,

Alex


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAM79t8FL_WDvXZvxFPr_QD=rpgfmoy4q-kqmtbfasgc+y1r...@mail.gmail.com



Joining the DPMT (Bug#551038: ITP: python-scrapy -- Python web scraping and crawling framework)

2009-10-15 Thread Ignace Mouzannar
Hello,

On Thu, Oct 15, 2009 at 10:54, Sandro Tosi mo...@debian.org wrote:
 Hi Ignace,
 consider joining DPMT[1] and maintain the package there.

I would be glad to maintain the python-scrapy package [1] through the
DPMT; and of course help out the team with other Python packages.

My Alioth login is: ghantoos-guest.

Thank you for the proposition.

Kind regards,
 Ignace M

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551038


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org