Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/19/2013 06:08 AM, Thomas Kluyver wrote:
> On 18 February 2013 20:46, Ludovic Gasc  > wrote:
>
> I vote D, and I can handle the migration from SVN to Git, I've
> done this several times for my work and WYMeditor.
>
> Are you interested?
>
> I'm interested personally, but the votes so far suggest there's no
> real will for any change - the only option with more than one first
> preference vote is the status quo.
>
> Thomas
So far, those who could have vote C or D (this shows in previous reply
that some could have voted that) didn't bother answering the "poll".
Probably because of the tone of some participants of this thread, who
didn't take it seriously, replied unrealistic answers who were not even
in the original poll, or discussed previously in the thread.It would
probably have been more efficient to just read previous contribution in
this thread, if some of the participants just ran away from it...

It seems that there's a will to completely destroy this discussion
anyway (which is quite successful), so don't expect much from now on.
I just hope not too many people will read this shameful thread.

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/5123b24d.6020...@debian.org

Re: How does team maintenace of python module works?

[Dmitry Shachnev]

On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand  wrote:
> So far, those who could have vote C or D (this shows in previous reply
> that some could have voted that) didn't bother answering the "poll".

I've already expressed my opinion in this thread, but to be formal: my
vote is DA.

--
Dmitry Shachnev


-- 
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/cakimphw-ghrj1w99naoglife1wup3rxisb78gk49hqkwsim...@mail.gmail.com

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand  wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev
Mine is CDAB.

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/5123b93b.7060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand  wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev
>
>
I have reviewed (I hope, MOST) answers, and here's what I get:

Scott K
E - Migrated to bzr, but I want someone else to to all the work.

Jakub Wilk
F - Migrate to Mercurial, but I want someone else to do all the work.

Dmitrijs
DA

Daniele Tricoli
A, F.1 but my F option imply that I will help "to do the work"

Robert Collins
Seems to want to allow Git

Barry Warsaw
Likes BZR, but seems to possibly agree with git on some workflow conditions

Chow Loong Jin
Didn't express himself, but knows how to use git and git-buildpackage

Javi Merino
FCDAB

Ludovic Gasc
D

Thomas Kluyver
Seems to be ok with migrating to Git (so, option D)

Myself:
CDBA

So, we have 12 persons who expressed themselves, about 6 persons
who would agree with Git in some ways, 3 who would like to move
to another system, but if they don't do the work. We also have
2 persons who proposed themselves for doing the work of moving
to Git.

If the above isn't correct, please let everyone know your view.

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/5123bc84.4040...@debian.org

Re: Request to Join Project Python Modules Packaging Team from Ben Carrillo (kali-guest)

[Jakub Wilk]

* Ben Carrillo , 2013-01-29, 20:02:

[1] https://mentors.debian.net/package/python-srp


Now I had a look at this one, too.

Implementation of the _ctsrp module is flawed: you must not load a 
shared library via the .so symlink. The symlink is supposed to be used 
at build-time one. As far I can see, this module is used only as a 
fallback, so for Debian a quick solution to this problem would be 
removing the module from the binary package.


You need versioned build-dependency on "dpkg-dev (>= 1.16.1)" if you 
want to use DEB_*_MAINT_* variables.


The extension modules should be linked with libcrypto, not libssl. All 
the symbols it uses are from the former, not the latter, as far as I can 
tell.


Lintian emits:
P: python-srp source: unversioned-copyright-format-uri 
http://dep.debian.net/deps/dep5
I: python-srp: possible-documentation-but-no-doc-base-registration

Short license names in DEP-5 copyright file cannot contain spaces; so 
"New BSD" is incorrect.


You probably want to indent the itemized list in d/copyright by one 
space; see Debian Policy §5.6.13 (the same formating rules apply to both 
Description in debian/control and license text in DEP-5 copyright 
files).


You might want to provide a -dbg package. Such package should contain 
extensions modules for the python2.X-dbg interpreter, and detached 
debugging symbols for the "normal" extensions.



All in all, it doesn't look very bad, so I've just added you to the 
team. Feel free to inject your packages to the team's repository.


--
Jakub Wilk


--
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/20130219182142.ga...@jwilk.net

Re: How does team maintenace of python module works?

[Piotr Ożarowski]

FTR: I want to migrate to Git, but I don't have time to do the migration
work right now, so I vote for status quo (unless someone will show me
the code)
-- 
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


