| 
      
      
      From: John P. R. <ro...@cs...> - 2019-05-16 01:36:33
      
     | 
| Hi Ezio: Thanks for keeping us in the loop. In message <CAC...@ma...>, Ezio Melotti writes: >earlier today it was announced on python-dev[0] that PEP 581[1] has >been accepted. >PEP 581 proposes that CPython abandons Roundup in favor of using >GitHub issues. Oh well. Does that mean issues.roundup-tracker.org will go away as well? >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. We discussed this in irc a while back, but in PEP581, they say: Users email addresses are exposed. There is no option to mask it. Where are the emails exposed? Unless you are an admin or privileged user, you don't see emails. issues.roundup-tracker.org) doesn't show emails. All you see is the username. Are you guys using email addresses as usernames? If so maybe adding: setlabelprop("realname") would work. Without a labelprop, the key property (username) is used. Also: There is no REST API available. There is an open issue in Roundup for adding REST API [9]. Last activity was in 2016. make that last activity was Sun Apr 28 18:28:44 2019 and it is being actively developed (and documented??). I have patches for adding a rate limit to the rest api, but there are some performance/db contention issues I am trying to work out. Regarding: It sends a number of unnecessary emails and notifications, and it is difficult, if not impossible, to configure. ... Upstream ticket https://issues.roundup-tracker.org/issue2550742 There is now a mechanism to reformat the message body via the note_filter. See changeset 5675:f3d68c1bb96e from March 29 2019. See https://issues.roundup-tracker.org/issue2551018 for example and details. The complaint about sending a message on nosy field change is confusing to me. Choosing to generate the message is and has always been done via the tracker. Roundup sends nothing by default. nosyreactor.py is where that is usually configured. Also IIRC the default is not to send anything unless there is a message. So I am not quite sure what the deal is here. 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-(. The statement: The upstream Roundup code is in Mercurial. Without any CI available, it puts heavy burden on the few existing maintainers in terms of reviewing, testing, and applying patches. Is incorrect and has been for a few years. There is a git clone (https://github.com/roundup-tracker/roundup), travis ci (https://travis-ci.org/roundup-tracker/roundup) and codecov (https://codecov.io/gh/roundup-tracker/roundup/commits) pipeline. I have integrated pull requests from git in the past. (There is one pending pull request for the jinja templates that's about 6 months old, so this may not be a point in roundup's favor.) Also since there is a git clone, I think: There is an open discussion about moving the source code of bpo to GitHub. If the source code of bpo does move to GitHub, it will become difficult to update patches from upstream. But as long as it is in Mercurial, it is difficult to maintain and onboard new contributors. is invalid. You can just fork it on github like others have done. The statement on the number of maintainers and the burden on the maintainers is valid. Also the statement: In its current state, the project is not equipped to accept lots of contributions from people who aren't already familiar with the code base. Seems to just be a restatement of the burden on the maintainers bullet point. 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. 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. There is an example of markdown processing a message, but setting up a preview (using a js markdown processor or round tripping to the server) would need to be developed along with preview, so * Support for markdown and emoji. * Preview tab, showing how a comment will be rendered, prior to actually posting. are valid points. Also if: * Administrators and core developers can edit issues, comments, and pull requests. means, change/edit the actual text of sombody's message that would take a little work. I would probably implement it by modifying the msg class by adding adding a previous_copy link to msg. Then "editing" a message is creating a new message, updating the text and submitting the message. Link the new message to the older message via the previous_copy link so you can track changes across time. * Support for voting via reactions. Two additional fields on the issue: "I want this 8-)" "I hate this 8-(" that are multilinks to users. Allow the users to add/remove themselves by editing the fields, or by hitting a button. This is also true: * Core developers, volunteers, and the PSF don't have to maintain the issue infrastructure/site, giving us more time and resources to focus on the development of Python. but that also brings a downside. If you want to make changes that don't align with the platform to make things more efficient you can't. We are having that issue with a well known 4 letter starts with j bug tracking system at work. * Ability to automatically close issues when a PR has been merged [6]. The PR merge process can't send an email to roundup to close the ticket? It can't generate an xmlrpc request. The xmlrpc interface has existed since Tue Apr 03 16:52:51 2007. If they had said "Pre-existing mechanism to automatically ..." I would agree. * Email notifications containing metadata [7], integrated with Gmail, allowing systematic filtering of emails. There is already a bunch of metadata in the headers of roundup notifications in the form of: X-Roundup-issue-prop: value e.g. X-Roundup-issue-keyword: SV:DACS, First Time Failure, ... X-Roundup-issue-status: open X-Roundup-issue-priority: routine and X-Roundup-Name: Sysadmin issue tracker I filter these all the time into folders by priority, keyword etc. Adding another header that integrates with Gmail (or embed metadata in the body) to supply the "see issue" button should would be possible. Sending plain and html with emoji, #links etc is a nice touch but ... * Additional privacy, such as offering the user a choice to hide an email address, while still allowing communication with the user through @-mentions. The email privacy issue I discussed above. Adding support for notifications to a user when @username is in the body of a message is doable. parse the @user out of the body of the message in nosyreaction.py and add the user as a bcc or cc to the outgoing message. Also with the note_filter you can change #link (whatever that is) into a real link etc. However things like: * Ability to reply to issue and pull request conversations via email. Why does somebody think roundup doesn't do this? That's one of it's core features.... I does have rudimentary support for HTML email though, so if that's what they mean then yeah it gains some validity. * Support for permalinks [5], allowing easy quoting and copying & pasting of source code. permalinks are just a url. Embed it in an email or roundup message and guess what ... you have a permalink in roundup. So again not sure what they really meant to say. That is a possible advantage of moving to github over mercurial but I don't see it as a tracker advantage. Just mystify me.... >Before the announcement, I also submitted a Google Summer of Code >(GSoC) idea[5] with the goal of porting the REST API to b.p.o and >develop tools that use it. The idea got accepted, and I got a student >that will start working on the project next week. Very neat. >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. Have a great week and thanks again for the updates. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |