Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #7690 > unrolled thread

Python Policy

Back to article view | Back to linux.debian.maint.python

Contents

  Python Policy Barry Warsaw <barry@debian.org> - 2015-10-19 19:40 +0200
    Re: Python Policy Scott Kitterman <debian@kitterman.com> - 2015-10-19 20:50 +0200
    Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:10 +0200
      Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:30 +0200
        Re: Python Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-19 21:40 +0200
          Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:50 +0200
      Re: Python Policy Brian May <bam@debian.org> - 2015-10-20 00:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 00:40 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:50 +0200
            Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:10 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:40 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:00 +0200
    Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 23:30 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 22:20 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 23:00 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-20 23:10 +0200
          Re: Python Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-21 02:20 +0200
            Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 02:50 +0200
            Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-21 10:00 +0200
              Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 16:00 +0200
                Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:30 +0200
                  Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-22 11:40 +0200
                    Re: DPMT Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 12:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 23:40 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 03:00 +0200
            Re: Python Policy Vincent Bernat <bernat@debian.org> - 2015-10-21 10:40 +0200
              Re: Python Policy Brian May <brian@microcomaustralia.com.au> - 2015-10-21 11:50 +0200
                PyPI wheels (was Re: Python Policy) Barry Warsaw <barry@debian.org> - 2015-10-21 16:00 +0200
                  Re: PyPI wheels (was Re: Python Policy) Ian Cordasco <graffatcolmingov@gmail.com> - 2015-10-21 16:50 +0200
                    Re: PyPI wheels (was Re: Python Policy) Jeremy Stanley <fungi@yuggoth.org> - 2015-10-21 17:50 +0200
              Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 15:50 +0200
            Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-21 14:10 +0200
              Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-21 15:50 +0200
                Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-21 16:20 +0200
                  Re: DPMT Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-21 23:40 +0200
                    Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-22 01:00 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-23 01:40 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-23 01:40 +0200
    Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 00:00 +0200
      Re: DPMT Policy Brian May <bam@debian.org> - 2015-10-20 00:30 +0200
      Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:10 +0200
        Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:10 +0200
          Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 23:40 +0200
    Re: Python Policy Brian May <bam@debian.org> - 2015-10-20 00:00 +0200

Page 1 of 3  [1] 2 3  Next page →

#7690 — Python Policy

[Multipart message — attachments visible in raw view] — view raw

So we currently have several places where we have team policy described.

* The Debian wiki
  https://wiki.debian.org/Python and subpages

* Another wiki page:
  https://wiki.debian.org/Teams/PythonModulesTeam

* https://www.debian.org/doc/packaging-manuals/python-policy/
  which comes from the python-defaults (*not* python3-defaults!) in the bzr
  repo at
  http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian

* "PMPT" policy
  http://python-modules.alioth.debian.org/
  git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
  except that that page specifically isn't represented in the git repo, only
  policy.rst

and maybe more.  This is crazy!  We really need to consolidate all this
information.

That said, I did a pass through policy.rst in the git repo above and pushed
the 'git-policy' branch for review.  `git diff master` to see the proposed
changes.  Here's a summary:

* PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian Python
  Modules Team and rarely if ever Python Modules Packaging Team any more.
  Another opportunity for more consistency.

* Clarified slightly the wording in policy differences between
  team-in-Maintainer and team-in-Uploaders.

* Remove all the references to Subversion and add a short blurb about Git,
  pointing to the GitPackaging wiki page.

Cheers,
-Barry

[toc] | [next] | [standalone]

#7691

On October 19, 2015 1:31:37 PM EDT, Barry Warsaw <barry@debian.org> wrote:
>So we currently have several places where we have team policy
>described.
>
>* The Debian wiki
>  https://wiki.debian.org/Python and subpages
>
>* Another wiki page:
>  https://wiki.debian.org/Teams/PythonModulesTeam
>
>* https://www.debian.org/doc/packaging-manuals/python-policy/
>which comes from the python-defaults (*not* python3-defaults!) in the
>bzr
>  repo at
> http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
>* "PMPT" policy
>  http://python-modules.alioth.debian.org/
>  git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>except that that page specifically isn't represented in the git repo,
>only
>  policy.rst
>
>and maybe more.  This is crazy!  We really need to consolidate all this
>information.
>
>That said, I did a pass through policy.rst in the git repo above and
>pushed
>the 'git-policy' branch for review.  `git diff master` to see the
>proposed
>changes.  Here's a summary:
>
>* PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian
>Python
>Modules Team and rarely if ever Python Modules Packaging Team any more.
>  Another opportunity for more consistency.
>
>* Clarified slightly the wording in policy differences between
>  team-in-Maintainer and team-in-Uploaders.
>
>* Remove all the references to Subversion and add a short blurb about
>Git,
>  pointing to the GitPackaging wiki page.
>
>Cheers,
>-Barry

That looks good.  The actual Python policy needs to remain separate.  That's something intended for the entire archive and not just the team.

Scott K

[toc] | [prev] | [next] | [standalone]

#7692

[Barry Warsaw, 2015-10-19]
> So we currently have several places where we have team policy described.

no.

Debian Python Policy¹ is something every single packages that extends
Python should follow. There are many teams (more than 4) each of them
can have their own policy that extends DPP.

Please do not confuse DPMT with this mythic "Python team" which doesn't
exist.

> * The Debian wiki
>   https://wiki.debian.org/Python and subpages

wiki is something everyone can edit. It's a place that can help with
various tasks, it can even be a place where policy is prepared, but it's
not a place to store official documents.

> * Another wiki page:
>   https://wiki.debian.org/Teams/PythonModulesTeam

this is wiki page, not a policy

> * https://www.debian.org/doc/packaging-manuals/python-policy/
>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>   repo at
>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian

this it THE policy (¹)

> * "PMPT" policy
>   http://python-modules.alioth.debian.org/
>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>   except that that page specifically isn't represented in the git repo, only
>   policy.rst

DPMT and PAPT are two different things

> and maybe more.  This is crazy!  We really need to consolidate all this
> information.

why? again, if you want to describe common Python related things - DPP
is the place, if it's team specific, please allow each team to have
their own rules.

> That said, I did a pass through policy.rst in the git repo above and pushed
> the 'git-policy' branch for review.  `git diff master` to see the proposed
> changes.  Here's a summary:

please paste the diff here, on this mailing list

> * PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian Python
>   Modules Team and rarely if ever Python Modules Packaging Team any more.
>   Another opportunity for more consistency.

+1

> * Clarified slightly the wording in policy differences between
>   team-in-Maintainer and team-in-Uploaders.

will comment later, once I have access to git repo

> * Remove all the references to Subversion and add a short blurb about Git,
>   pointing to the GitPackaging wiki page.

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

[toc] | [prev] | [next] | [standalone]

#7693

[Piotr Ożarowski, 2015-10-19]
> DPMT and PAPT are two different things

ups, PMPT != PAPT :)

anyway, there are only documents each DPMT should know:
* https://www.debian.org/doc/packaging-manuals/python-policy/
* https://python-modules.alioth.debian.org/policy.html

everything else can help, but if in doubt: check in above documents
-- 
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

[toc] | [prev] | [next] | [standalone]

#7695

Piotr Ożarowski <piotr@debian.org> writes:

> [Piotr Ożarowski, 2015-10-19]
> > DPMT and PAPT are two different things
>
> ups, PMPT != PAPT :)

So which of the following are redundant, and which names are canonical?

* Debian Python Modules Team
* Python Module Packaging Team
* Debian Python Maintainers Team

For symmetry with “Python Application Packaging Team” I was under the
impression this is the “Python Module Packaging Team”.

