Re: DPMT Policy

[Barry Warsaw, 2015-10-21] > How about this: > > """ > DPMT requires a pristine-tar branch, and only upstream tarballs can be used to > advance the upstream branch. Complete upstream git history should be avoided > in the upstream branch. > """ just a tiny change: s/ / / -- Piotr Ożarowski

PyPI wheels (was Re: Python Policy)

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

Re: DPMT Policy

On Oct 21, 2015, at 02:06 PM, Piotr Ożarowski wrote: >Only version to version upstream changes should be kept in the repository - >complete upstream git history should be avoided. In order to make it >easier to cherry-pick upstream commits as patches, add remote repository >(example below). > >

Re: Git migration schedule

On Oct 21, 2015, at 08:36 AM, Sandro Tosi wrote: >I need to backport quite some packages, and use often experimental to >stage big packages new releases (think of numpy and matplotlib) so it >is not a rare situation at all and it should be considered now that we >are at the beginning of a new era

Re: PyPI wheels (was Re: Python Policy)

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*

Re: PyPI wheels (was Re: Python Policy)

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

Re: DPMT Policy

Piotr Ożarowski writes: > [Barry Warsaw, 2015-10-21] > > """ > > DPMT requires a pristine-tar branch, and only upstream tarballs can be used > > to > > advance the upstream branch. Complete upstream git history should be > > avoided > > in the upstream branch. > > """ > >

Re: Git migration schedule

On Wed, Oct 21, 2015 at 3:48 PM, Barry Warsaw wrote: > On Oct 21, 2015, at 08:36 AM, Sandro Tosi wrote: > >>I need to backport quite some packages, and use often experimental to >>stage big packages new releases (think of numpy and matplotlib) so it >>is not a rare situation at

pytest

Hello, If you look at the djangorestframework git repository, it is failing to build due to tests failing. I incorrectly filed a bug report upstream about this: https://github.com/tomchristie/django-rest-framework/issues/3524 Upstream correctly pointed out that the test class is decorated by

Re: Git migration schedule

Sandro Tosi writes: > I dont know if this integrates easily with git-dpm though (from a very > high level, it seems they have some incompatibilities in particular on > how git-dpm keep tracks of the upstream source) Maybe we should fix #801666 first and then revisit this

Re: Git migration schedule

On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote: > Maybe we should fix #801666 first and then revisit this question? git-dpm hasnt seen a single line changed since more than a year (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold my breath on it :( --

Re: DPMT Policy

On Oct 22, 2015, at 08:32 AM, Ben Finney wrote: >+1 > GOML -Barry :)

Re: Python Policy

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

Re: DPMT Policy

[Barry Warsaw, 2015-10-21] > What I'm trying to express is the team decision (a couple of debconfs ago) for > pristine-tars rather than releasing from upstream git. I do want to keep the > rationale in the policy doc; it's one sentence and it seems to come up often > enough. Suggestions for

Re: Python Policy

❦ 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

Re: Git migration schedule

> It does seem like DEP-14 has thought of these complications. My concern is > that these should be rare so it seems nicer to optimize for the common > (simple) case and allow for the more complicated branch names when needed. I need to backport quite some packages, and use often experimental to

Re: Git migration schedule

On Tue, 20 Oct 2015, Brian May wrote: > Barry Warsaw writes: > > > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt > > *as long as the final state of the repo is compatible with git-dpm*. > > Meaning, > > in general, you can make whatever local

Re: Python Policy

-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