signature.asc
Description: Digital signature

Re: How does team maintenace of python module works?

[Andreas Noteng]

Den 19. feb. 2013 18:55, skreiv Thomas Goirand:
If the above isn't correct, please let everyone know your view. Thomas 
My contribution to this team is relatively low volume, but anyways: My 
vote is, in order of preference, DCAB. I'd also be happy with bzr (which 
I use for my Ubuntu stuff), but IMHO git is the most useable vcs for 
Debian packaging.


Regards
Andreas Noteng


--
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/5123e646.9050...@noteng.no

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 19 February 2013 17:55, Thomas Goirand  wrote:

> Thomas Kluyver
> Seems to be ok with migrating to Git (so, option D)


I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for
summarising the votes.

Including Piotr & Andreas, and putting people whose opinion you've
described into the nearest possible vote would give us first preference
votes:

D: 4 (migration to git)
C: 3 (allow git)
E: 2 (migration to bzr)
F: 2 (migration to hg)
A: 1 (maintain status quo) - I thought there were some more, but I'm too
tired to go back through the thread at present.

Using alternative voting, knock out A (and B, which had no first preference
votes):

D: 4
C: 3
F: 3
E: 2

After that it gets tricky, because we'd knock E out next, but the I'm not
sure where the votes counted for E (Scott & Barry) should be reallocated.
If we plough ahead regardless by dropping them, it ends up with a 4-4 draw
between D (migration to git) and C (allowing git and svn). Perhaps we can
get more votes, or more fallback preferences from people who've only
expressed their first preference.

Thomas

Re: How does team maintenace of python module works?

[Charlie Smotherman]

On Tue, Feb 19, 2013 at 3:42 PM, Thomas Kluyver  wrote:
> On 19 February 2013 17:55, Thomas Goirand  wrote:
>>
>> Thomas Kluyver
>> Seems to be ok with migrating to Git (so, option D)
>
>
> I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for
> summarising the votes.
>
> Including Piotr & Andreas, and putting people whose opinion you've described
> into the nearest possible vote would give us first preference votes:
>
> D: 4 (migration to git)
> C: 3 (allow git)
> E: 2 (migration to bzr)
> F: 2 (migration to hg)
> A: 1 (maintain status quo) - I thought there were some more, but I'm too
> tired to go back through the thread at present.
>
> Using alternative voting, knock out A (and B, which had no first preference
> votes):
>
> D: 4
> C: 3
> F: 3
> E: 2
>
> After that it gets tricky, because we'd knock E out next, but the I'm not
> sure where the votes counted for E (Scott & Barry) should be reallocated. If
> we plough ahead regardless by dropping them, it ends up with a 4-4 draw
> between D (migration to git) and C (allowing git and svn). Perhaps we can
> get more votes, or more fallback preferences from people who've only
> expressed their first preference.
>
> Thomas

here is my $.02 worth
EA

-- 
Charlie Smotherman


-- 
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/cal_xwdb9vludb70s4txvm4svo2wqkhuy_av9y9uev9f5jfy...@mail.gmail.com

Re: RFR: python-qrcode -- native python module to generate QR codes

[Jakub Wilk]

* Cornelius Kölbel , 2013-02-18, 17:38:

lintian --pedantic
produced no error,
lintian4py --pedantic produced:

p: python-qrcode: pyflakes-unused-import
usr/share/pyshared/qrcode/__init__.py:1: make
p: python-qrcode: pyflakes-unused-import
usr/share/pyshared/qrcode/__init__.py:3: image

How pedantic should be be? ;-)


It should be noted that --pedantic doesn't enable all the possible tags. 
You probably want --display-info, possibly also --display-experimental.


It's up to you to choose which options to use. _I_ enable them all, 
because I'm like to decide myself which of them are worth fixing and 
which not, and some interesting tags have low severity/certainty.


--
Jakub Wilk


--
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/20130219215418.ga...@jwilk.net

Re: How does team maintenace of python module works?

[Robert Collins]

I didn't vote initiall because I read the below as a summary...

