On 2 January 2015 at 14:25, Donald Stufft <don...@stufft.io> wrote: > I’m going through the PEPs again, and I think that evaluating these PEPs is > more complicated by the fact that there is two of them, I agree that > splitting > up the two PEPs was the right thing to do though. What do you think about > putting PEP 480 on the back burner for the moment and focus on PEP 458. > > I think this will benefit the process in a few ways: > > * I believe that PEP 458 is far less controversial than PEP 480 since it’s > effectively just exchanging TLS for TUF for verification and other than > for the authors of the tools who need to work with it (pip, devpi, > bandersnatch, PyPI, etc) it’s transparent for the end users. > * It allows us to discuss the particulars of getting TUF integrated in PyPI > without worrying about the far nastier problem of exposing a signing UX to > end authors. > * While discussing it, we can still ensure that we leave ourselves enough > flexibility so that we don’t need to make any major changes for PEP 480. > * The problems that are going to crop up while implementing it (is the > mirror protocol good enough? CDN Purging? Etc) are mostly likely to happen > during > PEP 458. > * I think having them both being discussed at the same time is causing a lot > of confusion between which proposal does what. > * By focusing on one at a time we can get a more polished PEP that is easier > to understand (see below). > > Overall I think the PEPs themselves need a bit of work, they currently rely > a lot on reading the TUF white paper and the TUF spec in the repository to get > a grasp of what’s going on. I believe they also read more like suggestions > about how we might go about implementing TUF rather than an actionable plan > for implementing TUF. I’ve seen feedback from more than one person that they > feel like they are having a hard time grok’ing what the *impact* of the PEPs > will > be to them without having to go through and understand the intricacies of TUF > and how the PEP implements TUF. > > Technically I’m listed on this PEP as an author (although I don’t remember > anymore what I did to get on there :D), but I care a good bit about getting > something better than TLS setup, so, if y’all are willing to defer PEP 480 > for right now and focus on PEP 458 and y’all want it, I’m willing to actually > earn that co-author spot and help get PEP 458 into shape and help get it > accepted and implemented. > > Either way though, I suggest focus on PEP 458 (with an eye towards not > making any decisions which will require changes on the client side to > implement > PEP 480).
+1 on all of this. I agree that PEP 458 is (relatively speaking) an obvious thing to do, and if the people who have to do the work for it are happy, I think it should just go ahead. I'd like to see the PEPs reworded a bit to be less intimidating to the non-specialist. For PEPs about the trust model for PyPI, it's ironic that I have to place a lot of trust in the PEP authors simply because I don't understand half of what they are saying ;-) Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig