Clutter from v-1-2-3 recreated PR-s

[pevogam]

Hi all,

Just want to gather your opinions about this but I find the constant re-submission of PR-s of different versions very noisy for a few reasons:

1. Turning off the "watch" feature for a given PR feature provided by GitHub is not usable because new PR-s with the same purpose keep reappearing. Some of us thus have to constantly sign out of the same PR/topic.

2. It is harder for many developers involved in this project that want to be able to quickly glance what is going on to do so since our notification panel in GitHub is filled with [v1], [v2], ... [vN] PR-s, cluttering our space and making it hard to see what's really new.

3. Tracing the history of a PR is much more complicated since we cannot see how a feature was started by simply following a link to the PR page. Instead, we have to do additional PR searches and open many older PR pages at the same time, then trace back the entire history through them.

4. Not sure how easy it is to associate different versions with cards in GitHub's Kanban project management but I foresee it is way easier to do this with a single fully traceable PR. As we don't use it with multiple versions like this I cannot say more so this is rather a guess on my side.

5. If pushing multiple PR versions like this is trying to compensate for some information system deficiency of Github, it is rather better to bring this to the GH support team and see if it can be resolved for good.

These are some thoughts I have about this workflow. I am curious to see what upsides you see about it and what is the main motivation behind it.

Best,
Plamen

[beraldoleal]

Hi @pevogam,

Turning off the "watch" feature for a given PR feature provided by GitHub is not usable because new PR-s with the same purpose keep reappearing. Some of us thus have to constantly sign out of the same PR/topic.

That is true. And I understand your point. But developers could change the default settings right (in order to have an opt-in approach)?

It is harder for many developers involved in this project that want to be able to quickly glance what is going on to do so since our notification panel in GitHub is filled with [v1], [v2], ... [vN] PR-s, cluttering our space and making it hard to see what's really new.

I guess this is a personal taste. I don't find it difficult to filter things that I have to read on my notification panel. But again, I understand.

Tracing the history of a PR is much more complicated since we cannot see how a feature was started by simply following a link to the PR page. Instead, we have to do additional PR searches and open many older PR pages at the same time, then trace back the entire history through them.

Not sure how easy it is to associate different versions with cards in GitHub's Kanban project management but I foresee it is way easier to do this with a single fully traceable PR. As we don't use it with multiple versions like this I cannot say more so this is rather a guess on my side.

If pushing multiple PR versions like this is trying to compensate for some information system deficiency of Github, it is rather better to bring this to the GH support team and see if it can be resolved for good.

In theory, we should adopt the same subject for all versions and this could be easy for tracing the history with all PRs with the string "foooo". Also, if the PRs descriptions make mention to a particular issue/card it will list all PRs on that issue.

TBH, I like the force-push approach, and I was using for many times. But I have to admit that is not clear there what has changed from version to version. Yes, there is a very hidden link on the "force-pushed" event text that shows the differences, but this is a web-browser approach, and many developers like to compare what has changed in the command-line.

I'm open to alternatives here, but I understand that from the reviewer's perspective, having v1, v2... is better for comparing the changes.

[pevogam]

Hi @beraldoleal,

Turning off the "watch" feature for a given PR feature provided by GitHub is not usable because new PR-s with the same purpose keep reappearing. Some of us thus have to constantly sign out of the same PR/topic.

That is true. And I understand your point. But developers could change the default settings right (in order to have an opt-in approach)?

What do you mean here? Maybe I am missing something but AFAIK we could either unsubscribe from a particular PR (what I meant above but new PR-s with the same name keep popping up) or we could unsubscribe from the entire project which is clearly not desirable given all our collaborations within the project.

It is harder for many developers involved in this project that want to be able to quickly glance what is going on to do so since our notification panel in GitHub is filled with [v1], [v2], ... [vN] PR-s, cluttering our space and making it hard to see what's really new.

I guess this is a personal taste. I don't find it difficult to filter things that I have to read on my notification panel. But again, I understand.

Yes but even as such the current workflow influences all of our notification panels - the ones that find it simple as well as the ones that don't.

Tracing the history of a PR is much more complicated since we cannot see how a feature was started by simply following a link to the PR page. Instead, we have to do additional PR searches and open many older PR pages at the same time, then trace back the entire history through them.

Not sure how easy it is to associate different versions with cards in GitHub's Kanban project management but I foresee it is way easier to do this with a single fully traceable PR. As we don't use it with multiple versions like this I cannot say more so this is rather a guess on my side.

If pushing multiple PR versions like this is trying to compensate for some information system deficiency of Github, it is rather better to bring this to the GH support team and see if it can be resolved for good.

In theory, we should adopt the same subject for all versions and this could be easy for tracing the history with all PRs with the string "foooo". Also, if the PRs descriptions make mention to a particular issue/card it will list all PRs on that issue.

TBH, I like the force-push approach, and I was using for many times. But I have to admit that is not clear there what has changed from version to version. Yes, there is a very hidden link on the "force-pushed" event text that shows the differences, but this is a web-browser approach, and many developers like to compare what has changed in the command-line.

I see, this is a useful explanation that I was searching for when trying to motivate this approach. Granted, Github (cli tool or web interface) still has some improvements to build upon in this direction.

I'm open to alternatives here, but I understand that from the reviewer's perspective, having v1, v2... is better for comparing the changes.

I wonder if this load could somehow be transferred to the downstream utilities such developers use (i.e. using enhanced tools) which could also be a good way to localize the issue to fewer affected people. Just an idea of course.

[clebergnu]

Hi @beraldoleal,

Turning off the "watch" feature for a given PR feature provided by GitHub is not usable because new PR-s with the same purpose keep reappearing. Some of us thus have to constantly sign out of the same PR/topic.