On 17 February 2013 01:43, Thomas Kluyver  wrote:
> On 16 February 2013 09:10, Thomas Goirand  wrote:
>>
>> It would be really stupid to only want to "claim" to be working as part
>> of the team, that's not at all what I want to do. I'd like to be able to
>> help when I can, and receive help when I need, which is the point of a
>> team.
>
>
> I agree there are reasonable reasons to want to maintain something in git,
> and it's not ideal to exclude those packages from team maintainership just
> because of the VCS question. Although, if it came to that, the team would be
> happy to offer advice and assistance for Python packages that aren't
> maintained by the team. We all want stuff to work smoothly, whether or not
> it's "our" stuff.
>
> I suggest we take a poll - not as a binding decision, but to get an idea of
> the level of support for different courses of action. You're free to attach
> more weight to the votes of highly involved team members.
>
> The following four positions have all been advocated in this thread:
>
> A - Maintain the status quo, in which DPMT packages may only be maintained
> in SVN.
> B - As A, but encourage the creation of a separate team where Python modules
> can be maintained in git.
> C - Allow DPMT-maintained packages to live in SVN or git, so new packages
> can be committed to git if the packager prefers. Optionally, we could make
> provisions to migrate existing packages.
> D - Migrate all the DPMT-maintained packages to git.

DCA

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services


-- 
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/caj3hoz0r_ssus4ukgywpaqfq8f_p_d4fvvqkozjjdqt-xhc...@mail.gmail.com

Re: How does team maintenace of python module works?

[Barry Warsaw]

On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:

>After that it gets tricky, because we'd knock E out next, but the I'm not
>sure where the votes counted for E (Scott & Barry) should be reallocated.

If it makes things easier, I am essentially sided with Piotr.  The fact that I
don't like git much is immaterial - I want a dvcs and don't have the time to
put into a bzr or hg migration.  I don't have time to put into a git migration
either, but it seems like you've got that covered. :)

So I still think it comes down to, them that does the work gets to decide, but
there *is* work to do.  It's clear we don't want multiple vcses.  So I think
you have an opportunity to convince us by:

* Doing a test migration and putting a test repo up so we can play with it and
  see what it's like.

* Figure out whether full-source or debian/ only works better (maybe give us
  both repos so we can play with them and discuss the pros and cons from
  actual working examples).

* Put together draft policy and documentation to describe a workflow for team
  maintenance of packages under git, including branching, pull requests, code
  review, quilt integration, package building, etc.

* Work out how upstreams that are under other vcses would work.

* Provide a plan for a smooth flag day transition if/when consensus is reached.

* Gather feedback, fix problems, rinse and repeat.

Once people are comfortable with how a git-based team repository would work, I
suspect you'll find more consensus to switch.

Cheers,
-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/20130219172048.66a75...@anarchist.wooz.org

Re: RFR: python-qrcode -- native python module to generate QR codes

[Jakub Wilk]

* Cornelius Kölbel , 2013-02-18, 18:05:

http://mentors.debian.net/debian/pool/main/q/qrcode/qrcode_2.4.2-1.dsc


"XSPV: 2.6, 2.7" is better than "XSPV: current", but please make it:
XS-Python-Version: >= 2.6

The description has improved, thanks. :) I'd remove this sentence, 
though: "So it depends on the package python-imaging."


Why do you include compressed README and changelog in debian? :/
You probably should use dh_installdoc and dh_installchangelog to install 
them, not dh_install.


Shouldn't the two patches ("add-man-page", "improve-man-page") be merged 
into a single one?


--
Jakub Wilk


--
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/20130219223415.ga2...@jwilk.net

Re: How does team maintenace of python module works?

[Daniele Tricoli]

On Tuesday 19 February 2013 23:20:48 Barry Warsaw wrote:
> If it makes things easier, I am essentially sided with Piotr.  The fact
> that I don't like git much is immaterial - I want a dvcs and don't have
> the time to put into a bzr or hg migration.  I don't have time to put
> into a git migration either, but it seems like you've got that covered.
> :)

[CUT: I agree with remaining paragraphs]

I'm agree with Barry, although I don't like git, it doesn't matter, I will 
simply learn git better if it's the best tool for us :)

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org


-- 
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/20130221.46749.er...@mornie.org

Re: How does team maintenace of python module works?

[Piotr Ożarowski]

