On Tue, 09.06.15 18:42, David Timothy Strauss (da...@davidstrauss.net) wrote:
> Let's just try the GitHub tracker. I like how it associates issues with
> pull requests and supports auto-linking for commit IDs, user names, and
> other issue numbers. Is there any serious use case for systemd upstream it
> doesn't support?
Here's one issue I have with the github bug tracker. Or maybe it's
more an issue with the github PR tracker... Anyway, if somebody finds
a bug in systemd two things might happen:
a) if he's a user/admin without C skills, he'll just file an
issue and that's it. that's great.
b) if he's a hacker with C skills he'll likely send us a PR
instead. But this is where the problems now start: Most likely
the first patch iteration will not be right, so we comment and
ask for a new PR, and close the old one. The two PRs will not
be closely related to each other then. In the best case they
will "reference" each other, but that's it. However what's
worse is that the bug is not tracked at all in the the time
between the old PR got closed and the new is opened. Now, we
could require that in the meantime a new "issue" has to be
created, but this is a manual process, and it will not inherit
labels and stuff, unless the user does so manually. And that's
nasty.
And of course, the issue that in case of a) we only end up in an
issue, and in case of b) when the first patch is actually good we only
end up in a PR is a major issue too.
I am not sure what to do about this yet. Maybe we can enforce that PRs
have to have an issue, or so.
Maybe anyone has an idea?
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
