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.


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ý


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ý


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



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


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



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


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 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