[Barry Warsaw, 2013-02-19]
> So I still think it comes down to, them that does the work gets to decide, but
> there *is* work to do.  It's clear we don't want multiple vcses.  So I think
> you have an opportunity to convince us by:
> 
> * Doing a test migration and putting a test repo up so we can play with it and
>   see what it's like.
> 
> * Figure out whether full-source or debian/ only works better (maybe give us
>   both repos so we can play with them and discuss the pros and cons from
>   actual working examples).
> 
> * Put together draft policy and documentation to describe a workflow for team
>   maintenance of packages under git, including branching, pull requests, code
>   review, quilt integration, package building, etc.
> 
> * Work out how upstreams that are under other vcses would work.
> 
> * Provide a plan for a smooth flag day transition if/when consensus is 
> reached.
> 
> * Gather feedback, fix problems, rinse and repeat.
> 
> Once people are comfortable with how a git-based team repository would work, I
> suspect you'll find more consensus to switch.

+1 

/me will point to this mail every time someone proposes to switch to $foo
-- 
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


signature.asc
Description: Digital signature

Re: How does team maintenace of python module works?

[Ludovic Gasc]

On Feb 19, 2013 11:21 PM, "Barry Warsaw"  wrote:
>
> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>
> >After that it gets tricky, because we'd knock E out next, but the I'm not
> >sure where the votes counted for E (Scott & Barry) should be reallocated.
>
> If it makes things easier, I am essentially sided with Piotr.  The fact
that I
> don't like git much is immaterial - I want a dvcs and don't have the time
to
> put into a bzr or hg migration.  I don't have time to put into a git
migration
> either, but it seems like you've got that covered. :)
>
> So I still think it comes down to, them that does the work gets to
decide, but
> there *is* work to do.  It's clear we don't want multiple vcses.  So I
think
> you have an opportunity to convince us by:
>
> * Doing a test migration and putting a test repo up so we can play with
it and
>   see what it's like.

I can do that this week-end. I've only a github account to publish the git
repository, unless somebody else has an access for a better place? For a
test, I think that github is enough.

>
> * Figure out whether full-source or debian/ only works better (maybe give
us
>   both repos so we can play with them and discuss the pros and cons from
>   actual working examples).

A tool that we could use in the future to maintain the packages with more
ease: https://honk.sigxcpu.org/piki/projects/git-buildpackage/

>
> * Put together draft policy and documentation to describe a workflow for
team
>   maintenance of packages under git, including branching, pull requests,
code
>   review, quilt integration, package building, etc.
>
> * Work out how upstreams that are under other vcses would work.
>
> * Provide a plan for a smooth flag day transition if/when consensus is
reached.
>
> * Gather feedback, fix problems, rinse and repeat.
>
> Once people are comfortable with how a git-based team repository would
work, I
> suspect you'll find more consensus to switch.
>
> Cheers,
> -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/20130219172048.66a75...@anarchist.wooz.org
>

Re: How does team maintenace of python module works?

[Matthias Klose]

Am 20.02.2013 00:53, schrieb Piotr Ożarowski:
> [Barry Warsaw, 2013-02-19]
>> So I still think it comes down to, them that does the work gets to
>> decide, but there *is* work to do.  It's clear we don't want multiple
>> vcses.  So I think you have an opportunity to convince us by:
>> 
>> * Doing a test migration and putting a test repo up so we can play with
>> it and see what it's like.
>> 
>> * Figure out whether full-source or debian/ only works better (maybe give
>> us both repos so we can play with them and discuss the pros and cons
>> from actual working examples).
>> 
>> * Put together draft policy and documentation to describe a workflow for
>> team maintenance of packages under git, including branching, pull
>> requests, code review, quilt integration, package building, etc.
>> 
>> * Work out how upstreams that are under other vcses would work.
>> 
>> * Provide a plan for a smooth flag day transition if/when consensus is
>> reached.
>> 
>> * Gather feedback, fix problems, rinse and repeat.
>> 
>> Once people are comfortable with how a git-based team repository would
>> work, I suspect you'll find more consensus to switch.
> 
> +1

can we limit the packages in this ppa to those using dh_python[23] and those
supporting python3?

  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/512416b2.5030...@debian.org

Re: How does team maintenace of python module works?

[Scott Kitterman]

On Tuesday, February 19, 2013 05:20:48 PM Barry Warsaw wrote:
> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
> >After that it gets tricky, because we'd knock E out next, but the I'm not
> >sure where the votes counted for E (Scott & Barry) should be reallocated.
> 
> If it makes things easier, I am essentially sided with Piotr.  The fact that
> I don't like git much is immaterial - I want a dvcs and don't have the time
> to put into a bzr or hg migration.  I don't have time to put into a git
> migration either, but it seems like you've got that covered. :)

