Re: PEP 581 and Google Summer of Code
"John P. Rouillard" <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.roundup.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Ezio: In message <CACBhJdGj=FV5e+340WKQW959Es4eig=n32wOcGuxn5EtrVXHtw@mail.gmail.com>, Ezio Melotti writes: >On Thu, May 16, 2019 at 3:36 AM John P. Rouillard <[email protected]> wrote: >> In message >> <CACBhJdG7OOXzfGCLXL9N3o8Dy9i6KQfevnFfGLBZtFbO-hha4Q@mail.gmail.com>, >> Ezio Melotti writes: >> Oh well. Does that mean issues.roundup-tracker.org will go away as >> well? >> >The plan is to keep our instance around and read-only, so Roundup will >still need to be up and running. issues.r-t.org should be unaffected. >See https://www.python.org/dev/peps/pep-0588/#make-bpo-read-only > >> >The migration plan is described in PEP 588[2], which is still a draft >> >and not yet accepted, so it will likely take some time before PEP 588 >> >is approved and the actual migration takes place. >> >In the same thread, Guido said[3] that people can submit PR to the >> >peps repo[4] to correct factual errors in the PEP 581 or to write a >> >PEP against the move. >> >> Well, I can't open a pep apparently. > >Berker pushed an initial draft to >https://github.com/berkerpeksag/peps/blob/pep-593/pep-0593.rst >You can send PRs there, or directly to PEP 581 if you prefer >(https://github.com/python/peps). I never got into the whole github ecosystem. My git fu is limited to a canned series of commands to sync roundup mercurial to git and the occasional git clone/pull on some code hosted at github. >> [skipped stuff you didn't reply to] >> The report: >> >> Creating an account has been a hassle. There have been reports of >> people having trouble creating accounts or logging in. >> >> I wish there were links to the tracker's issue tracker so I could see >> some details. That meta tracker seems to be totally gone. But again I >> don't know of any issues. We have had spammers create accounts on >> issues.roundup-tracker.org so I know at least some people can create >> accounts 8-(. >> >A new metatracker was created on github a while ago, and after a while >the original metatracker got closed without migrating all the open >issues. I actually wanted to look at the closed issues as there are tickets there that are referenced from roundup.i-t.org. I have fogotten which tickets I needed. I think issue262, "skip searching file contents" was one of them. >We still have backups of the original metatracker, so we could >resurrect it somewhere if needed. >The new metatracker is at https://github.com/python/bugs.python.org/issues Thanks for the link. >The main issue was that often tracker emails were detected as spam, >and users were watching their inbox and waiting for a mail that was >already sitting in their spam folder. >The issue was discussed and I think partially solved, so I'm not sure >how many people were having issues recently. Ah ok, yeah I remeber that. Email from github would probably have more resources to work with mail (gmail, yahoo, aol, ... etc.) providers to bypass spam filters. >Adding a way to login using github credential should solve this (and >other) problems. How so? the email sent from roundup would not have the github.com email blessing. >> It looks like: >> >> >Berker Peksag and I are working on a PEP about improving >> >bugs.python.org (b.p.o). >> >> addresses: >> >> The user interface needs an update and redesign. It will >> require UX/UI research to keep it up to date with current web >> standards, including accessibility. >> > >Actually this is an area we might need some help. >While on the technical side I can solve some of these issues, on the >"artistic" side I'm not particularly skilled. Yeah well you can see my UX skill at the demo tracker, so not much skill in that area here 8-). >For example I could find a typeface and a color palette that is easy >to read and had good contrast values, but it will probably look >hideous :) >I believe Berker has more experience when it comes to design. >It should also be discussed what kind of UX/UI changes we want to >have, and consequently the skillset required to implement them. Agreed. >> I do like some of the features of github issues: >> >> * Ability to embed/drag and drop screenshots and debug log files >> into GitHub pull requests and issues. >> >> * Support for two factor authentication. >> >> This would have to be developed for roundup, I would suggest using >> oauth2/OpenID which I think github can act as a server for so people >> can use their github identities. >> > >This has been discussed on the metatracker and there's is a patch on >the new metatracker: >https://github.com/python/bugs.python.org/issues/7 Nice. I may have to try to play with that. >Thanks for all the feedback, even though I haven't replied to all your >points, I'm planning to integrate what you said in the PEP I linked >above. Thanks. I am glad my musings will be helpful. If you have questions or need me to provide more detail/thoughts let me know. >> >If CPython abandons Roundup, the focus of the project will likely >> >shift from developing b.p.o-specific tools, to generic tools that can >> >be used by any Roundup user. This will depend on how the situation >> >evolves in the following days. >> >> That would be nice. How do we prevent the issue that happened with the >> rest interface. It would be nice to get these changes integrated into >> the mainline project as we go rather than waiting 2 years. > >I expect this won't be a problem this time around. The REST API was >an ambitious project, and while the student did a great job on it, I >didn't feel confident enough to simply merge it as it was, especially >considering the security implication. I looked for someone who could >help me review the work and make sure it was safe to merge but I >didn't have much success, and eventually the project sat there until >you resurrected it :) I can't take credit for the resurection. It was Ralf Schlatterbeck that did that work. >This new project comprises a series of smaller-sized and independent >sub-projects, many of which are standalone and don't require changes >to Roundup, so I think it will be much easier to develop and deploy >them (either as separate tools, or include them in Roundup). Ok, that makes me feel better. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions.