Page MenuHomePhabricator

[Task] Do a "clean up open pull requests on GitHub" day
Closed, DeclinedPublic

Description

We talked about an additional "GitHub day" in addition to the the planned "Gerrit day" and the two "Phabricator days" we already did. Here is what I'm suggesting:

  • There are some really, really old pull requets that are just sitting there, rotting and slowly dying, the worst example probably being the WikibaseQueryEngine integration tests.
  • Let's try to merge as much as we can and do releases right away, so changes don't get stuck in dev pre-releases (I made this mistake to often).
  • I suggest to avoid discussions about the version number scheme. Use the smallest increase that's necessary. In the 0.x.x range a 0.1.x step is for breaking changes and a 0.0.1 step is for new features.
  • Many pull requests need a rebase. This should usually be done by the original author. It's common practice to squish multiple commits in this case.
  • If a rebase is done by an other user, he should usually add a new commit so the original author can see what happened.
  • We can also use the time to work on moving GitHub repositories to Gerrit (see T74907), most notably T112120: [Task] Move ValueView repository from github to gerrit.
  • All this is much easier if the involved persons are sitting in the same room.

On GitHub you use the search, it can do pretty much the same as the Gerrit board if you know how:

Event Timeline

There are some really, really old pull requets that are just sitting there, rotting and slowly dying, the worst example probably being the WikibaseQueryEngine integration tests.

As we are not sure we will continue work on that component, why would we spend time and effort on these?

I'm listing an example, not saying we should work on this.

thiemowmde set Security to None.
thiemowmde added subscribers: JanZerebecki, daniel, aude, hoo.

There are some really, really old pull requets that are just sitting there, rotting and slowly dying, the worst example probably being the WikibaseQueryEngine integration tests.

As we are not sure we will continue work on that component, why would we spend time and effort on these?

We should spend the effort to make it clear that we won't continue work on it, which includes closing the pull requests.

I'm listing an example, not saying we should work on this.

That is not how I'm reading the description of this task. Can you reword it?

We should spend the effort to make it clear that we won't continue work on it, which includes closing the pull requests.

Adding a note to the readme seems like a better approach to me.