On Tue, 09.06.15 14:54, Filipe Brandenburger (filbran...@google.com) wrote:
> On Tue, Jun 9, 2015 at 2:37 PM, Lennart Poettering > <lenn...@poettering.net> wrote: > > On Tue, 09.06.15 13:04, Filipe Brandenburger (filbran...@google.com) wrote: > >> On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering > >> <lenn...@poettering.net> wrote: > >> > [...] so we comment and ask for a new PR, and close the old one. > >> > >> See my previous comment, I think this "cure" is worse than the > >> "disease" :-) > > > > Why would you say this? Why are multiple sequencial PR, where the old > > obsoleted ones are closed and locked that bad? > > - Too much administrivia Yes, I with this was easier to do. But I figure it's OK to do if you have the git shell helper stuff in place. > - Threads get split up (did I comment on the origina PR or on this > one?) Yeah, it generally requires a regime for everybody to stick to code disccusions in the PR comments, and conceptional discussions in the issue comments. Also, when we obsolete a PR we should "lock" it to ensure people stop commenting there. > - Hard to follow the references around Yupp. > I actually think the fact that in GitHub you'll use a PR *or* and > Issue is actually good, so you mainly have a single thread to discuss > the same item... Well, but it's really weird... If you start out with a patch things are tracked as PR. If you start out without a patch things are tracked as an issue. And they have quite different workflows, as PRs cannot be reopened and issues can, for example. I am pretty sure issues should be at the core of things... WHat really surprises me about the whole discussion is that we cannot be the first ones running into this. Given the success of github this must be a common issue. And if it is, then either github is actually prety bad, or I am too stuck in my bugzilla mindset and haven't really grokked the github way of doing things yet. > I just think that working around the GitHub bug of losing comments by > creating a convoluted workflow around it (which is hard to enforce, as > you can't really block PR authors from using `git push -f`) is the > wrong approach... Well, I can actually enforce it by closing the PR and locking it. > Maybe someone should complain to GitHub about this issue with losing > track of the comments on the previous versions of the code instead? Well, that's not sufficient at all, see above. > If that was fixed in GitHub, would you be happy not splitting multiple > PRs for multiple versions of the same feature/issue? I would prefer if we'd have immutable history. i.e. each issue that is raised should keep its comments, its patches, its reviews forever, but just get them marked obsolete but not vanished. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
