Join the team
Hello, I would like to join the Python-modules team to maintain the python-pyric package (https://github.com/wraith-wireless/PyRIC) and maybe other packages needed by the pkg-security-team. My alioth login is sbrun-guest I have read the DPMT policy (https://python-modules.alioth.debian.org/python-modules-policy.html) and I accept it. Regards, Sophie
Re: Backport of python-lockfile and suggested team maintenance
Andreas Tille writes: > However, if maintainers decide from deriving what several people > consider good practice of team maintenance and put extra work on me > (like creating an extra public repository) I'm not willing to do this. I'm sorry to say that I am not clear on what that sentence means; I got lost around “decide from deriving”. The distributed nature of Git – choosing how to share commits between repositories – is a core feature, and allows collaboration without requiring access to the same filesystem. As a maintainer of the package, I remain open to pull requests. > There was a longish discussion on Debian Project[1] and my reading of > it was that named person maintenance is not the prefered way. You have said that you “consider it sensible” to maintain a package within DPMT, and I have no objection to that position. The discussion thread you point to has many opinions, some of them in support of nominating a team as package maintainer. I have no objection to that position. Are you now expressing the separate position that you consider it *not* sensible to name an individual as package maintainer? On what basis? In the discussion thread you point to, I don't see anything to support that. -- \ “[H]ow deep can a truth be — indeed, how true can it be — if it | `\ is not built from facts?” —Kathryn Schulz, 2015-10-19 | _o__) | Ben Finney
Re: Transition away from git-dpm was: Re: Adopting OpenStack packages
On 03/06/2017 11:18 PM, Brian May wrote: > On 2017-03-07 08:43, Thomas Goirand wrote: > >> I prefer if we use debian/unstable rather than debian/master though, so >> it is more explicit where we upload that branch. > > My reading of DEP-14 is that is says we should use debian/master. > > Not that I care much myself, either is fine with me. > > Why debian/unstable, and not debian/sid? Because "unstable" is what we write in debian/changelog, so that's consistent, and also consistent if we upload to experimental. But I'm fine either ways anyway, if others would like to use debian/sid because it's faster to type. >> Also, it'd be wise to >> set that branch as default when cloning the repository. ie we shall ran >> on Alioth: >> >> git symbolic-ref HEAD refs/heads/debian/unstable >> >> so that debian/unstable becomes the default branch. This has a good >> chance to avoid confusion between the old "master" (ie: git-dpm) branch >> and the new DEP14 style that we would adopt. > > I didn't know you could do this. Good to know. The only annoying bit with that thing, is that you can't run it remotely with a git command (unless there's a new command I didn't know about). As a consequence, you need to have an interactive shell access and type the command on the server. Lucky, Alioth provides it and it's ok in our case. But sometimes, you don't have such access, and it's very annoying. Cheers, Thomas Goirand (zigo)
Re: Transition away from git-dpm was: Re: Adopting OpenStack packages
Thomas Goirand writes: >> Why debian/unstable, and not debian/sid? > > Because "unstable" is what we write in debian/changelog, so that's > consistent, and also consistent if we upload to experimental. But I'm > fine either ways anyway, if others would like to use debian/sid because > it's faster to type. At the moment - since there were no objections yet - I have revised the wiki documentation (link already provided) to include DEP-14 and debian/master (as per DEP-14). -- Brian May
