guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking package submissions with Debbugs


From: David Craven
Subject: Re: Tracking package submissions with Debbugs
Date: Mon, 5 Sep 2016 22:39:11 +0200

> 1. Our commit history is not full of merges of tiny branches, which is
>     what GitHub (and I thought Gitlab) encourages.

Yes, that is right. But as I mentioned in a different thread, there
are many projects where the maintainers agree to not use the merge
button because of this. Since we are using gitlab we can actually go
further than an agreement and disable the merge button entirely.

>   2. Contributors can revise their patch series (by rewriting history of
>      that series), and committers can incorporate the final patch set,
>      rather than the whole sequence of iterations.  This is what we
>      currently do; Gitlab should be able to recognize such patterns and
>      notice that the “merge request” can be closed, for instance.

It depends on how much modification the maintainers make before
pushing. It's git that has to recognize the commits as being the same.
If a contributor can rebase his branch after the PR was merged without
getting any conflicts, gitlab will also recognize that the PR was
merged. Since it's a lot easier to iterate without spamming the
mailing list we can in practice ask contributors to fix issues like
indentation themselves, and if the worst case happens, PR can be
closed manually (in the web interface).

>   3. People (especially, ahem, me!) can work from the comfort of their
>      favorite editor/terminal, or at least without having to run lots of
>      JS code and clicking around all day long.

That's what we all want. The only time it's required to use the web
interface is when creating a new issue or a new PR. After that you can
reply via email, rebase and push via git.

> I haven’t used Gitlab so I don’t know whether these requirements are
> satisfied.  If you set up an instance of Gitlab-free-software-edition
> and we do not have these problems, I’m happy!  :-)

Some adjustments to the workflow might have to be made, but I think we
have to give it a test run of at least a week or two before throwing
the towel ;-)

Who wants to take on this? Any volunteers?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]