[Twisted-Python] overview: new review queue venue

[Glyph]

> On May 21, 2016, at 11:36 PM, Amber Hawkie Brown <hawkowl at atleastfornow.net> wrote:
> 
> 
>> On 22 May 2016, at 14:32, Glyph <glyph at twistedmatrix.com> wrote:
>> 
>> 
>>> On May 21, 2016, at 11:21 PM, Amber Hawkie Brown <hawkowl at atleastfornow.net> wrote:
>>> 
>>> 
>>>> On 22 May 2016, at 14:15, Glyph <glyph at twistedmatrix.com> wrote:
>>>> 
>>>> Sorry, I guess I wasn't clear.  I know that PRs are presently a potential alternative to a diff, and that we are still using Trac for ticketing.  I want to make it possible to avoid using Trac for ticketing; perhaps switching to github issues entirely.
>>> 
>>> This is an optimistic idea but one that, unfortunately, won't happen yet ;)
>>> 
>>> The things GitHub Issues need to be competitive with Trac as it stands:
>>> 
>>> - Allowing triage by people without write.
>> 
>> How are things currently "triaged"?  Do you mean "review"?  If so, I think it would be acceptable to come up with a magic comment for a non-commiter to use to signify that they've fully reviewed a PR.  As it stands, we need committers to "accept" a review by deciding to merge, the only difference here is that it would remain in the review queue until they did so, which I think is acceptable (since if the review isn't accepted, it should have remained in the queue anyway).  We could also have a bot address this edge-case somehow.
> 
> Creating a ticket, adding it to the relevant milestone (commit required on GitHub), setting the component (which would be a tag on github, requires commit)...

I don't see us getting a lot of non-committer triage of this kind.  And I'm not sure that's really an important part of our workflow - do you really feel that it is?  Frankly when non-committers try to put their changes into a milestone or start adding custom keywords, it's almost always wrong.

We also don't use "component" for much.  If we just got rid of it, would any part of our process change?

>>> - Useful search (GitHub search is kind of abysmal)
>> 
>> I don't see how Trac's is better.
> 
> It has a GUI rather than being stringly typed ;)

Oh, you're talking about "query", i.e. https://twistedmatrix.com/trac/query, not "search", i.e. https://twistedmatrix.com/trac/search ?

GitHub's search is actually structured, not stringly typed; there's a bit of GUI here: https://github.com/search/advanced.  It does resolve down to a string query, but so does the trac "custom query" eventually (in that it goes into a URL you can copy and paste).

But, this is all sort of abstract: what kinds of queries would you do against our ticket database in Trac that are not possible in GitHub's query language?  Personally after some exploration of GitHub's query language I have found it's actually more expressive for what I want to do most of the time; particularly querying across projects which is obviously not possible with trac...

>>> - Assigning to non-committers.
>> 
>> Honestly I'm not sure that the non-committer assignment part of the workflow is all that useful.  I know I hardly ever look at report 7, and I very much doubt any non-committer does :).  It's not like we're losing information, either; we still have a record of whose fork the PR points to.
> 
> I look at report 7 :(

That's not a counterexample: you are a committer :-).

I do actually have a recurring personal to-do item to check report 7 nowadays, but almost all of my doing-stuff-on-the-tracker has to do with me getting emails about actionable state changes (somebody reviewed your change, you should merge it), rather than scanning that list.

>>> Without these things (and quite a few more), it's unlikely that GitHub Issues will be as useful to us.
>> 
>> I am curious about the "quite a few more".  There are things which we really need as a critical part of our workflow (primarily: the review queue) and then there are accidents of the way trac works.  Nothing is graven in stone here :).
> 
> I guess there's a lot of things that are an accident of trac, but the things above are useful.

I'm not disputing that, but I'm still a little confused about how exactly they're useful, rather than just different.  Can you give some examples of things you do regularly?

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160522/0a6dbf9b/attachment-0002.html>