On 20 September 2013 12:08, Paul Tagliamonte <paul...@debian.org> wrote:
> Don't take this as me trashing on Python or Pythonistas. If you want to > talk > about this in person, I'm usually at PyCon. I'm also usually in the > packaging > BOF. Perhaps we can bring some of this up there this year? > Unfortunately, I don't think I'll be going to PyCon next year. I'll probably be at next year's SciPy, but I presume you won't be there? I'm glad to hear that you are a developer as well. However, a lot of the tone in this discussion suggests that all developers are idiots who can't keep an API intact. I think there is a much more productive conversation to be had with upstreams. > > help. Work with upstream developers to understand what they're doing, > encourage > > them to care about API stability and to use conventions like semantic > > versioning and deprecation warnings to reduce the impact of changes. > There are > > plenty of developers who do care about backwards compatibility. > > And just as many (if not more) that don't. As a result, we have to > design the system to defend against this breakage. > Alright, a proposal: create some kind of 'expedited upload' pathway, so upstream developers sign to say that they will use semantic versioning, never break APIs in a bugfix release, issue deprecation warnings for any code relying on something that they plan to remove, and create strong regression tests. We could add other reasonable conditions to this list. The carrot for developers is that, by agreeing to this, they get semi-automated uploads of minor updates (run the package's own tests, run DEP-8 tests of its dependencies, and a brief manual check). If projects that have signed break the requirements, kick them off the pathway for a couple of subsequent releases. At present, there is no carrot - getting stuff packaged is slow whether upstream cares about API stability or not. (I'm sure someone reading is about to point out a reason why this won't work exactly as I have described. Don't bother telling me - I'm not really expecting this will actually happen. But please try to think of how things might change, instead of why nothing must change.) > > We could also have topic-specific extra repos, so that a user can add, > say, a > > Python-science repo to get newer versions of some packages by accepting > a bit > > of extra risk associated with that. Neurodebian offers something like > that, but > > in general it's hard to set up. Ubuntu PPAs are much easier to get set > up, but > > don't build for Debian relases. > > PPAMAIN would be nice for special cases like this, aye! > OK, I searched that term. It's nice to see that Debian is finally considering setting up a PPA system. Did anything more happen on that after the mailing list thread got sidetracked into security questions? Elena: > there is an UpstreamGuide_ on the wiki: So promote it! I'm pretty sure I've never seen that URL before. > ITP bugs aren't cruft, they are a way to prevent duplication of work, > which would lead to even more frustration. That seems like an unlikely problem in real world cases - how often will two people decide to package the same, currently unpackaged, piece of software, within the couple of days or so before the first one publishes their work. And if it is necessary: make it simple. A web page listing 'things people have said they're working on packaging in the last week', with a text box to add something, would be easy to implement. Instead, I have to install a command line tool, run through several questions, paste it into an e-mail client, and then remember to close the bug in the package's changelog. It's a double-reciprocating sledgehammer with cruise control to crush an ant. ;-) > It takes more than the two weeks for AUR, but afaik it should take > less than the 4 months you mentioned: was the MIA team contacted? Yes. They never responded to me, but instead filed a bug which I didn't see. Most of the four months was then just waiting for someone to act on that bug. I didn't realise anything had happened until I checked on the package today. Thomas