Re: [Roundup-devel] PEP 581 and Google Summer of Code

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.