Hi Guillem (2024.10.18_13:31:26_+)
> > IMO source package names should follow upstream as closely as possible
>
> If Debian only contained python packages, that would make sense,
> because python modules upstream need to care about not stomping over
> each others names. But Debian contains sou
On 18.10.24 18:48, Scott Kitterman wrote:
On October 18, 2024 2:07:35 PM UTC, Simon McVittie wrote:
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is
On October 18, 2024 2:07:35 PM UTC, Simon McVittie wrote:
>On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
>> I guess whether "upstream name or python-$modulename" would seem fine,
>> depends on what "upstream name" is. I guess if the latter is something
>> like "py" or some widely
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
> I guess whether "upstream name or python-$modulename" would seem fine,
> depends on what "upstream name" is. I guess if the latter is something
> like "py" or some widely known sub-ecosystem that is
> really very much python-specific, an
Hi!
[ I never received a reply so was not aware some conversation had been
going on. :) I've rearranged the replies a bit. ]
On Sun, 2023-01-29 at 13:52:09 +0100, Piotr Ozarowski wrote:
> tags 791635 + wontfix
> thanks
> [Scott Kitterman, 2023-01-29]
> > Please wontfix and let's move on.
>
>
Hi Scott (2023.01.29_01:34:54_+)
> It'd be much simpler just to drop DPT or myself from uploaders and ignore
> this, so that's probably the path I would take.
The Debian Python Policy is independent of DPT. So, if adopted, that
wouldn't help much... :)
> Regardless,
t;
>This got closed due to the python-defaults package being removed from
>sid, reopening and reassigning where python-policy seems to be located
>now.
>
>On Tue, 2022-12-27 at 23:29:30 +, Debian Bug Tracking System wrote:
>> Date: Tue, 7 Jul 2015 03:11:06 +0200
>&g
Control: reopen -1
Control: reassign -1 python3
[ Sorry, resending, as the bug was archived so it ignored all the
control commands. ]
This got closed due to the python-defaults package being removed from
sid, reopening and reassigning where python-policy seems to be located
now.
On Tue, 2022
The Python Policy document [1] states:
> For all supported Debian releases, sys.path does not include a
> /usr/lib/pythonXY.zip entry.
I may not understand the sentence, or something, because it looks wrong to me
as pythonXY looks to be in sys.path, at least on my Debian bookworm:
Hi,
I added in the Wiki [0], the link to the python3-defaults
docs and policy [1].
Please review it.
[0] https://wiki.debian.org/Teams/PythonTeam#preview
[1] https://www.debian.org/doc/packaging-manuals/python-policy/
Cheers
Emmanuel
Hi!
On Fri, Oct 1, 2021 at 7:43 AM wrote:
> Hello,
>
> this is about the wiki page of that team.
> https://wiki.debian.org/Teams/PythonTeam
>
> I accidentally found the "Debian Python Policy documentation".
> https://www.debian.org/doc/packaging-manuals/python-pol
Hello,
this is about the wiki page of that team.
https://wiki.debian.org/Teams/PythonTeam
I accidentally found the "Debian Python Policy documentation".
https://www.debian.org/doc/packaging-manuals/python-policy/
Looks nice and very important for new team members.
Maybe it would hel
Hi Dmitry (2021.02.26_19:10:42_+)
> On Fri, Feb 26, 2021 at 06:09:50PM +, Stefano Rivera wrote:
> > Hi Dmitry (2021.02.26_08:31:11_+)
> > > You can use :samp:`python3.{Y}`. See:
> >
> > Thanks for the hint. Glad I asked :)
> >
> > Switched to that, and re-rendered.
>
> Small addition (
On Fri, Feb 26, 2021 at 06:09:50PM +, Stefano Rivera wrote:
> Hi Dmitry (2021.02.26_08:31:11_+)
> > You can use :samp:`python3.{Y}`. See:
>
> Thanks for the hint. Glad I asked :)
>
> Switched to that, and re-rendered.
Small addition (sorry that I did not mention it earlier): when referring
Hi Dmitry (2021.02.26_08:31:11_+)
> You can use :samp:`python3.{Y}`. See:
Thanks for the hint. Glad I asked :)
Switched to that, and re-rendered.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Hi Stefano!
On Thu, Feb 25, 2021 at 10:58:41PM +, Stefano Rivera wrote:
> Hacking on the docbook Python Policy is no fun.
>
> I ported the current version to sphinx.
>
> MR: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/10
>
> Render: http
Hacking on the docbook Python Policy is no fun.
I ported the current version to sphinx.
MR: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/10
Render: https://people.debian.org/~stefanor/python-policy-sphinx/
I'd appreciate it if anyone who has the time would give
Hi Fabrice,
Fabrice BAUZAC-STEHLY writes:
> Hello Debian-Python,
>
> I have a few questions regarding the Python Policy:
> https://www.debian.org/doc/packaging-manuals/python-policy/
>
> - Is there a Debian package for reading it offline? (apparently not)
>
> - Who mai
Hello Debian-Python,
I have a few questions regarding the Python Policy:
https://www.debian.org/doc/packaging-manuals/python-policy/
- Is there a Debian package for reading it offline? (apparently not)
- Who maintains this document: is it the Policy team, the Python team?
- Where is the
Hi Geert!
On Sun, Jul 05, 2020 at 07:05:28PM +0200, Geert Stappers wrote:
> Hi,
>
> Where to find the source of python-policy?
I believe it is here:
https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/debian/python-policy.dbk
--
Dmitry Shachnev
signature.asc
Descrip
Hi,
Where to find the source of python-policy?
It it not (yet?) at Salsa
https://salsa.debian.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=&search=python-policy
https://salsa.debian.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_r
Le mer. 6 nov. 2019 à 23:49, Matthias Klose a écrit :
>
> On 06.11.19 22:04, Nicholas D Steeves wrote:
> > Brian May writes:
> >> Or maybe even expand as two bullet points:
> >>
> >> - Do not remove python-foo-doc.
> >> - Do not rename it to python3-foo-doc.
> >>
> >> I think this makes it very e
On 06.11.19 22:04, Nicholas D Steeves wrote:
Brian May writes:
Stéphane Blondon writes:
Perhaps there is a doubt how to read it?
- do not (remove python-foo-doc or rename it to python3-foo-doc)
- (do not remove python-foo-doc) or (rename it to python3-foo-doc)
Would it be better if we remo
Brian May writes:
> Stéphane Blondon writes:
>
>> Perhaps there is a doubt how to read it?
>> - do not (remove python-foo-doc or rename it to python3-foo-doc)
>> - (do not remove python-foo-doc) or (rename it to python3-foo-doc)
>>
>> Would it be better if we remove the indentation and use this
Stéphane Blondon writes:
> Perhaps there is a doubt how to read it?
> - do not (remove python-foo-doc or rename it to python3-foo-doc)
> - (do not remove python-foo-doc) or (rename it to python3-foo-doc)
>
> Would it be better if we remove the indentation and use this sentence(?):
> if documentat
On 03/11/2019 15:16, Matthias Klose wrote:
> On 03.11.19 15:09, Neil Williams wrote:
>> * do not remove python-foo-doc or rename it to python3-foo-doc
>
> yes, but this tells you not to rename it to python3-foo-doc.
Perhaps there is a doubt how to read it?
- do not (remove python-foo-doc or
On 03.11.19 15:09, Neil Williams wrote:
On Sun, 3 Nov 2019 15:00:17 +0100
Matthias Klose wrote:
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3 mi
On Sun, 3 Nov 2019 15:00:17 +0100
Matthias Klose wrote:
> [discussing this outside the bug report on the ML]
>
> On 03.11.19 14:39, Neil Williams wrote:
> > Actually, that's a good catch. I was mixing up the defaults package
> > with the general advice on python3 migration to not remove
> > pyth
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3 migration to not remove
python-foo-doc just to rename it to python3-foo-doc.
where did you read that
Package: python3
Version: 3.7.5-1
Severity: normal
As discussed on IRC and alongside the post to debian-devel-announce, please
review and include this amendment to the Debian Python Policy to cover
the removal of the Python 2 stack as outlined at
https://wiki.debian.org/Python/2Removal
https
On Wednesday, May 16, 2018 06:25:01 PM Joseph Herlant wrote:
> https://wiki.debian.org/Python/Policy has been updated/cleaned up.
> Sorry it took so long.
>
> Joseph
Thanks for taking care of it.
Scott K
https://wiki.debian.org/Python/Policy has been updated/cleaned up.
Sorry it took so long.
Joseph
On Mon, May 14, 2018 at 10:50 PM, Ben Finney wrote:
> Joseph Herlant writes:
>
>> Hi,
>>
>> On Mon, May 14, 2018, 10:01 PM Ben Finney wrote:
>>
>> > J
Joseph Herlant writes:
> Hi,
>
> On Mon, May 14, 2018, 10:01 PM Ben Finney wrote:
>
> > Joseph, do you mean simply replacing the article content with a “now
> > the policy is in the packaging manuals” external link?
>
> Yes, that's what I meant, sorry for the confusion.
Okay. Yes, that sounds f
Hi,
On Mon, May 14, 2018, 10:01 PM Ben Finney wrote:
> I don't see how a “redirect” (which I understand to be automatic, not
> controlled by the visitor) to a URL outside the wiki would be good.
>
> Joseph, do you mean simply replacing the article content with a “now the
> policy is in the packa
Scott Kitterman writes:
> On Monday, May 14, 2018 10:55:36 AM Joseph Herlant wrote:
> > Hi guys,
> >
> > I noticed that https://wiki.debian.org/Python/Policy is full of
> > obsolete ways to do.
> > Is it worth updating it or should I just remove everythin
On Monday, May 14, 2018 10:55:36 AM Joseph Herlant wrote:
> Hi guys,
>
> I noticed that https://wiki.debian.org/Python/Policy is full of
> obsolete ways to do.
> Is it worth updating it or should I just remove everything there and
> redirect to https://www.debian.org/doc/packag
Hi guys,
I noticed that https://wiki.debian.org/Python/Policy is full of
obsolete ways to do.
Is it worth updating it or should I just remove everything there and
redirect to https://www.debian.org/doc/packaging-manuals/python-policy/
?
It's ranked 3rd in Google when looking for "Deb
Scott Kitterman writes:
> On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> > Ben Finney writes:
> > > * Address all the language around Python 2 versus Python 3 versus
> > > Python general, and re-order or re-word to focus *primarily* on
> > > Python 3, with Python 2 treated as the
On Feb 16, 2016, at 11:54 AM, Paul Wise wrote:
>I always thought it strange to put site- in /usr/local since
>/usr/local already implies site/system-wide packages. Same for dist-
>since /usr already implies distribution packages.
For as long as I can remember, a from-source 'configure && make &&
On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:
> I don't remember exactly why we called it 'site-packages' ...
Thanks for the history :)
I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already imp
On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote:
>I don't remember exactly why we called it 'site-packages', but I believe it
>was an evolution from the earlier ni.py module, which was where dotted module
>paths first showed up in Python.
And which had a 'site-python' directory, which was kept a
On Feb 16, 2016, at 11:05 AM, Paul Wise wrote:
>Side-note: does anyone know why Python puts packages in "dist-packages",
>"site-packages" etc directories instead of just "packages" directories?
I don't remember exactly why we called it 'site-packages', but I believe it
was an evolution from the e
On Sat, Jan 23, 2016 at 9:55 AM, Barry Warsaw wrote:
> 2.5 Module Path
>
> "Public Python modules must be installed in the system Python modules
> directory, /usr/lib/python./dist-packages. Public Python 3 modules must
> be installed in /usr/lib/python3/dist-packages."
Side-note: does anyone kno
On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> Ben Finney writes:
> > * Address all the language around Python 2 versus Python 3 versus
> >
> > Python general, and re-order or re-word to focus *primarily* on Python
> > 3, with Python 2 treated as the still-supported legacy syst
Python 3 version; the
+ binary package python will represent the
+ current default Debian Python 2 version. As far as is reasonable,
+ Python 3 and Python 2 should be treated as separate runtime
+ systems with minimal interdependencies.
In some cases, Python policy explicitly referenc
Scott Kitterman writes:
> On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
> ...
> > Once these non-semantic changes are accepted I will begin work on
> > the second stage of semantic changes.
> ...
>
> OK. Those are all accepted.
Thank you, Scott! I'll proceed with the semantic c
On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
...
> Once these non-semantic changes are accepted I will begin work on the
> second stage of semantic changes.
...
OK. Those are all accepted. Barry Warsaw had done some changes in the -whl
section so I made an attempt at merging w
Scott Kitterman writes:
> I should be able to get it reviewed and merged no later than Saturday
> (probably Friday).
Much appreciated, thanks for the response.
--
\“When I was a baby I kept a diary. Recently I was re-reading |
`\ it, it said ‘Day 1: Still tired from the move. Day
On January 26, 2016 10:32:57 PM EST, Ben Finney
wrote:
>Dmitry Shachnev writes:
>
>> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
>> > I'm planning to provide changes in two bundles:
>> >
>> > * Go through the whole document and tidy it up for consistency,
>> > source style, m
Dmitry Shachnev writes:
> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> > I'm planning to provide changes in two bundles:
> >
> > * Go through the whole document and tidy it up for consistency,
> > source style, markup, and language style. This should not change
> > the meanin
Hi Ben,
On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
> style, markup, and language style. This should not change the meaning
> of anything, but will chang
Ben Finney writes:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
> style, markup, and language style. This should not change the meaning
> of anything, but will change the wording of numerous passages.
>
> My pro
-25 Distinguish “Python” the system versus “python”
the command.
414: Ben Finney 2016-01-25 Add myself to the document's authors.
413: Ben Finney 2016-01-25 Correct whitespace to conform to Policy style.
412: Ben Finney 2016-01-25 Add editor hints to match Debian Policy text
style.
On January 24, 2016 11:59:14 PM EST, Ben Finney
wrote:
>Scott Kitterman writes:
>
>> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
>> > Found it; the source document is ‘python-policy.sgml’ in the source
>> > VCS for ‘python3’. Currently that's a Bazaar repository at
>> >
>.
>>
>>
Scott Kitterman writes:
> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> > Found it; the source document is ‘python-policy.sgml’ in the source
> > VCS for ‘python3’. Currently that's a Bazaar repository at
> > .
>
> That's correct.
Hmm, apparently I've got the wrong thing. I've got
Thanks for taking this on Ben,
On Jan 24, 2016, at 04:33 PM, Ben Finney wrote:
>I think you're right that this needs a general clean-up through the
>policy document, to consistently use:
>
>* “python2” to refer to that command only;
>
>* “python3” to refer to that command only;
>
>* “python” to r
On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> Ben Finney writes:
> > Where is the Git (I assume?) repository you're using for VCS of this
> > policy document?
>
> Found it; the source document is ‘python-policy.sgml’ in the source VCS
> for ‘python3’. Currently that's a Bazaar repos
es this comes up.
>
> Yes, that's likely because when the Debian Python policy was initially
> drafted, there was no Python 3 anywhere close to entering Debian. So
> “Python” and “Python 2” were less ambiguously conflated at that time.
>
> Now that Python 2 and Python 3 are bot
On Sunday, January 24, 2016 04:46:09 PM Ben Finney wrote:
> Scott Kitterman writes:
> > I've taken a run through the current Python Policy to see where I
> > think it needs to be updated for Stretch. The updates largely fall
> > into four categories: […]
>
> This
Ben Finney writes:
> Where is the Git (I assume?) repository you're using for VCS of this
> policy document?
Found it; the source document is ‘python-policy.sgml’ in the source VCS
for ‘python3’. Currently that's a Bazaar repository at
.
--
\ “The entertainment industry calls DRM "se
Scott Kitterman writes:
> I've taken a run through the current Python Policy to see where I
> think it needs to be updated for Stretch. The updates largely fall
> into four categories: […]
This is great to see, thank you Scott.
Where is the Git (I assume?) repository you'
Scott Kitterman writes:
> I don't particularly agree, but if that's correct, then there's a
> large amount of change needed throughout the policy. These certainly
> aren't the only places this comes up.
Yes, that's likely because when the Debian Python policy w
On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote:
> On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
> >Personally I seriously dislike the trend to call Python Python 2 (and I
> >still thing approving a pep to invent /usr/bin/python2 because Arch went
> >insane was a horrible idea).
On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
>Personally I seriously dislike the trend to call Python Python 2 (and I still
>thing approving a pep to invent /usr/bin/python2 because Arch went insane was
>a horrible idea). There's an earlier spot in the document where it says that
>everyth
On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote:
> On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
> >I've taken a run through the current Python Policy to see where I think it
> >needs to be updated for Stretch.
>
> Thanks Scott for the badly needed
On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
>I've taken a run through the current Python Policy to see where I think it
>needs to be updated for Stretch.
Thanks Scott for the badly needed update.
Some comments, apologies for the lack of good quoting, or if I'
I've taken a run through the current Python Policy to see where I think it
needs to be updated for Stretch. The updates largely fall into four
categories:
1. Update old examples
2. Clean up old policy test that no longer applies
3. Simplify things due to there only being one python ve
On Oct 22, 2015, at 11:11 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>something else i wonder whether we shouldn't drop it, as i don't quite
>understand why it has to be in the policy.
>
>i *think* it's supposed to urge DDs into becoming team members, even though
>they can ("are able to") already
On Oct 22, 2015, at 11:14 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>thanks for gender neutral wording. however, you missed one "his" in the
>first sentence (probably more in other paragraphs).
Got it, thanks.
-Barry
pgpm4DkniheG1.pgp
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-21 15:54, Barry Warsaw wrote:
> Hopefully, the latest changes (see previous follow up) are both
> more concise and coherent.
maybe.
i have to admit i'm not totally used to an reviewing git patches per
mailinglists, and in this case i got
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-20 22:53, Barry Warsaw wrote:
> +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,·w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-20 22:53, Barry Warsaw wrote:
> +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,·w
On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote:
> On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> > On Oct 21, 2015, at 08:47 PM, Brian May wrote:
> >
> >>in one case this is because upstream have only supplied a *.whl
> >>file on Pypi.
> >
> > I'm *really* hoping that the PyPA wi
On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
I'm not sure why they should pro
On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>in one case this is because upstream have only supplied a *.whl
>file on Pypi.
I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
There is talk about source wheels, and if that happens we'll probably have to
adjust our tools
On Oct 21, 2015, at 09:51 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>i am not a native speaker. so i might get things wrong.
>but i'm not the only non-native English speaker in Debian.
>therefore, i *strongly* suggest that the policy should be written in a
>style that non-natives can understand i
On Oct 21, 2015, at 08:46 AM, Vincent Bernat wrote:
>You should remove the reference to Pypi since tarballs can also be taken
>From GitHub (when upstream doesn't want to ship everything, like tests,
>in Pypi tarballs or doesn't even release tarballs on Pypi):
Yep, done.
-Barry
pgpcjyVfgA4jB.pg
Vincent Bernat writes:
> You should remove the reference to Pypi since tarballs can also be taken
> From GitHub (when upstream doesn't want to ship everything, like tests,
> in Pypi tarballs or doesn't even release tarballs on Pypi):
Have filled upstream bugs on issues that prevent me using the
❦ 20 octobre 2015 20:52 -0400, Barry Warsaw :
>>I'd remove this paragraph. Releases can be made via `git archive` and I did
>>that many times (assuming pristine-tar will still keep needed data to
>>regenerate exact same tarball). If you meant that we don't want to keep
>>complete upstream git h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)" 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
>>> u
On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote:
>I have few comments, but even if I didn't, please wait at least until after
>the weekend (or better: 7 days) so that others have time to review it and
>comment / propose changes.
Fair enough. Of course, it's in a vcs so it's easy to change! :
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
"IOhannes m zmölnig (Debian/GNU)" 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
>
[Barry Warsaw, 2015-10-20]
> Latest diff against master. If you're happy with this, I'll merge to master,
> update the web page, and trim the wiki.
I have few comments, but even if I didn't, please wait at least until after
the weekend (or better: 7 days) so that others have time to review it and
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 fi
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 @@
-
- P
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
[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 ma
[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
[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 exte
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? . 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 p
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&#
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 ne
[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 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-de
Barry Warsaw writes:
> * "PMPT" policy
> http://python-modules.alioth.debian.org/
> git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
Is policy.rst automatically kept in sync somehow in between
python-modules.git and http://python-modules.alioth.debian.org/?
--
Brian May
| 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
| -
| +
[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
Piotr Ożarowski 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 s
[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,
1 - 100 of 533 matches
Mail list logo