-- 
 \       “If you always want the latest and greatest, then you have to |
  `\          buy a new iPod at least once a year.” —Steve Jobs, MSNBC |
_o__)                                             interview 2006-05-25 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#7696

[Ben Finney, 2015-10-19]
> So which of the following are redundant, and which names are canonical?
> 
> * Debian Python Modules Team
> * Python Module Packaging Team

these two are the same thing

> * Debian Python Maintainers Team

this doesn't exist AFAIK

> For symmetry with “Python Application Packaging Team” I was under the
> impression this is the “Python Module Packaging Team”.

it's completely different thing, f.e. we package applications in PAPT
-- 
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

[toc] | [prev] | [next] | [standalone]

#7703

Piotr Ożarowski <piotr@debian.org> writes:

>> * The Debian wiki
>>   https://wiki.debian.org/Python and subpages
>
> wiki is something everyone can edit. It's a place that can help with
> various tasks, it can even be a place where policy is prepared, but it's
> not a place to store official documents.
>
>> * Another wiki page:
>>   https://wiki.debian.org/Teams/PythonModulesTeam
>
> this is wiki page, not a policy
>
>> * https://www.debian.org/doc/packaging-manuals/python-policy/
>>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>>   repo at
>>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
> this it THE policy (¹)
>
>> * "PMPT" policy
>>   http://python-modules.alioth.debian.org/
>>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>>   except that that page specifically isn't represented in the git repo, only
>>   policy.rst
>
> DPMT and PAPT are two different things

Are DAPT and PAPT the same thing?

This information should be documented somewhere.

In my words, for Debian project there is a wiki and a policy. For each
team there is a wiki and policy that apply for that team.

The wikis are not official policy, only the policy if official policy.

I don't understand why we need two teams for Python in Debian. DPMT and
DAPT share this mailing list. The only significant difference I see is
one is using git and the other is using subversion.

The description on the DAPT wiki says "We are taking care of Python
applications, i.e. end user programs written in Python that usually do
not provide public modules. We are not about packaging Python modules or
Python interpreter."

There are packages that do not provide public modules that are aimed at
developers. I imagine there are also packages that are end user
applications that do provide public modules, for end user
programming. These end user's may require the first group of packages
aimed at developers too.
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#7704

[Brian May, 2015-10-20]
> Are DAPT and PAPT the same thing?

no such thing as DAPT

> This information should be documented somewhere.

should we also document that we're not OpenStack Packaging Team?

> In my words, for Debian project there is a wiki and a policy. For each
> team there is a wiki and policy that apply for that team.
> 
> The wikis are not official policy, only the policy if official policy.
> 
> I don't understand why we need two teams for Python in Debian. DPMT and
> DAPT share this mailing list. The only significant difference I see is
> one is using git and the other is using subversion.

there is one HUGE difference, one is about packaging MODULES and the
other one is packaging APPLICATIONS. One provides python-, python3-
and/or pypy- packages, the other cannot do that.

> There are packages that do not provide public modules that are aimed at
> developers. I imagine there are also packages that are end user
> applications that do provide public modules, for end user
> programming. These end user's may require the first group of packages
> aimed at developers too.

if something installs into dist-packages, it should (I'd make it a
"must", but it's just me) provide python-/python3-/pypy- binary
package. Python application should not (again, "must" is much better
here IMO) pollute global Python namespace
-- 
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

[toc] | [prev] | [next] | [standalone]

#7716

On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote:

>should we also document that we're not OpenStack Packaging Team?

Or zope-packaging? <wink>.  Agreed that there are different teams here, but I
am hoping that we can do some consolidation.  E.g. I posted on the zope list
that I'd like to pull those packages into DPMT.  I heard *zero* responses, so
I'm honestly not sure there's still anybody who cares about that team.

(I'll post on the wider debian lists to follow up, but I will take silence as
assent at some point.)

>there is one HUGE difference, one is about packaging MODULES and the
>other one is packaging APPLICATIONS. One provides python-, python3-
>and/or pypy- packages, the other cannot do that.

Although there is often overlap.  Some packages intentionally provide both
libraries and applications.  These usually end up in DPMT, which I think is
fine.

I also think it would be fine to *eventually* merge the two teams.  I suspect
there isn't really much benefit to keeping them separate and a lot of
unnecessary cost.  Is there anybody on PAPT who doesn't want to be on DPMT?
Is there any reason why team policy couldn't be expanded to describe the few
differences between packaging libraries and pure-applications?

>> There are packages that do not provide public modules that are aimed at
>> developers. I imagine there are also packages that are end user
>> applications that do provide public modules, for end user
>> programming. These end user's may require the first group of packages
>> aimed at developers too.
>
>if something installs into dist-packages, it should (I'd make it a
>"must", but it's just me) provide python-/python3-/pypy- binary
>package. Python application should not (again, "must" is much better
>here IMO) pollute global Python namespace

I'm not sure I'd go as far as MUST, but aside from that, there's no inherent
reason IMHO why these two policies and procedures couldn't co-exist within the
same team.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7718

[Barry Warsaw, 2015-10-20]
> I also think it would be fine to *eventually* merge the two teams.  I suspect
> there isn't really much benefit to keeping them separate and a lot of
> unnecessary cost.  Is there anybody on PAPT who doesn't want to be on DPMT?

/me puts his PAPT admin hat on

WHAT? You want us to learn about all these weird package name rules? All
these transitions? All these so name abi ext whatever weird tags? GO AWAY!

/me puts his DPMT admin hat on

WHAT? Do you know these guys despise our belowed dist-packages? And they
have weird package names that do not start with python-! GO AWAY!

;P

> I'm not sure I'd go as far as MUST, but aside from that, there's no inherent
> reason IMHO why these two policies and procedures couldn't co-exist within the
> same team.

DPMT is already too big, please don't add applications to make it even
more complicated

-- 
evil general Piotr

[toc] | [prev] | [next] | [standalone]

#7715

On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote:

>Debian Python Policy¹ is something every single packages that extends
>Python should follow. There are many teams (more than 4) each of them
>can have their own policy that extends DPP.

This is an important distinction that I don't think is really captured
anywhere.  Let me rephrase it to see if I'm capturing your sentiment.

There is Debian Python Policy which describes the standards for publishing
Python libraries and applications within the Debian archive.  It is a Debian
Project-wide standard, irrespective of which team, if any, is maintaining the
Python package.

There is the DPMT, a team for co-maintaining Python libraries.  It has its own
policy document for how those libraries are maintained, and adheres to DPP for
publishing those libraries in the archive.

There is the PAPT, a team for co-maintaining Python applications.  While there
may be overlap with DPMT (e.g. some upstream packages provide both libraries
and applications), PAPT has its own policy document for how those applications
are maintained, and adheres to DPP for publishing those applications in the
archive.

>> and maybe more.  This is crazy!  We really need to consolidate all this
>> information.
>
>why? again, if you want to describe common Python related things - DPP
>is the place, if it's team specific, please allow each team to have
>their own rules.

My concern here is discoverability and knowing the procedures for making
changes to the various policies.  Am I the only one who thinks that it's
harder than necessary to find the right information?

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7717

[Barry Warsaw, 2015-10-20]
> On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote:
> 
> >Debian Python Policy¹ is something every single packages that extends
> >Python should follow. There are many teams (more than 4) each of them
> >can have their own policy that extends DPP.
> 
> This is an important distinction that I don't think is really captured
> anywhere.  Let me rephrase it to see if I'm capturing your sentiment.
> 
> There is Debian Python Policy which describes the standards for publishing
> Python libraries and applications within the Debian archive.  It is a Debian
> Project-wide standard, irrespective of which team, if any, is maintaining the
> Python package.
> 
> There is the DPMT, a team for co-maintaining Python libraries.  It has its own
> policy document for how those libraries are maintained, and adheres to DPP for
> publishing those libraries in the archive.

correct

> There is the PAPT, a team for co-maintaining Python applications.  While there
> may be overlap with DPMT (e.g. some upstream packages provide both libraries
> and applications), PAPT has its own policy document for how those applications
> are maintained, and adheres to DPP for publishing those applications in the
> archive.

just to make it even clearer: if package provides a tiny script that
uses library, it should go to DPMT. If package provides an app and a
tiny library (I'm thinking about real library, not just those where
maintainer forgot to set --install-lib correctly and installs app into
dist-packages) - it's a PAPT candidate.

--install-lib is the main difference between DPMT and PAPT. There are
different set of problems when you install into dist-packages and outside
this directory.
-- 
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

[toc] | [prev] | [next] | [standalone]

#7697

[Multipart message — attachments visible in raw view] — view raw

| diff --git a/policy.rst b/policy.rst
| index c09f03a..9a9abb4 100644
| --- a/policy.rst
| +++ b/policy.rst
| @@ -1,20 +1,19 @@
| -========================================
| - Python Modules Packaging Team - Policy
| -========================================
| +=====================================
| + Debian Python Modules Team - Policy
| +=====================================
|  
| -:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>
| +:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>, Barry Warsaw <barry@debian.org>
|  :License: GNU GPL v2 or later
|  
|  :Introduction:
| -  Python Modules Packaging Team aims to improve the python modules situation
| -  in Debian, by packaging available modules that may be useful and providing
| -  a central location for packages maintained by a team, hence improving
| -  responsiveness, integration and standardization.
| +  The Debian Python Modules Team (DPMT) aims to improve the Python modules
| +  situation in Debian, by packaging available modules that may be useful and
| +  providing a central location for packages maintained by a team, hence
| +  improving responsiveness, integration, and standardization.
|  
| -  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
| -  GForge installation. We currently have a SVN repository and a mailing list
| -  whose email address can be used in the Maintainer field on co-maintained
| -  packages.
| +  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
| +  currently have a git repository and a mailing list whose email address can

+1 to all above

| +  be used in the ``Maintainer`` field on co-maintained packages.

I suggest:

s/``Maintainer`` field/``Maintainer`` or ``Uploaders`` fields/

|  
|    For more information send a message to: debian-python@lists.debian.org
|  
| @@ -24,16 +23,17 @@
|  Joining the team
|  ----------------
|  
| -The team is open to any python-related package maintainer. To be added on
| +The team is open to any Python-related package maintainer. To be added on
|  the team, please send your request on debian-python@lists.debian.org
|  indicate why you want to join the team: maintain your current packages
|  within the team, help maintain some specific packages, etc.

how about adding (taken from the wiki :) this:

  In your email please state that you have read
  https://python-modules.alioth.debian.org/policy.html and
  that you accept it.

| -Don't forget to indicate your Alioth login !
| +Don't forget to indicate your Alioth login!
|  
| -Any Debian developer who wishes to integrate his packages in the team can do so
| -without requesting access (as the repository is writable by all DD). If one
| +Any Debian developer who wishes to integrate his packages in the team can do
| +so without requesting access (as the repository is writable by all DD). If one
|  wants to be more involved in the team, we still recommend requesting_ access
| -so that he appears in the public member list displayed on Alioth's project page.
| +so that they appear in the public member list displayed on Alioth's project
| +page.
|  
|  The team accepts all contributors and is not restricted to Debian developers.
|  Several Debian developers of the team will gladly sponsor packages of non-DD
| @@ -48,71 +48,35 @@ Maintainership
|  --------------
|  
|  A package maintained within the team should have the name of the team either
| -in the Maintainer field or in the Uploaders field.
| +in the ``Maintainer`` field or in the ``Uploaders`` field.
|  
|  Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
|  
|  This enables the team to have an overview of its packages on the DDPO_website_.
|  
| -* Team in Maintainers is a strong statement that fully collaborative
| -  maintenance is preferred. Anyone can commit to the vcs and upload as
| -  needed. A courtesy email to Uploaders can be nice but not required.
| +* Team in ``Maintainers`` is a strong statement that fully collaborative
| +  maintenance is preferred. Anyone can commit to the git repository and upload
| +  as needed. A courtesy email to ``Uploaders`` can be nice but not required.
|  
| -* Team in Uploaders is a weak statement of collaboration. Help in maintaining
| -  the package is appreciated, commits to vcs are freely welcomed, but before
| -  uploading, please contact the Maintainer for the green light.
| +* Team in ``Uploaders`` is a weak statement of collaboration. Help in
| +  maintaining the package is appreciated, commits to the git repository are
| +  freely welcomed, but before uploading, please contact the ``Maintainer`` for
| +  the green light.
|  
|  Team members who have broad interest should subscribe to the mailing list
|  python-modules-team@lists.alioth.debian.org whereas members who are only
|  interested in some packages should use the Package Tracking System to
|  follow the packages.
|  
| ----------------------
| -Subversion Procedures
| ----------------------
| -
| -We're using a Subversion repository to maintain all the packages, then if you're not
| -already using it you will need to install svn-buildpackage.
| -
| -*The repository layout:*
| -
| -metainfo/
| -  Ignore this directory (reserved for future usage).
| -
| -packages/
| -  The source packages are here.
| -
| -  package-foo
| -      branches
| -         If you or someone wants to play with a package possible breaking the trunk, give it a name and do it here.
| -      tags
| -         For each release, a tag. More information below.
| -      trunk
| -         That's where the main development happens, it should contain only the debian/ subdirectory part of a package.
| -
| -www/
| -  Documents and stuff that will be or are being published online in our website.
| -
| -
| -Hints:
| -======
| -* To keep your package tree clean as pointed out above, always :code:`svn-inject` your packages using :code:`-o` argument.
| -* If you svn-inject'ed a package without :code:`-o`, you should remove upstream sources and run :code:`svn propset mergeWithUpstream 1 debian/`.
| -* Since you are keeping only debian/ directory in the svn tree, you need to put the 'package-foo'_'version'.orig.tar.gz in tarballs/ a directory above the package, and svn-buildpackage will do the merge for you. More information about this in the svn-buildpackage howto at /usr/share/doc/svn-buildpackage/.
| -* After upload, tag the latest revision running :code:`svn-buildpackage --svn-tag-only` into 'package-foo' directory.
| -* You can revert the changelog changes after tagging, running :code:`svn revert debian/changelog`.
| -* If you're a pbuilder user, you can invoke it using :code:`svn-buildpackage --svn-builder pdebuild <args>`.
| -
| -For more information on how to maintain packages within the repository with svn-buildpackage:
| -`http://pkg-perl.alioth.debian.org/subversion.html <https://web.archive.org/web/20141027193341/http://pkg-perl.alioth.debian.org/subversion.html>`_
| -
| -Please note that python-modules URLs are different than pkg-perl ones:
| -
| -* svn+ssh://login@svn.debian.org/svn/python-modules/packages/
| -* svn://svn.debian.org/python-modules/packages/
| -* http://anonscm.debian.org/viewvc/python-modules

