Under which umbrella should I package my Python IDE for beginners (Thonny)?

[Aivar Annamaa]

Hi!

I've developed a Python IDE for beginners, Thonny (http://thonny.org) 
and I intend to package it for Debian 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857042).


The application would consist of a Python 3 package named "thonny" 
(https://pypi.python.org/pypi/thonny), a simple launch script (python3 
-m thonny), desktop file and icon. It depends only on Python 3.4 or 
later with Tkinter.


For the needs of the main application, the Python package could be 
private for the application, but as 3rd party Thonny plugins may need to 
import something from there, it makes sense to treat it as a shared 
Python package.


By the example of similar app Spyder 
(https://packages.debian.org/sid/spyder3), I thought that it makes sense 
to create two binary packages: "python3-thonny" for the Python package 
and "thonny" for providing end user facilities. Would you agree with 
this plan?


If I want to publish Thonny under one of the Python teams, which one 
should I choose? (My own preference would be Python Modules, because I'm 
more comfortable with git than with svn).


If it's good idea to publish it under Python Modules Team, can you 
please add me to the team (my Alioth user is aivarannamaa-guest)? I've 
read the policy document and agree with it.


Is anyone willing to sponsor the package?

best regards,
Aivar Annamaa

Re: Backport of python-lockfile and suggested team maintenance

[Andreas Tille]

Hi Ben,

On Wed, Mar 08, 2017 at 03:13:09AM +1100, Ben Finney wrote:
> 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”.

You decided to use github instead of git.debian.org.  IMHO that is not
following good practice for Debian team maintenance since it makes
contributions (admitedly slightly!) harder.

> 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.

The pull request would force me to create my own clone on Github and I'm
not willing to do this extra work, sorry.  If you are interested you can
fetch changes from the backported upload (or in case others might NMUs)
and if this effort from your side outwights the advantages you see from
Github over git.debian.org that's fine for me.

> > 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.

Fine.
 
> 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.

DPMT policy[1] section "Maintainer".

Kind regards

Andreas.


[1] https://python-modules.alioth.debian.org/policy.html

-- 
http://fam-tille.de

Re: Adopting OpenStack packages

[Brian May]

Simon McVittie  writes:

> Here's a maybe-stupid idea: use http://dep.debian.net/deps/dep14/ branch
> naming (debian/master, debian/experimental) for that branch, and switch to
> it as the default branch (edit foo.git/HEAD on alioth) when unfreezing
> and "officially" switching to gbp-pq?

One thing we could do right now, for selected packages, is create a
debian/experimental branch, switch to gbp-pq, update to latest upstream,
and upload to experimental. This will not interfere in any way to do
updates to unstable/testing - which still use the master branch, and
similarly won't cause any confusion which branch to use.

These packages that we do this to probably should be excluded from any
post-freeze automatic bulk switch to gbp-pq however. As the procedure is
likely to different (unless there are changes in the master branch, this
probably just involve creating a new debian/master branch from
debian/experimental and deleting the old master branch).

It might pay to have a list somewhere of packages that have already been
converted to gbp-pq, and what branches. Of course it is easy to
autodetect this too, just look for the presence of a debian/.git-dpm
file in that selected branches.

Before doing any automated conversion, we should make the following
checks on the following branches:

* master: exists and has debian/.git-dpm file
* debian/master: this branch should not exist - no DPMT package should
  be using this branch name yet.
* debian/experimental: if this exists it should have a debian/.git-dpm

If any of these checks fails, the respository should be converted
manually. Or it might be an indication that the repository is already in
the required format.

Any other branches are probably not that important for the initial
conversion and can be done manually as required.

Assuming at the moment, that only few packages would require manual
processing, otherwise this may require a rethink.
-- 
Brian May 

Joining DPMT

[Gaurav Juvekar]

Hi,

I wish to upload and maintain humanfriendly(RFS: #852233), 
python-coloredlogs(RFS: #854249) and python-verboselogs(RFS: #854115) packages 
in DPMT so that a sponsor can upload them to experimental or sid. I also want 
to help create and maintain other packages from pending RFPs.

My alioth login is gauravjuvekar-guest

I have read the Debian Python Policy, the Python Library Style Guide, DPMT FAQ 
and the DPMT policy (https://python-modules.alioth.debian.org/policy.html) and 
I accept it.

-- 
Regards,
Gaurav Juvekar



signature.asc
Description: OpenPGP digital signature

Re: Transition away from git-dpm was: Re: Adopting OpenStack packages

[Simon McVittie]

On Wed, 08 Mar 2017 at 17:47:40 +1100, Brian May wrote:
> 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).

I think there's value in using debian/master for the focus of development
rather than arguing debian/master vs. debian/unstable vs. debian/sid,
on the basis that it's essentially an arbitrary choice, and debian/master
is what other packages are already using.

In a thread about moving from a less-widely-used tool-specific git repo
layout (git-dpm) to a layout that is used by a lot of teams and doesn't
even strictly require a particular tool (a gbp-pq-style patches-unapplied
branch), it would seem odd to introduce another DPMT-specific point of
divergence :-)

S