That is true. And I understand your point. But developers could change the default settings right (in order to have an opt-in approach)?

What do you mean here? Maybe I am missing something but AFAIK we could either unsubscribe from a particular PR (what I meant above but new PR-s with the same name keep popping up) or we could unsubscribe from the entire project which is clearly not desirable given all our collaborations within the project.

Right, I don't think it's possible to get more granular than that.

It is harder for many developers involved in this project that want to be able to quickly glance what is going on to do so since our notification panel in GitHub is filled with [v1], [v2], ... [vN] PR-s, cluttering our space and making it hard to see what's really new.

I guess this is a personal taste. I don't find it difficult to filter things that I have to read on my notification panel. But again, I understand.

Yes but even as such the current workflow influences all of our notification panels - the ones that find it simple as well as the ones that don't.

Tracing the history of a PR is much more complicated since we cannot see how a feature was started by simply following a link to the PR page. Instead, we have to do additional PR searches and open many older PR pages at the same time, then trace back the entire history through them.

Not sure how easy it is to associate different versions with cards in GitHub's Kanban project management but I foresee it is way easier to do this with a single fully traceable PR. As we don't use it with multiple versions like this I cannot say more so this is rather a guess on my side.

If pushing multiple PR versions like this is trying to compensate for some information system deficiency of Github, it is rather better to bring this to the GH support team and see if it can be resolved for good.

In theory, we should adopt the same subject for all versions and this could be easy for tracing the history with all PRs with the string "foooo". Also, if the PRs descriptions make mention to a particular issue/card it will list all PRs on that issue.
TBH, I like the force-push approach, and I was using for many times. But I have to admit that is not clear there what has changed from version to version. Yes, there is a very hidden link on the "force-pushed" event text that shows the differences, but this is a web-browser approach, and many developers like to compare what has changed in the command-line.

I see, this is a useful explanation that I was searching for when trying to motivate this approach. Granted, Github (cli tool or web interface) still has some improvements to build upon in this direction.

I'm open to alternatives here, but I understand that from the reviewer's perspective, having v1, v2... is better for comparing the changes.

I wonder if this load could somehow be transferred to the downstream utilities such developers use (i.e. using enhanced tools) which could also be a good way to localize the issue to fewer affected people. Just an idea of course.

Myself and @beraldoleal actually had a conversation about this Yesterday. I believe that most of the deficiencies regarding the lack of history could be addressed with some tooling.

For instance, tools such as git publish can tag a branch incrementally so that you keep the same branch name. If that is applied to a single version PR approach in GH, we could have also a generated comment with links (or even the content) of the changes.

I also do not enjoy the manual aspects involved in creating multiple PRs, so I believe we should and could make life easier on reviewers (documenting and giving them easy access to the actual diffs) and at the same time to people receiving notifications.

[beraldoleal]

What do you mean here? Maybe I am missing something but AFAIK we could either unsubscribe from a particular PR (what I meant above but new PR-s with the same name keep popping up) or we could unsubscribe from the entire project which is clearly not desirable given all our collaborations within the project.

I thought that we could configure our settings to receive notifications only on what we subscribed to or mentions (an opt-in approach). I have to double-check on GH.

For instance, tools such as git publish can tag a branch incrementally so that you keep the same branch name. If that is applied to a single version PR approach in GH, we could have also a generated comment with links (or even the content) of the changes.

I really like the git publish tool, but I'm concerned about new developers' contributions and increasing the learning curve for them. So it could be optional for new developers, not sure. TBH, I have mix-feelings here.

[beraldoleal]

@pevogam I'm concerned with both: reviewers and contributors.

Tired of manually creating patch series emails? git-publish prepares patches and stores them as git tags for future reference. It works with individual patches as well as patch series. Revision numbering is handled automatically.

I might have missed something, but based on @clebergnu's comments and git publish ' README, I thought that he was suggesting that developers submitting patches would use this tool.

If not, then I'm ok using it.

[clebergnu]

I was not suggesting the use of actual git publish but doing/having something similar with regards to the version tagging. Actual git publish would not be practical, as it works by sending patch emails.

So, whoever wants to opt in (hopefully all frequent Avocado developers), would do something like:

$ git push-pr --version=1 remote topic-branch
$ git tag | grep topic-branch
topic-branch
topic-branch-v1

Then after getting feedback, responding one would do:

$ git push-pr --increment-version remote topic-branch # or --version=2
$ git tag | grep topic-branch
topic-branch
topic-branch-v1
topic-branch-v1

On top of that, the creation of the pointers to show the diffs on the web UI (or even a git diff | fpaste - of sorts) would be a nice addition.

Finally, gathering commit notes (if available) and compiling a human readable changelog would be the ultimate level of niceness.

[beraldoleal]

Thank you @clebergnu for the clarification. I had the same understanding.

So, it would be useful for sending patches in the v1, v2, ... approach. Probably I would be adopting something like this.

But (just to be extra clear) based on your reply, and on what I have said before, I'm assuming that you are ok with this not being "enforced", since, as I said before, it is increasing the new developers learning curve (one more tool/script to learn) and most developers are used to the GH force-push approach.

Did I understand correctly?

[clebergnu]

You understood correctly. We would not be turning down contributions because they are not complying with that workflow.

As I've seen on other communities/projects, as one's involvement grows, it's almost natural that the adherence to the general workflow and guidelines used by other, also grows. But I do think we can politely ask frequent contributors to also join the common workflow.

[pevogam]

I am in for anything that could reduce manual overhead and notification clutter that I mentioned originally.

At least from my admittedly limited contributor perspective, I would greatly appreciate both not having to track down each version of development out of my current context as well as not having to manually compile and push various additional copies of my original PR.