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

[Ronny Chevalier]

On Tue, Jun 2, 2015 at 1:06 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
> Hi
>
> On Mon, Jun 1, 2015 at 8:12 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> Hi
>>
>> As of today we've disabled git-push to fd.o. The official development
>> git repository is now at github [1]. The old repository will still be
>> back-synced, but we had to disable push-access to avoid getting
>> out-of-sync with github.
>>
>> In recent months, keeping up with the mailing-list has become more and
>> more cumbersome, with many of us missing mails or unable to keep up
>> with the traffic. To make sure all community requests and patches will
>> get handled in time, we're now trying out the github infrastructure.
>> We encourage everyone in the development community to switch over now,
>> even though the old fd.o infrastructure will still be maintained.
>> Distributions are free to wait until the next release announcement
>> before updating anything.
>>
>> If github does not work out, we will see what else we can try out. But
>> lets give it at least a try.
>
> Short update trying to answer all the questions:
>
> Our preferred way to send future patches is "the github way". This
> means sending pull-requests to the github repo. Furthermore, all
> feature patches should go through pull-requests and should get
> reviewed pre-commit. This applies to everyone. Exceptions are
> non-controversial patches like typos and obvious bug-fixes.
> The exact 'rules' on when to merge a pull-request need to be figured
> out once we get going. Ideas welcome! Until then, just apply common
> sense. Push-access can be granted to contributors like before.
> However, given that we want a pre-commit review model, it will not
> make much of a difference which person eventually merges the patches.
> We still highly appreciate the effort spent by many commiters to
> review and apply trivial changes up to critical bugfixes. This worked
> well and we want to keep this model, but avoid it for any feature
> development.
>
> The mailing-list will still be used for non-code related discussions,
> and I think (?) patches from new contributors on the ML might still be
> handled as before. But I guess this is mostly limited to trivial
> patches. Bigger patchsets should really go through github to avoid
> them getting lost on mailing-lists.
> Regarding the bug-tracker, I honestly don't know what the plan is. I
> think the plan is to stick to everything github provides us, to make
> sure we don't spread our tools across multiple hosts. However, I
> personally would prefer to discuss this in the community and see what
> issues come up. Anyone?
>
> The reason behind this move is that our current post-commit model
> places a high burden on anyone doing a release. It really does not
> scale and requires often more than a month to review everything. It is
> hard to distribute the workload as the infrastructure doesn't provide
> any help here. The result could be seen with the several hiccups
> during the 220 release.
> Furthermore, we want to avoid miscommunications on bigger feature
> patches that might not make it into upstream. With a pre-commit
> review, we hope to settle discussions before any code makes it into
> git, and save everyone the hassle of reverting patches which maybe
> other projects already relied on.
>
> Regarding the final github address: David Strauss kindly offered the
> 'systemd' user to us. Hence, we hope to move the repository to
> github.com/systemd/systemd this week. Sorry for the confusion, I hope
> we can settle all this this week.
>
> Finally, please speak up if there are any issues. I will do my best to
> address them. We want to tryout github to reduce the burden on the
> maintainers, but to also improve the interactions with outside
> contributions. Feedback is welcome! And to everyone not happy with
> that move, we'd appreciate if you could still give it a try. Lets see
> how it works out!

Will the systemd-commits ML still receive mails when commits are pushed?

It was easy to do post-review of the commits pushed on the repo with
this ML (or maybe there is a github feature that sends mail
notifications when there is commits pushed that I missed).

>
> Thanks
> David