[systemd-devel] [ANNOUNCE] Git development moved to github

[Lennart Poettering]

On Tue, 09.06.15 14:54, Filipe Brandenburger (filbranden at google.com) wrote:

> On Tue, Jun 9, 2015 at 2:37 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Tue, 09.06.15 13:04, Filipe Brandenburger (filbranden at google.com) wrote:
> >> On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering <lennart at 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