Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On 2014-01-27 at 00:14:12 +0100, Nicolas Dandrimont wrote: It has been a while since I have been meaning to post a message like this. I Thanks for writing this - Be more welcoming to newcomers. I think that the proof of previous work policy is a hurdle that we would be better off without. The worst that could happen is that someone starts packaging something and then the package languishes in svn. I don't know about this: in my case the proof of previous work was just a package submitted on mentors, and it was my first package for debian ever, still not in a great shape, not a big hurdle. On the other hand, having to declare which packages you intend to work on when joining the team is probably helping maintaing the idea that you should only look at your own things and not dare touch anything else. -- Elena ``of Valhalla'' -- 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/20140127102313.gb2...@virginsteele.home.trueelena.org
Re: Making packaging Python modules fun again
Am 27.01.2014 00:14, schrieb Nicolas Dandrimont: - Adding Python 3 support when upstream has it I think this should make it into the python policy. 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/52e67a05.8010...@debian.org
Re: Making packaging Python modules fun again
On 01/27/2014 11:23 PM, Matthias Klose wrote: Am 27.01.2014 00:14, schrieb Nicolas Dandrimont: - Adding Python 3 support when upstream has it I think this should make it into the python policy. Matthias I agree. 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/52e6a1bb.4010...@debian.org
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On 26 Jan 2014 16:33, Paul Tagliamonte paul...@debian.org wrote: On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Ditto - I agree with just about everything Nicolas said. I'd love to see this become a cooperative and welcoming team. Thomas
Re: Making packaging Python modules fun again
Nicolas Dandrimont ol...@debian.org writes: I am strongly of the opinion that the DPMT should be a team, not just a SVN repository with random packages and a mailing-list where people shout at each other when they dare touch those packages. Thanks for expressing these constructive ideas. This continuing atmosphere of fear, and the constant bad faith accusations, make it really hard to work in the team efficiently […] I acknowledge your reticence at mentioning VCS. That said, though: I really think this culture of fear and territorialism is exacerbated by using Subversion as the VCS, instead of a VCS with proper merge support. The great difficulty Subversion presents in the task of merging someone's changes leads to the avoidance of casual branching, whereas any modern DVCS positively encourages casual branching and invitations to merge. Using a VCS with such poor merging support means the only feasible way to put work in the VCS is to put it directly on the trunk; which in turn leads to either frustration with discussing a change that isn't in the VCS where everyone can see it, or exasperation when a set of changes goes into the trunk with little discussion. On the other hand, a DVCS with proper merge support makes for a community of developers much more welcoming of “just get in there and try it”. The effort of working on a branch does not entail a great deal of effort at the end of the journey: it is easily examined by anyone else and merged into trunk after discussing whether it's valuable. So I think migrating to a DVCS – any of Bazaar, Git, Mercurial – would make it much easier to think about a problem by committing changes early to a VCS branch. At the same time, it would mean having that branch immediately available in the team's VCS for comparison — without disrupting what's happening on the trunk branch. (I'm afraid to put this in here, as it's mostly a matter of taste, but) - Migration to a more modern VCS. So while I agree that *which* DVCS to use is in part a matter of taste, there is great benefit to the development community as a whole to be had from switching away from Subversion to *some* modern popular DVCS. None of that reduces the effort involved in such a migration, nor helps to choose between the competing DVCSes (all three of the main ones I mentioned have good merge support, so this isn't a criterion to choose between them). But it hopefully makes clear how the community issues discussed in this thread are connected with the choice of workflow tools, and thereby increases the perceived benefit of such a change compared to the cost of remaining with an inferior tool. -- \“Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney -- 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/854n4qdtqm@benfinney.id.au
