Bug#800903: ITP: jupyter-client -- Jupyter protocol client APIs
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: jupyter-client Version : 4.0.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_client * License : BSD-3-clause Programming Lang: Python Description : Jupyter protocol client APIs This package contains the reference implementation of the Jupyter protocol. It also provides client and kernel management APIs to work with kernels and the "jupyter kernelspec" entry point to install kernelspecs for use with Jupyter frontends. Cheers, Snark on #debian-python
Re: Git migration schedule
On Sat, Oct 3, 2015 at 7:52 PM, Stefano Rivera wrote: > The errors: > > Cannot "git-dpm init" package: adhocracy [8<] > Cannot "git-dpm init" package: urlgrabber those are 98 packages > I think these are mostly because the package has never been uploaded to > Debian, or has a new release staged, or has patch problems. > > > Then: > liblarch has > Orphaned tag commit: b'935216b70ff944f4fdef508a3ad9a53ede9aff93' > b'refs/tags/3.0-1' > namebench has > Orphaned tag commit: b'06ab8961db663cfd9002288ba098cd8aa523f81b' > b'refs/tags/1.1+dfsg-1' > > These, I don't care about. + other 2 > We can't merge the svn head into master on: > alembic > pycryptopp > pyme > python-concurrent.futures > python-django > python-eventlet > python-pip > python-reportlab > python-socksipy and other 9, for a grand total of 109 packages that cannot be converted to git, 13.5% of DPMT (oh, what about PAPT?) am I the only one thinking it's quite a huge number to be handled by hand? and whose hands will be the ones converting these packages? yours or Barry's dont seem enough and others will need training/time. Additionally, now we are in the middle of the 3.5 transition, and so packages will need updating rather quickly: are we sure this is the best time to push full throttle with the migration? I'd rather wait a little bit longer and have a more automatic migration at a calmer moment for python modules. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: Git migration schedule
Hi, Le dimanche 04 oct. 2015 à 20:03:29 (+0100), Sandro Tosi a écrit : > am I the only one thinking it's quite a huge number to be handled by > hand? and whose hands will be the ones converting these packages? > yours or Barry's dont seem enough and others will need training/time. There's a point to be made here : as long as the team works on the credo that everything must be svn or everything must be git, nothing will bulge. It's a general principle : all or nothing hence nothing! Accept the transition won't be instantaneous and proceed by steps: - disallow creating new packages as subversion repositories ; - migrate now those packages for which the script works ; - the rest should follow at a reasonable pace, and in hand with the maintainers/uploaders/whoever feels responsible. Stop talking about doacracy and actually move! Snark on #debian-python
Re: Git migration schedule
sorry, i forgot to ask another question: how will the packages already maintained in git be handled? On Sun, Oct 4, 2015 at 8:03 PM, Sandro Tosi wrote: > On Sat, Oct 3, 2015 at 7:52 PM, Stefano Rivera wrote: >> The errors: >> >> Cannot "git-dpm init" package: adhocracy > [8<] >> Cannot "git-dpm init" package: urlgrabber > > those are 98 packages > >> I think these are mostly because the package has never been uploaded to >> Debian, or has a new release staged, or has patch problems. >> >> >> Then: >> liblarch has >> Orphaned tag commit: b'935216b70ff944f4fdef508a3ad9a53ede9aff93' >> b'refs/tags/3.0-1' >> namebench has >> Orphaned tag commit: b'06ab8961db663cfd9002288ba098cd8aa523f81b' >> b'refs/tags/1.1+dfsg-1' >> >> These, I don't care about. > > + other 2 > >> We can't merge the svn head into master on: >> alembic >> pycryptopp >> pyme >> python-concurrent.futures >> python-django >> python-eventlet >> python-pip >> python-reportlab >> python-socksipy > > and other 9, for a grand total of 109 packages that cannot be > converted to git, 13.5% of DPMT (oh, what about PAPT?) > > am I the only one thinking it's quite a huge number to be handled by > hand? and whose hands will be the ones converting these packages? > yours or Barry's dont seem enough and others will need training/time. > > Additionally, now we are in the middle of the 3.5 transition, and so > packages will need updating rather quickly: are we sure this is the > best time to push full throttle with the migration? I'd rather wait a > little bit longer and have a more automatic migration at a calmer > moment for python modules. > > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: Git migration schedule
Hi Sandro (2015.10.04_21:03:29_+0200) > and other 9, for a grand total of 109 packages that cannot be > converted to git, 13.5% of DPMT (oh, what about PAPT?) They're all converted. There are just some remaining steps to do by hand, to reconcile the SVN history with upstream history, and convert patches to dpm. > am I the only one thinking it's quite a huge number to be handled by > hand? and whose hands will be the ones converting these packages? The maintainers. They'll have to learn dpm soon enough, anyway. Or a team volunteer army. 10 people x 10 each, should be quick enough. > Additionally, now we are in the middle of the 3.5 transition, and so > packages will need updating rather quickly: are we sure this is the > best time to push full throttle with the migration? I'd rather wait a > little bit longer and have a more automatic migration at a calmer > moment for python modules. Further automation is a *lot* more work. I don't think it's worth it. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Git migration schedule
Hi Sandro (2015.10.04_21:31:07_+0200) > sorry, i forgot to ask another question: how will the packages already > maintained in git be handled? Up to their maintainers (assuming they're following team standards). If people only have one git package, for testing, each, then this shouldn't be an issue :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: [DPMT] radical changes: automation, carrot and stick
This thread has had me thinking a bit. Hi Scott (2015.10.02_20:34:16_+0200) > Personally, I like the current approach where someone can either commit to > either strong team maintainership (DPMT in maintainer) or weak team > involvement (DPMT as uploader). If you'll check, I have done both and it > reflects my level of interest in the package. I like it too, but I don't actually use it very accurately. Whether I'm maintainer or uploader for a package is more an accident of history than anything else. I should probably fix that. That said I haven't found it makes much difference to people's contributions to my packages. I've woken up to find that something was added to SVN and uploaded, immediately. > Personally, I would find this kind of rule demotivating. I think it will > actually discourage participation which isn't what we want. There's a fundamental question to ask here. Do we want to welcome Python packages into the team, or do we want to put up barriers and require a level of commitment before packages can be brought into the team? What are the possible outcomes of either choice? I'd imagine that if we're open, we become the natural home for most Python packages in the archive. Transitions become easier, and standardisation of the vast majority of Python packages in the archive is within our power. We'll collect cruft. But so does the rest of the archive. I don't think being open will necessarily increase the amount of crufty Python in the archive. On the other hand, if we raise barriers, we reduce the size and influence of the team. The few packages we maintain, we can probably maintain to a higher standard. Maybe there'd be less bickering, because we'd be working together more (not that I think we have much). Newcomers would be rarer (there's a commitment) but more valuable to the team. Or would we start to attract people faster because of our level of activity? Of the newcomers we turn away, I don't think most will abandon their pet packages. They'll just not do it in our team. New Python teams will form, and many more Python packages will be individually maintained. I know most of us have QA interests wider than the team, and this isn't desirable for us. How would we feel if a cabal-free-python team formed? Would any of us join it? And as to cruft. What happens when a widely-used package that is maintained by a 3-month inactive maintainer gets evicted? Do we orphan it? Alternatively, is the team prepared to take on all these packages? If we want to seriously think about these issues, should we start lighter-weight? * Audit the team for crufty packages that should be RMed. * or need love. * Audit the team for inactive members. * ... and their packages. Doing something about these is within our power right now. Can we find "carrot" ways to encourage team members to work on packages besides their own? Many of the problems arising from inactive team members are problems that affect the wider Debian, equally. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: [DPMT] radical changes: automation, carrot and stick
On Mon, 5 Oct 2015 at 08:54 Stefano Rivera wrote: > There's a fundamental question to ask here. Do we want to welcome Python > packages into the team, or do we want to put up barriers and require a > level of commitment before packages can be brought into the team? Speaking for myself, I welcome anybody working on 'my' packages. As in making changes to subversion/git or even uploading packages. Sure mistakes can happen, packages might even become broken, however I think the risks of packages going unmaintained is far more damaging. I had several packages or mine fail to get into Jessie, because of trivial release critical bugs in dependent packages, and the official maintainer ignored the bug reports. I believe this is why we have team maintainers - so anybody can work on the packages. Yes - I could have also done an immediate NMU - however not being the maintainer I wasn't aware of the release critical bug until the packages had been removed and it was too late to do anything - the release team wouldn't let one package back in despite the fact the only bug was a problem with the copyright file. My impression is that it is a minority that get upset when people upload 'their' packages to the Debian archive without asking for permission first. I think these people tend to be active developers, so maybe these maintainers should be treated as special cases? My understanding - correct me if I am wrong - is that nobody has ever complained about committing changes to subversion/git. Which rather puzzles me that Thomas Goirand was removed from DPMT and PAPT - I believe (am I mistaken?) this removes his ability to commit changes to subversion (which was OK), but not remove his ability to upload packages (which was not always OK). > On the other hand, if we raise barriers, we reduce the size and > influence of the team. The few packages we maintain, we can probably > maintain to a higher standard. Maybe there'd be less bickering, because > we'd be working together more (not that I think we have much). > Newcomers would be rarer (there's a commitment) but more valuable to the > team. Or would we start to attract people faster because of our level of > activity? > With fewer packages in the team, we would end up with more packages being out-of-date and poorly maintained. This would lead to even more people installing packages directly using pip, and Debian packaging would become less relevant for Python developers.
