[katello-devel] Trello for fighting the pull-requests mess

Fri May 24 09:59:34 UTC 2013

I feel your pane, but having another page/system (Trello) to organize it 
seems to me like more bureaucracy (as previously said).

So here is my attempt. I've just deployed a small bot to heroku which 
will be periodically doing:

1. assigning 'PR' label to all pull-requests, to be able to filter 
pull-requests on issue page [1]

2. scanning pull-request's comments' strings by regexps to assign 
additional labels '✓', '✘'
    * /:shipit:|ACK/ will trigger '✓'
    * /:x:|NACK/ will trigger '✘'

Additional labels and theirs regexps are configurable, so we can add 
more or improve the current ones.

Source is here [2]

Petr

[1] https://github.com/Katello/katello/issues?labels=PR
[2] https://github.com/pitr-ch/pr-labels/blob/master/lib/labelizer.rb

On 22.05.13 9:45, Ivan Necas wrote:
>
>
> ----- Original Message -----
>> Not opposed to this idea. Personally, email filters +
>> https://github.com/organizations/Katello/dashboard/pulls have kept me from
>> having any confusion.
>
> The problem with this approach is that everyone in the team has to deal with
> this, solving the same problem of handling PRs again and again. Personally,
> every solution that doesn't involve emails is better for me: if there was
> a survey for the most misused technology in history, I would vote for emails.
>
>> I think this idea helps with lots of community PRs and when you have lots of
>> large pull requests, but my concern is over enforcing this workflow on
>> small, short focused PRs (that a lot of our work tends to be). Something to
>> consider, the workflow you describe also introduces some steps and elements
>> of the process that we didn't previously have or enforce:
>>
>> - PR 'state'
>
> This is actually what I want. If you take a look the the PRs list in Github,
> you have no idea if somebody is handling that or not, or on which side is the
> ball right now.
>
>> - PRs being in a 'review' state
>
> Having the review state also keeps the list of "Waiting review" pull requests.
> There is quite often an issue that a PR is waiting for review for longer time
> than it should be.
>
>> - defined PR reviewers
>
> Just optional.
>
> In conclusion, I don't want anyone to enforce to do anything. And if folks feel
> that more like a bureaucracy than a thing helping with the work, I won't push
> it any further, keeping my personal synced trello board anyway.
>
> -- Ivan
>
>>
>> -Eric
>>
>> On Tue, May 21, 2013 at 10:28 AM, Ivan Necas < inecas at redhat.com > wrote:
>>
>>
>> Hi,
>>
>> I don't know how you feel about the pull-requests situation right now but I'm
>> getting quite lost, especially after the split.
>>
>> The information I want to see is:
>>
>> * what are the PRs that are not being reviewed yet
>> * is my PR being reviewed
>> * is the PR waiting for review, rework or is it ready to merge
>> * who is doing the review, who was asked to do the review
>> * watch PRs progress (especially when it was merged) when interested
>>
>> … and all of this for all our repos on one place.
>>
>> I kind of like the approach the Foreman team has [1]. Therefore I've set up
>> similar board for Katello [2]:
>>
>> https://trello.com/board/katello-pull-requests/519b4226fdc9a46b1c002dbb
>>
>> It works like this:
>>
>> 1) when a PR is opened in Github, new card is created in "New" list
>> 2) someone triages the PR (maybe the author itself), sets flags or due to
>> date if needed
>> 3) the author can assign the people that he would like to get reviews from if
>> any
>> 4) the cards is moved to "Needs review"
>> 5) when someone starts with the review, moves the card into "Active reviews"
>> (the information about
>> who moved the cards is logged in the card, so no need for explicit assignment
>> of the reviewer)
>> 6) depending on how the review ends up, the reviewer(s) move the card into
>> "Waiting on team advice"
>> (if someone else is needed for advice), "Waiting on contributor" if issues
>> found with the PR,
>> or "Pending merge" if everything is fine.
>> 7) in case the PR needed rework, after doing so, goto 3)
>>
>> When the PR is closed, the corresponding card in Trello is automatically
>> archived.
>>
>> As the integration piece, I've used the dcleal's fork of puppet-webhooks [3],
>> I'm running it on Openshift.
>>
>> The downside of this approach, that it needs a bit of discipline to move the
>> cards to "Active review",
>> "Waiting for contributor" or "Ready to merge", but since the ticked is
>> archived when the PR is closed
>> no matter in what list is it in, there should not be too much mess.
>>
>> The most important step is moving the ticked between "New", "Needs review"
>> and "Active review",
>> as this helps folks seeing what was not touched yet.
>>
>> How do you feel about this approach?
>>
>> [1] - Foreman Deep-Dive on PR process -
>> http://www.youtube.com/watch?v=mKWw349rQwE
>> [2] - Katello Pull-Requests Board -
>> https://trello.com/board/katello-pull-requests/519b4226fdc9a46b1c002dbb
>> [3] - Dominic Openshift fork of puppet-webhooks -
>> https://github.com/domcleal/puppet-webhooks/tree/openshift
>>
>> -- Ivan
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>