[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tracking package submissions with Debbugs
From: |
ng0 |
Subject: |
Re: Tracking package submissions with Debbugs |
Date: |
Mon, 05 Sep 2016 23:12:17 +0000 |
David Craven <address@hidden> writes:
>> 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?
How would we proceed with this? One of us sets up a gitlab instance on a
server under their control?
I could volunteer for a test run.
--
ng0
For non-prism friendly talk find me on http://www.psyced.org
- Re: Tracking package submissions with Debbugs, (continued)
- Re: Tracking package submissions with Debbugs, Alex Vong, 2016/09/03
- Re: Tracking package submissions with Debbugs, Efraim Flashner, 2016/09/03
- Re: Tracking package submissions with Debbugs, Alex Vong, 2016/09/03
- Re: Tracking package submissions with Debbugs, Andreas Enge, 2016/09/04
- Re: Tracking package submissions with Debbugs, ng0, 2016/09/04
- Re: Tracking package submissions with Debbugs, ng0, 2016/09/04
- Re: Tracking package submissions with Debbugs, David Craven, 2016/09/04
- Re: Tracking package submissions with Debbugs, Alex Kost, 2016/09/05
- Re: Tracking package submissions with Debbugs, Ludovic Courtès, 2016/09/05
- Re: Tracking package submissions with Debbugs, David Craven, 2016/09/05
- Re: Tracking package submissions with Debbugs,
ng0 <=
- Re: Tracking package submissions with Debbugs, Ludovic Courtès, 2016/09/07
- Re: Tracking package submissions with Debbugs, ng0, 2016/09/05
- Re: Tracking package submissions with Debbugs, David Craven, 2016/09/05
- Re: Tracking package submissions with Debbugs, Ben Woodcroft, 2016/09/05
- Re: Tracking package submissions with Debbugs, ng0, 2016/09/06
- Re: Tracking package submissions with Debbugs, David Craven, 2016/09/06
- Re: Tracking package submissions with Debbugs, Alex Vong, 2016/09/05