A few technical suggestions

[Ben Gamari]

lonetiger at gmail.com writes:

> Hi All,
>
Sorry Tamar, it seems I overlooked this.

> I wanted to give my own thoughts/suggestions for things we could do on the short/medium term
> To make things a bit better. As a whole I may be one of the few who likes the current setup so I 
> Propose enhancing the current toolset.
>
> I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest.
> And the discussion quickly becomes hard to follow as it branches  lot.
>
> My proposals (sorry for the brevity, I can expand if needed):
>
> * Link phab to github
>    Phabricator seems to have build in OAuth support.
>    As you'll likely need a github account anyway, why not
>    also support github logins? This would reduce the barrier of
>    needing multiple accounts that is often a complaint.
>  
Our Phabricator instance already supports GitHub logins. This is indeed
my primary means of authentication.

>  Would it be possible to maybe also extract the user's public
>  key from github automatically? That would reduce one of the barriers as well.
>  https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/
>
Sadly it seems that Phacility may be reluctant to implement this [1].

> * Link Trac to github
>  - used to login (OAuth support)
>  - readonly issues (to begin with?).
>    we already have a code mirror, why not mirror more content.

Unfortunately GitHub doesn't allow one to override the automatically
assigned ticket numbering, so we'd end up with two different sets of
ticket numbers. I think this would be worse than no mirror. This pretty
much sinks any possibility for using GitHub issues.

>  - sync issues back between the two
>  - gives us an ability to see which github users an issue affects
>    since they can then reference it.
>  - updates the users when an issue is fixed since it will be closed on GH.
>  - Gives us an indication of the importance of the tickets
>
>  As a whole, I find Trac MUCH better for ticket triaging than Github or Phab,
>  both of which seem to be quite bare and simple in what they provide.

I agree that Trac's ticket system is great. It is without doubt much more capable
than GitHub, which would be quite painful given our ticket load. That
being said, I am beginning to waver its merits relative to Phabricator.
Matthew Pickering pointed out that Phabricator indeed supports custom
fields, which is what gives Trac much of its power (this and the ability
to define custom ticket workflows, which Phabricator does not support AFAIK).

>  I am not in favor of ditching it. Also we have and continue to accept
>  patches just uploaded to Trac as a diff. We tend to ask people to
>  upload it to phab for better reviews and so it's attributed to them
>  when we commit. Some don't (and we then do it ourselves), most due.
>  If they don't need another login then I suspect almost all would.
>  
I don't mind this. Trac tickets are relatively few and far between.

>  There's a (seemingly) actively maintained project that does all the above, could we leverage it?
>  https://github.com/trac-hacks/trac-github
>  
Perhaps.

> * There is a trac plugin to generate a new section on trac
>   /doc which allows you to render and edit documentations checked into repo.
>   Could this be used to allow easier editing of non generated documentation?
>   
>   It's currently based on SVN, but maybe a git one exists too?
>   https://github.com/trac-hacks/tracdocs
>
> * Newcomers
>  - Expose newcomers information more by creating a new landing page
>  - Clean up build instructions. For windows, I have scripts to automate setup.
>    Often heard complain is that it is hard, but never hear why it's hard.
>    
>    In any case, my setup script for a 100% unattended build env setup for Windows
>    are here: https://github.com/Mistuke/GhcDevelChoco/releases
>    
>    These are entirely self contained environments that can be removed by a simple rm -rf /.
>    You can have as many as you want on the same machine without them interfering with eachother
>    or with whatever else you might have done to your GHC already installed.
>    
>    It's not 100% production ready but it works and does so well.
>
> * Updated Phab reviewers list to be more automated
>  - Assign reviewers next to the static list (as is currently done)
>    to maybe also include significant contributors to that file?
>    
>    The reason for this is that currently it's always the same people reviewing patches.
>    Their time is spread thin. Particularly on less popular platforms it basically comes
>    down to 4 people.
>  
Agreed. However, I suspect this would need to be a manual effort. There
is no easy way to achieve this with Herald as far as I know.

> * Update trac linters and pre-commit linters to be the same.
>  - particularly reject summaries that would be rejected on commit.
>    Often when I try landing patches (especially from others) I have to
>    edit the summary. Maybe arc should reject the diff if a push would fail?
>    
Again, I'm not sure that this is possible. Phabricator's linter support
doesn't cover commit messages AFAIK. Moreover, Phabricator itself sadly
requires the "Summary:" tag.

>    Also I want to say I love the summary document you have to fill in.
>    It ensures useful information is there later when I have to find out why
>    a change was made. So whatever we do, don't remove this.
>
> * Phab plugin to on signup ask for public key if none found.
>  - It's recently been made a requirement to require a public key to push to phab.
>    The error you get when you don't do this and try to push a patch is very very
>    cryptic and unintuitive. Could we make a plugin that asks the user to upload
>    a public key on trac if they haven't done so? Like a banner at the top?
>
Do you mean s/a public key on trac/a public key on Phabricator/?

> * Automate trac tickets
>  - Particular on new tickets post a friendly reminder that if they
>    want they can give it a hand in fixing it themselves.
>  - Parse information added, in particular check if reproduction steps
>    are there etc.
>  - If stack is used, kindly ask if a repo without can be used. The
>    amount of bug reports with stack is increasing and regardless of my
>    own opinion on the tool, these reports are not very useful as is.
>  - Maybe automatically CC people from a pool based on the information
>    in the ticket? I tend to miss tickets because my filters are quite
>    strict. Generally if the ticket doesn't mention my name, is directed
>    at me or has "Windows" in the body somewhere it will skip my inbox. I
>    review filtered tickets only once a week.
>  - If a newcomer assigns a ticket to themselves, have trac
>    automatically post links to useful pages:
>   * how to setup build environment.
>   * how to get help
>   * assign a mentor?
>   * after x amount of time with no progress, remind them again that
>     help is available
>
I'm honestly not sure how much of this is worth automating with Trac. My
last attempt at using Trac's XML-RPC interface ended in fruitless
frustration.

Cheers,

- Ben


[1] https://secure.phabricator.com/T4587

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160929/1fdc63d2/attachment.sig>