What I don't have is time to relearn git every time I'm forced to use it.  I'm 
not sure the advantages of a team outweigh that for me.

Scott K


-- 
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/16809265.qMvuDupsD3@scott-latitude-e6320

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 06:20 AM, Barry Warsaw wrote:
> * Figure out whether full-source or debian/ only works better (maybe give us
>   both repos so we can play with them and discuss the pros and cons from
>   actual working examples).

What is important, I believe, is that git-buildpackage always works.

I've found that having a debian/rules entry called "get-vcs-source"
which gets what is needed from upstream works quite nicely. Our
workflow is described here:

http://openstack.alioth.debian.org/

The idea to use "git archive" was mostly from Julien Danjou. It's
very nice because that way, we can use xz compression, instead
of what upstream provides (that is, github .zip or .tar.gz, which
isn't the best). It's also quite nice because that way, it's possible
to tag a specific commit and package that as upstream release.
This is mostly why I think using Git is convenient, so I really would
like this to be part of the draft.

Though this workflow only works if upstream uses Git, which isn't
the case. In other cases, probably using a pristine tar branch
would do.

BTW, I of course agree that it's 100% necessary to make sure we
have a unified policy, including on branch names and all. For branch
names, I've used the following:

- debian-sid
- upstream-sid
- debian-squeeze
- upstream-squeeze
- etc.

But also:

- debian/unstable
- debian/experimental
- master

then I used the tags from the master branch.

I think it's ok to have both naming shemes. The important bit,
IMO, is that everything is referenced in the debian/gbp.conf so
that nobody has to second-guess what to do.

Just my 2 cents, and if help is needed for migrating, I hope to
be able to be available if you ask.

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/51244fa6.4020...@debian.org

Re: How does team maintenace of python module works?

[Scott Kitterman]

On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
> The idea to use "git archive" was mostly from Julien Danjou. It's
> very nice because that way, we can use xz compression, instead
> of what upstream provides (that is, github .zip or .tar.gz, which
> isn't the best).

See devref 6.7.8.  This not an appropriate reason to not use the upstream 
tarball.

Scott K


-- 
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/3161329.3ERJUKFsNh@scott-latitude-e6320

Re: How does team maintenace of python module works?

[Scott Kitterman]

On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
> On 02/20/2013 06:20 AM, Barry Warsaw wrote:
> > * Figure out whether full-source or debian/ only works better (maybe give
> > us> 
> >   both repos so we can play with them and discuss the pros and cons from
> >   actual working examples).
> 
> What is important, I believe, is that git-buildpackage always works.
> 
> I've found that having a debian/rules entry called "get-vcs-source"
> which gets what is needed from upstream works quite nicely. Our
> workflow is described here:
> 
> http://openstack.alioth.debian.org/
> 
> The idea to use "git archive" was mostly from Julien Danjou. It's
> very nice because that way, we can use xz compression, instead
> of what upstream provides (that is, github .zip or .tar.gz, which
> isn't the best). It's also quite nice because that way, it's possible
> to tag a specific commit and package that as upstream release.
> This is mostly why I think using Git is convenient, so I really would
> like this to be part of the draft.
> 
> Though this workflow only works if upstream uses Git, which isn't
> the case. In other cases, probably using a pristine tar branch
> would do.
> 
> BTW, I of course agree that it's 100% necessary to make sure we
> have a unified policy, including on branch names and all. For branch
> names, I've used the following:
> 
> - debian-sid
> - upstream-sid
> - debian-squeeze
> - upstream-squeeze
> - etc.
> 
> But also:
> 
> - debian/unstable
> - debian/experimental
> - master
> 
> then I used the tags from the master branch.
> 
> I think it's ok to have both naming shemes. The important bit,
> IMO, is that everything is referenced in the debian/gbp.conf so
> that nobody has to second-guess what to do.
> 
> Just my 2 cents, and if help is needed for migrating, I hope to
> be able to be available if you ask.

This all seems to assume full source branches which is not something I'm 
interested in participating in at all.  I've tried it and I find it very 
difficult to work with.

Currently we have one VCS and one package layout.  In the end, we should have 
that still.  Anything else raises a substantial barrier to collaboration.

Scott K

Scott K


-- 
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/20321216.BZ1nqtJvkm@scott-latitude-e6320