On Mar 2, 2013, at 11:41 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Fri, Mar 1, 2013 at 9:39 AM, Doug Hellmann <doug.hellm...@gmail.com> wrote: >> >> On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: >> >>> Hello all, >>> >>> PyCon, and the Python Language Summit, is nearly upon us. We have a good >>> number of people confirmed to attend. If you are intending to come to the >>> language summit but haven't let me know please do so. >>> >>> The agenda of topics for discussion so far includes the following: >>> >>> * A report on pypy status - Maciej and Armin >>> * Jython and IronPython status reports - Dino / Frank >>> * Packaging (Doug Hellmann and Monty Taylor at least) >> >> Since the time I suggested we add packaging to the agenda, Nick has set up a >> separate summit meeting for Friday evening. I don't know if it makes sense >> to leave this on the agenda for Wednesday or not. >> >> Nick, what do you think? > > I think it's definitely worth my taking some time to explain my goals > for the Friday night session, and some broader things in terms of > where I'd like to see packaging going, but a lot of the key packaging > people aren't involved in Python language development *per se*, and > hence won't be at the language summit. OK, a summary seems like a good idea. > > There's also one controversial point that *does* need to be raised at > the summit: I would like to make distutils-sig the true authority for > packaging standards, so we can stop cross-posting PEPs intended to > apply to packaging in *current* versions of Python to python-dev. The > split discussions suck, and most of the people that need to be > convinced in order for packaging standards to be supported in current > versions of Python aren't on python-dev, since it's a tooling issue > rather than a language design issue. Standard lib support is necessary > in the long run to provide a good "batteries included" experience, but > it's *not* the way to create the batteries in the first place. Until > these standards have been endorsed by the authors of *existing* > packaging tools, proposing them for stdlib addition is premature, but > has been perceived as necessary in the past due to the confused power > structure. +1 -- anything to reduce the confusion about where to get involved :) > > This means that those core developers that want a say in the future > direction of packaging and distribution of Python software would need > to be actively involved in the ongoing discussions on distutils-sig, > rather than relying on being given an explicit invitation to weigh in > at the last minute through a thread (or threads) on python-dev. The > requirement that BDFL-delegates for packaging and distribution related > PEPs also be experienced core developers will remain, however, as > "suitable for future stdlib inclusion" is an important overarching > requirement for packaging and distribution standards. Such delegates > will just be expected to participate actively in distutils-sig *as > well as* python-dev. > > Proposals for *actual* standard library updates (to bring it into line > with updated packaging standards) would still be subject to python-dev > discussion and authority (and would *not* have their Discussions-To > header set). Such discussions aren't particularly relevant to most of > the packaging tool developers, since the standard library version > isn't updated frequently enough to be useful to them, and also isn't > available on older Python releases, so python-dev is a more > appropriate venue from both perspectives. > > At the moment, python-dev, catalog-sig and distutils-sig create an > awkward trinity where decision making authority and the appropriate > venues for discussion are grossly unclear. I consider this to be one > of the key reasons that working on packaging issues has quite a high > incidence of developer burnout - it's hard to figure out who needs to > be convinced of what, so it's easy for the frustration levels to reach > the "this just isn't worth the hassle" stage (especially when trying > to bring python-dev members up to speed on discussions that may have > taken months on distutils-sig, and when many of the details are > awkward compromises forced by the need to support *existing* tools and > development processes on older versions of Python). Under my proposal, > the breakdown would be slightly clearer: > > distutils-sig: overall authority for packaging and distribution > related standards, *including* the interfaces between index servers > (such as PyPI) and automated tools. If a PEP has "Discussions-To" set > to distutils-sig, announcements of new PEPs, new versions of those > PEPs, *and* their acceptance or rejection should be announced there, > and *not* on python-dev. The "Resolution" header will thus point to a > distutils-sig post rather than a python-dev one. distutils-sig will > focus on solutions that work for *current* versions of Python, while > keeping in mind the need for future stdlib support. > > python-dev: authority over stdlib support for packaging and > distribution standards, and the "batteries included" experience of > interacting with those standards. Until a next generation distribution > infrastructure is firmly established (which may involve years of > running the legacy infrastructure and the next generation metadata 2.x > based infrastructure in parallel), the stdlib will typically trail the > upstream standards substantially, since many upstream enhancements > will run afoul of the standard library's "no new features" rule, > preventing their inclusion in maintenance releases of old Python > versions. > > catalog-sig: authority over the PyPI index server (supported by the > infrastructure SIG for actual operation of the service). Key people > are expected to also participate in distutils-sig, as that is where > the expected interface exposed to automated tools will be defined. How > PyPI exposes the packaging and distribution standards to *users* > through its web UI will be up to catalog-sig. > > The vehicle for *documenting* such a change in policy would be an > update to PEP 1 to indicate that the "Discussions-To" header should > always point to the list where any formal acceptance of rejection of > the PEP would be announced. If preliminary discussions take place on a > feeder list like python-ideas, or import-sig, or somewhere else, that > will be declared as explicitly irrelevant from the PEP metadata point > of view: the Discussions-To field would be documented as referring to > the list that any Resolution field will eventually reference. > > Regards, > NIck. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com