+1 for all above changes

| +--------------
| +Git Procedures
| +--------------
|  
| -Moreover, python-modules still use the default layout: don't pass :code:`-l 2` to :code:`svn-inject`.
| +As of October 9, 2015, the DPMT uses git as the version control system for all
| +packages, and git-dpm as the patch management regime.  Details of the
| +procedures, standards for branches and tags, and common workflows are
| +maintained on the `Debian wiki <https://wiki.debian.org/Python/GitPackaging>`_
| +page.

I'm against this change. If we want all team packages to follow some
rules, these rules need to be in policy document, not on the wiki page.
I don't want this page to be removed, policy can even point to it, but I
want it to be crystal clear that the binding document is the policy, not
any other document in the internet (even if it's very helpful).

What am I missing here is a set of branch/tag names and procedures
(f.e. I didn't know that git pull is not enough and I should gbp pull or
update pristine-tar branch by hand) and debian/patches related set of rules
(do we require git-dpm or can one use plain quilt of some other rules
are followed?)

|  
|  -----------------
|  Quality Assurance
| @@ -127,7 +91,7 @@ packaging tools, etc.
|  License
|  -------
|  
| -Copyright (c) 2005-2015 Python Modules Packaging Team. All rights reserved.
| +Copyright (c) 2005-2015 Debian Python Modules Team. All rights reserved.
|  This document is free software; you may redistribute it and/or modify
|  it under the same terms as GNU GPL v2 or later.
|  
| 

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

[toc] | [prev] | [next] | [standalone]

#7714

[Multipart message — attachments visible in raw view] — view raw

Thanks for the feedback Piotr.  I've made all the changes you suggest, except
one.  I'll discuss that below and include an updated diff against master.

On Oct 19, 2015, at 11:26 PM, Piotr Ożarowski wrote:

>I'm against this change. If we want all team packages to follow some
>rules, these rules need to be in policy document, not on the wiki page.
>I don't want this page to be removed, policy can even point to it, but I
>want it to be crystal clear that the binding document is the policy, not
>any other document in the internet (even if it's very helpful).
>
>What am I missing here is a set of branch/tag names and procedures
>(f.e. I didn't know that git pull is not enough and I should gbp pull or
>update pristine-tar branch by hand) and debian/patches related set of rules
>(do we require git-dpm or can one use plain quilt of some other rules
>are followed?)

Here's my concern: I don't want too much duplication of information in
multiple locations.  That's a sure recipe for bitrot, and I know no one wants
to have to edit information in more than one place.

Until now, the wiki has been the more convenient place to make these changes,
but I agree in principle with your opinion that some of that information must
be captured in policy.  So here's what I suggest.

For standards we must all adhere to, such as branch and tag names, source-full
branches, the use of git-dpm, and maybe a few other points, these should go in
policy.rst.

The wiki page points to the policy document but doesn't otherwise describe
those details.  That way, there's only one place to change when/if these
standards change.

The wiki then goes on to describe common workflows, how to create new
repositories, mr, etc.  These aren't specifically policy related but are
mostly there to help developers get started, or handle tricky situations.

If you're in agreement with that split, I'll update both the policy and wiki.

Cheers,
-Barry

diff --git a/policy.rst b/policy.rst
index c09f03a..aed57c0 100644
--- a/policy.rst
+++ b/policy.rst
@@ -1,19 +1,19 @@
-========================================
- Python Modules Packaging Team - Policy
-========================================
+=====================================
+ Debian Python Modules Team - Policy
+=====================================
 
-:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>
+:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>, Barry Warsaw <barry@debian.org>
 :License: GNU GPL v2 or later
 
 :Introduction:
-  Python Modules Packaging Team aims to improve the python modules situation
-  in Debian, by packaging available modules that may be useful and providing
-  a central location for packages maintained by a team, hence improving
-  responsiveness, integration and standardization.
-
-  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
-  GForge installation. We currently have a SVN repository and a mailing list
-  whose email address can be used in the Maintainer field on co-maintained
+  The Debian Python Modules Team (DPMT) aims to improve the Python modules
+  situation in Debian, by packaging available modules that may be useful and
+  providing a central location for packages maintained by a team, hence
+  improving responsiveness, integration, and standardization.
+
+  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
+  currently have a git repository and a mailing list whose email address can
+  be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained
   packages.
 
   For more information send a message to: debian-python@lists.debian.org
@@ -24,16 +24,21 @@
 Joining the team
 ----------------
 
-The team is open to any python-related package maintainer. To be added on
-the team, please send your request on debian-python@lists.debian.org
-indicate why you want to join the team: maintain your current packages
-within the team, help maintain some specific packages, etc.
-Don't forget to indicate your Alioth login !
+The team is open to any Python-related package maintainer. To be added to
+the team, please send your request to debian-python@lists.debian.org.  Include
+the following in your request:
 
-Any Debian developer who wishes to integrate his packages in the team can do so
-without requesting access (as the repository is writable by all DD). If one
+* Why you want to join the team: e.g. maintain your current packages within
+  the team, help maintain some specific packages, etc.
+* Your Alioth login.
+* A statement that you have read
+  https://python-modules.alioth.debian.org/policy.html and that you accept it.
+
+Any Debian developer who wishes to integrate his packages in the team can do
+so without requesting access (as the repository is writable by all DD). If one
 wants to be more involved in the team, we still recommend requesting_ access
-so that he appears in the public member list displayed on Alioth's project page.
+so that they appear in the public member list displayed on Alioth's project
+page.
 
 The team accepts all contributors and is not restricted to Debian developers.
 Several Debian developers of the team will gladly sponsor packages of non-DD
@@ -48,71 +53,35 @@ Maintainership
 --------------
 
 A package maintained within the team should have the name of the team either
-in the Maintainer field or in the Uploaders field.
+in the ``Maintainer`` field or in the ``Uploaders`` field.
 
 Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
 
 This enables the team to have an overview of its packages on the DDPO_website_.
 
-* Team in Maintainers is a strong statement that fully collaborative
-  maintenance is preferred. Anyone can commit to the vcs and upload as
-  needed. A courtesy email to Uploaders can be nice but not required.
+* Team in ``Maintainers`` is a strong statement that fully collaborative
+  maintenance is preferred. Anyone can commit to the git repository and upload
+  as needed. A courtesy email to ``Uploaders`` can be nice but not required.
 
-* Team in Uploaders is a weak statement of collaboration. Help in maintaining
-  the package is appreciated, commits to vcs are freely welcomed, but before
-  uploading, please contact the Maintainer for the green light.
+* Team in ``Uploaders`` is a weak statement of collaboration. Help in
+  maintaining the package is appreciated, commits to the git repository are
+  freely welcomed, but before uploading, please contact the ``Maintainer`` for
+  the green light.
 
 Team members who have broad interest should subscribe to the mailing list
 python-modules-team@lists.alioth.debian.org whereas members who are only
 interested in some packages should use the Package Tracking System to
 follow the packages.
 
----------------------
-Subversion Procedures
----------------------
-
-We're using a Subversion repository to maintain all the packages, then if you're not
-already using it you will need to install svn-buildpackage.
-
-*The repository layout:*
-
-metainfo/
-  Ignore this directory (reserved for future usage).
-
-packages/
-  The source packages are here.
-
-  package-foo
-      branches
-         If you or someone wants to play with a package possible breaking the trunk, give it a name and do it here.
-      tags
-         For each release, a tag. More information below.
-      trunk
-         That's where the main development happens, it should contain only the debian/ subdirectory part of a package.
-
-www/
-  Documents and stuff that will be or are being published online in our website.
-
-
-Hints:
-======
-* To keep your package tree clean as pointed out above, always :code:`svn-inject` your packages using :code:`-o` argument.
-* If you svn-inject'ed a package without :code:`-o`, you should remove upstream sources and run :code:`svn propset mergeWithUpstream 1 debian/`.
-* Since you are keeping only debian/ directory in the svn tree, you need to put the 'package-foo'_'version'.orig.tar.gz in tarballs/ a directory above the package, and svn-buildpackage will do the merge for you. More information about this in the svn-buildpackage howto at /usr/share/doc/svn-buildpackage/.
-* After upload, tag the latest revision running :code:`svn-buildpackage --svn-tag-only` into 'package-foo' directory.
-* You can revert the changelog changes after tagging, running :code:`svn revert debian/changelog`.
-* If you're a pbuilder user, you can invoke it using :code:`svn-buildpackage --svn-builder pdebuild <args>`.
-
-For more information on how to maintain packages within the repository with svn-buildpackage:
-`http://pkg-perl.alioth.debian.org/subversion.html <https://web.archive.org/web/20141027193341/http://pkg-perl.alioth.debian.org/subversion.html>`_
-
-Please note that python-modules URLs are different than pkg-perl ones:
-
-* svn+ssh://login@svn.debian.org/svn/python-modules/packages/
-* svn://svn.debian.org/python-modules/packages/
-* http://anonscm.debian.org/viewvc/python-modules/
+--------------
+Git Procedures
+--------------
 
-Moreover, python-modules still use the default layout: don't pass :code:`-l 2` to :code:`svn-inject`.
+As of October 9, 2015, the DPMT uses git as the version control system for all
+packages, and git-dpm as the patch management regime.  Details of the
+procedures, standards for branches and tags, and common workflows are
+maintained on the `Debian wiki <https://wiki.debian.org/Python/GitPackaging>`_
+page.
 
 -----------------
 Quality Assurance
@@ -127,7 +96,7 @@ packaging tools, etc.
 License
 -------
 
-Copyright (c) 2005-2015 Python Modules Packaging Team. All rights reserved.
+Copyright (c) 2005-2015 Debian Python Modules Team. All rights reserved.
 This document is free software; you may redistribute it and/or modify
 it under the same terms as GNU GPL v2 or later.
 

[toc] | [prev] | [next] | [standalone]

#7720

[Barry Warsaw, 2015-10-20]
> Here's my concern: I don't want too much duplication of information in
> multiple locations.  That's a sure recipe for bitrot, and I know no one wants
> to have to edit information in more than one place.
> 
> Until now, the wiki has been the more convenient place to make these changes,
> but I agree in principle with your opinion that some of that information must
> be captured in policy.  So here's what I suggest.
> 
> For standards we must all adhere to, such as branch and tag names, source-full
> branches, the use of git-dpm, and maybe a few other points, these should go in
> policy.rst.
> 
> The wiki page points to the policy document but doesn't otherwise describe
> those details.  That way, there's only one place to change when/if these
> standards change.
> 
> The wiki then goes on to describe common workflows, how to create new
> repositories, mr, etc.  These aren't specifically policy related but are
> mostly there to help developers get started, or handle tricky situations.
> 
> If you're in agreement with that split, I'll update both the policy and wiki.

if policy describes f.e. tag name convention and our tools create
correct configuration out of the box, then there's no need to mention it
on the wiki so yes, I agree with what you said. I don't even mind to
list only few things in policy now and extend it later, once we figure
out whats best for us (and work on wiki only for now), but at some point
I want a set of rules (a "standard"!) that will make my life as sponsor
easier and this is F*****G important for me. I will leave this team the
moment I have to read README.sources each day when I sponsor a package.
If you want help from me, make it easier for me to review your work.

(most of RFS emails I get contain "RFS: DPMT: foo version" subject and
nothing else, it works for me, I'm lazy and I prefer to read
non-technical books rather than RFS mails :P)
-- 
evil general Piotr

[toc] | [prev] | [next] | [standalone]

#7721

On Oct 20, 2015, at 05:16 PM, Piotr Ożarowski wrote:

>I will leave this team the moment I have to read README.sources each day when
>I sponsor a package.

Nobody wants that! (either you leaving or having to read README.source for
every package).

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7722

[Multipart message — attachments visible in raw view] — view raw

Latest diff against master.  If you're happy with this, I'll merge to master,
update the web page, and trim the wiki.

Cheers,
-Barry

diff --git a/policy.rst b/policy.rst
index c09f03a..123792c 100644
--- a/policy.rst
+++ b/policy.rst
@@ -1,39 +1,44 @@
-========================================
- Python Modules Packaging Team - Policy
-========================================
+=====================================
+ Debian Python Modules Team - Policy
+=====================================
 
-:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>
+:Author: Gustavo Franco <stratus@debian.org>, Raphaël Hertzog <hertzog@debian.org>, Barry Warsaw <barry@debian.org>
 :License: GNU GPL v2 or later
 
 :Introduction:
-  Python Modules Packaging Team aims to improve the python modules situation
-  in Debian, by packaging available modules that may be useful and providing
-  a central location for packages maintained by a team, hence improving
-  responsiveness, integration and standardization.
-
-  PMPT or just python-modules is hosted at alioth.debian.org, the Debian
-  GForge installation. We currently have a SVN repository and a mailing list
-  whose email address can be used in the Maintainer field on co-maintained
+  The Debian Python Modules Team (DPMT) aims to improve the Python modules
+  situation in Debian, by packaging available modules that may be useful and
+  providing a central location for packages maintained by a team, hence
+  improving responsiveness, integration, and standardization.
+
+  The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We
+  currently have a git repository and a mailing list whose email address can
+  be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained
   packages.
 
   For more information send a message to: debian-python@lists.debian.org
 
 .. contents::
 
-----------------
+
 Joining the team
-----------------
+================
 
-The team is open to any python-related package maintainer. To be added on
-the team, please send your request on debian-python@lists.debian.org
-indicate why you want to join the team: maintain your current packages
-within the team, help maintain some specific packages, etc.
-Don't forget to indicate your Alioth login !
+The team is open to any Python-related package maintainer. To be added to
+the team, please send your request to debian-python@lists.debian.org.  Include
+the following in your request:
 
-Any Debian developer who wishes to integrate his packages in the team can do so
-without requesting access (as the repository is writable by all DD). If one
+* Why you want to join the team: e.g. maintain your current packages within
+  the team, help maintain some specific packages, etc.
+* Your Alioth login.
+* A statement that you have read
+  https://python-modules.alioth.debian.org/policy.html and that you accept it.
+
+Any Debian developer who wishes to integrate his packages in the team can do
+so without requesting access (as the repository is writable by all DD). If one
 wants to be more involved in the team, we still recommend requesting_ access
-so that he appears in the public member list displayed on Alioth's project page.
+so that they appear in the public member list displayed on Alioth's project
+page.
 
 The team accepts all contributors and is not restricted to Debian developers.
 Several Debian developers of the team will gladly sponsor packages of non-DD
@@ -43,91 +48,129 @@ discussion list or on #debian-python IRC channel (OFTC network).
 All team members should of course follow the main discussion list:
 debian-python@lists.debian.org
 
---------------
+
 Maintainership
---------------
+==============
 
 A package maintained within the team should have the name of the team either
-in the Maintainer field or in the Uploaders field.
+in the ``Maintainer`` field or in the ``Uploaders`` field.
 
 Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
 
 This enables the team to have an overview of its packages on the DDPO_website_.
 
-* Team in Maintainers is a strong statement that fully collaborative
-  maintenance is preferred. Anyone can commit to the vcs and upload as
-  needed. A courtesy email to Uploaders can be nice but not required.
+* Team in ``Maintainers`` is a strong statement that fully collaborative
+  maintenance is preferred. Anyone can commit to the git repository and upload
+  as needed. A courtesy email to ``Uploaders`` can be nice but not required.
 
-* Team in Uploaders is a weak statement of collaboration. Help in maintaining
-  the package is appreciated, commits to vcs are freely welcomed, but before
-  uploading, please contact the Maintainer for the green light.
+* Team in ``Uploaders`` is a weak statement of collaboration. Help in
+  maintaining the package is appreciated, commits to the git repository are
+  freely welcomed, but before uploading, please contact the ``Maintainer`` for
+  the green light.
 
 Team members who have broad interest should subscribe to the mailing list
 python-modules-team@lists.alioth.debian.org whereas members who are only
 interested in some packages should use the Package Tracking System to
 follow the packages.
 
----------------------
-Subversion Procedures
----------------------
 
-We're using a Subversion repository to maintain all the packages, then if you're not
-already using it you will need to install svn-buildpackage.
+Git Procedures
+==============
+
+As of October 9, 2015, the DPMT uses git as the version control system for all
+packages, and git-dpm as the patch management regime.
+
+Git repositories live on Alioth under the url
+``git+ssh://git.debian.org/git/python-modules/packages/<src-pkg-name>.git``
+To access any source package's repository, use ``gbp clone`` on the above url,
+substituting *src-pkg-name* for the source package name of the package in
+question.
+
+DPMT git repos are **source-full**, meaning they contain both the upstream
+source and the ``debian/`` directory.
+
+DPMT requires upstream tarballs; releases cannot be made from upstream git
+repositories directly.  This is because PyPI contains upstream tarballs, and
+tarballs are what we upload to the Debian archive.
+
+Deviations from this policy are strongly discouraged.  When you must (not want
+to) deviate, you MUST include a ``debian/README.source`` file explaining the
+rationale for the deviation and the details of working with the package's git
+repo.
 
-*The repository layout:*
 
-metainfo/
-  Ignore this directory (reserved for future usage).
+Tools
+-----
 
-packages/
-  The source packages are here.
+``gbp build-package`` is used to build the package, either as a source package
+for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.
+Do *not* create ``quilt`` patches directly.  Instead, use ``git-dpm
+checkout-patched`` to enter a patch branch, edit the files, commit them, and
+then use ``git-dpm update-patches`` to switch back to the master branch, with
+the commits turned into patches.  Use the pseudo header ``Patch-Name`` in the
+commit message to control what the patch file will be named, e.g.::
 
-  package-foo
-      branches
-         If you or someone wants to play with a package possible breaking the trunk, give it a name and do it here.
-      tags
-         For each release, a tag. More information below.
-      trunk
-         That's where the main development happens, it should contain only the debian/ subdirectory part of a package.
+    Patch-Name: fix-the-foo.patch
 
-www/
-  Documents and stuff that will be or are being published online in our website.
+Use ``git-dpm tag`` to tag the repository when you upload a new release of the
+package.  See below for the required tag format.
 
 
-Hints:
-======
-* To keep your package tree clean as pointed out above, always :code:`svn-inject` your packages using :code:`-o` argument.
-* If you svn-inject'ed a package without :code:`-o`, you should remove upstream sources and run :code:`svn propset mergeWithUpstream 1 debian/`.
-* Since you are keeping only debian/ directory in the svn tree, you need to put the 'package-foo'_'version'.orig.tar.gz in tarballs/ a directory above the package, and svn-buildpackage will do the merge for you. More information about this in the svn-buildpackage howto at /usr/share/doc/svn-buildpackage/.
-* After upload, tag the latest revision running :code:`svn-buildpackage --svn-tag-only` into 'package-foo' directory.
-* You can revert the changelog changes after tagging, running :code:`svn revert debian/changelog`.
-* If you're a pbuilder user, you can invoke it using :code:`svn-buildpackage --svn-builder pdebuild <args>`.
+Branch names
+------------
 
-For more information on how to maintain packages within the repository with svn-buildpackage:
-`http://pkg-perl.alioth.debian.org/subversion.html <https://web.archive.org/web/20141027193341/http://pkg-perl.alioth.debian.org/subversion.html>`_
+Currently, we require the following branch names in the git repo:
 
-Please note that python-modules URLs are different than pkg-perl ones:
+* master - The Debianized upstream source directory.  This contains both the
+  upstream source and a ``debian/`` packaging directory.
+* pristine-tar - Contains the standard ``pristine-tar`` deltas.
+* upstream - The un-Debianized upstream source.  This is what you get when you
+  unpack the upstream tarball.
 
-* svn+ssh://login@svn.debian.org/svn/python-modules/packages/
-* svn://svn.debian.org/python-modules/packages/
-* http://anonscm.debian.org/viewvc/python-modules/
+In some cases you may need to have additional branches, such as if you have
+deltas for downstream distributions (e.g. Ubuntu) or need to maintain multiple
+versions for security releases in previous versions of Debian.  In those
+cases, follow the `DEP-14 <http://dep.debian.net/deps/dep14/>`_ guidelines,
+and document them in ``debian/README.source``.
+
+
+Tag format
+----------
+
+Use the following ``git-dpm`` tag formats for the three branches named above.
+Put these lines at the *end* of your ``debian/.git-dpm`` file::
+
+    debianTag="debian/%e%v"
+    patchedTag="patches/%e%v"
+    upstreamTag="upstream/%e%u"
+
+All packages which have been automatically converted from the old Subversion
+repository should already have these lines present, but you will need to add
+them for any new packages.
+
+
+More information
+----------------
+
+Additional information for working with DPMT git repositories, creating new
+repositories, common workflows, and helpful hints, can be found on the
+`Debian wiki <https://wiki.debian.org/Python/GitPackaging>`_
+page.
 
-Moreover, python-modules still use the default layout: don't pass :code:`-l 2` to :code:`svn-inject`.
 
------------------
 Quality Assurance
------------------
+=================
 
 The goal of the team is to maintain all packages as best as possible.
 Thus every member is encouraged to do general QA work on all the
 packages: fix bugs, test packages, improve them to use the latest python
 packaging tools, etc.
 
--------
+
 License
--------
+=======
 
-Copyright (c) 2005-2015 Python Modules Packaging Team. All rights reserved.
+Copyright (c) 2005-2015 Debian Python Modules Team. All rights reserved.
 This document is free software; you may redistribute it and/or modify
 it under the same terms as GNU GPL v2 or later.
 

[toc] | [prev] | [next] | [standalone]

#7723

[Multipart message — attachments visible in raw view] — view raw

thanks a lot for preparing all this.

On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> +DPMT requires upstream tarballs; releases cannot be made from upstream git
> +repositories directly.  This is because PyPI contains upstream tarballs, and
> +tarballs are what we upload to the Debian archive.

i find the justification a bit weird: "no releases can be made from
upstream git because some upstreams use tarballs"?

in any case, i don't think that there is actually a need for the policy
to justify the decision to require tarballs (let's put that in the wiki
for those interested).

gfmsadr
IOhannes

[toc] | [prev] | [next] | [standalone]

#7726

"IOhannes m zmölnig (Debian/GNU)" <umlaeute@debian.org> writes:

> thanks a lot for preparing all this.
>
> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> > +DPMT requires upstream tarballs; releases cannot be made from upstream git
> > +repositories directly.  This is because PyPI contains upstream tarballs, and
> > +tarballs are what we upload to the Debian archive.
>
> i find the justification a bit weird: "no releases can be made from
> upstream git because some upstreams use tarballs"?

Yes, that is weird, and it's not what you quoted. I don't know how you
get that meaning from the text you quoted:

    This is because PyPI contains upstream tarballs, and tarballs are
    what we upload to the Debian archive.

> in any case, i don't think that there is actually a need for the
> policy to justify the decision to require tarballs (let's put that in
> the wiki for those interested).

On the contrary, I think the Policy document should document the
rationale for contingent decisions like this. When it is inevitably
discussed again in the future, it is always better to know the intent of
the authors.

-- 
 \          “Our products just aren't engineered for security.” —Brian |
  `\             Valentine, senior vice-president of Microsoft Windows |
_o__)                                                development, 2002 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#7727

On Oct 21, 2015, at 11:17 AM, Ben Finney wrote:

>On the contrary, I think the Policy document should document the
>rationale for contingent decisions like this. When it is inevitably
>discussed again in the future, it is always better to know the intent of
>the authors.

+1

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web