On 4/16/19 1:51 PM, rawfiner wrote:
Using github by commenting directly on PRs
I'm in favor of this with some modifications with the mailing list as a
second choice. IRC is too ephemeral without logging and conversations
can go on for days and end up intermixed with other topics, making it
hard to pick through.
PRs shouldn't exist until there's code to be pulled. Sometimes there's
discussion about a project before anyone writes a single line. These
projects should be started as issues that we can organize using tags.
pros:
- we can comment directly near the code, and we can comment code details
- people can see the message when they want, and reply when they want,
wherever they are on the planet
- we can have conversations organised by topics (PRs)
In addition to all of that, the commits can refer to the issues (e.g.,
"Overhaul of malloc() and free() #1234") so anyone looking at the code
has a near-direct path to the entire history of how it got there.
If a discussion takes place elsewhere (IRC or the mailing list), the
conversation should be copied out and added to the issue or, if it
persists, add a link to it.
cons:
- devs will have to check new PRs regularly to give their opinion, and
a big-change PR may "hide" in between small ones. However, we could
easily have a tag "big-change" to request devs to pay attention to
particular PRs, or use the PRs names to indicate such big changes
This isn't any different than looking at the issues that get written for
bugs, which makes a good case for using issues (or Redmine or anything
similar).
- big changes should be discussed before making them. Yet, I think
this drawback can be compensated by making PRs really early, which is
already done by several of us (see PRs with [WIP] in the title)
Work-in-progress PRs lower the signal-to-noise ratio for those
considering PRs. If someone is working on a project, they should be
doing it in their own GitHub space and requesting a pull when it's ready
to be integrated.
As for the concerns about GitHub going away: Everything the project has
on GitHub can be backed up. I do this twice a day for my own work and
anything I depend on (darktable included):
https://github.com/markfeit/github-backup.
Another way to have this discussion would be to come up with an
agreeable workflow and then find the tools that fit it.
--Mark
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
