Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [4diac-dev] 回复: Foundation Code and Issue services reminder 
Hi,

I would also like to contribute my views on the matter.

First of all, I agree with both Alois and Martin, that we shouldn't expect huge changes in contributions whether we host our code on Gerrit, GitHub, or GitLab. I would like to note, however, that there are also several major open-source projects hosting their code on GitLab, such as CMake (https://gitlab.kitware.com/cmake/cmake), Kde (https://invent.kde.org/), GNOME (https://gitlab.gnome.org/GNOME), Debian (https://salsa.debian.org/), and many more.

In my opinion, both GitHub and GitLab offer roughly the same features, although GitLab offers better integration overall. There are some differences, though.

GitLab offers Epics out of the box (at least in the edition Eclipse is using), while GitLab does so only together with third-party issue management tools.

GitLab also offers Merge trains, a feature that allows to schedule a series of commits for automatic merge given the corresponding pipelines succeed [1]. A similar feature is currently only in limited beta on GitHub and only supported together with GitHub Actions [2].

The most significant difference, however, lies in the development workflow, particularly evident in the distinction between Merge Requests (GitLab) and Pull Requests (GitHub). On GitHub, it is common for developers to create a fork of the project's upstream repository and contribute from there via Pull Requests. This is therefore well suited to many independent developers making few contributions each, as is common with many open-source projects. Looking at the recent commit history of 4diac, however, this is simply not the case. On the contrary, virtually all contributions are made by a core group of developers working closely together.

With GitLab, on the other hand, developers often work closely together in a common repository, much like how it has been with Gerrit. This would also allow the project maintainers or co-developers to more easily and frequently give feedback or even help out directly if changes are developed alongside upstream code in the same repository. It would further enable contributors to seamlessly use common infrastructure provided by the project, such as CI/CD pipelines.

In summary, considering both the developer base and the development workflows currently used within 4diac, I believe GitLab to be the better choice.

Best regards,
Martin

[1] https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html
[2] https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue


On 23/03/2022 13.27, Alois Zoitl wrote:

Hi,

I think no one of us is so naive thinking putting stuff on certain platform magically increasing contributions. However as Github is so popular much more people
know how to use it. This is great difference to previous forges like Sourceforge. This has the chance that people who wanted to do small fixes more probably
submit them because it is easier for them as they are already used to process.

There are Eclipse projects out there telling contributions increased after moving to Github. This was then also a key reason why the Eclipse Platform decided to
move the Github.

But our mileage may vary.

For me it is important we choose what fits our community best and where we can work efficiently.

For Github please also keep in mind that it will be a project under the Umbrella of the Eclipse Foundation with the Eclipse rules already enforced. Especially
the later is for me important as it reduces the effort managing contributions.

My 2 cents on that.

BR,
Alois


On Wed, 2022-03-23 at 09:16 +0000, Martin Melik-Merkumians wrote:

Hi,
Locating the source code on Github does not ensure more contributions. Same holds true for Sourceforge, which was THE BIG THING long before GitHub 
I have a different project there, so I have some experience in that😃
GitHub and GitLab offer a quite similar set of features, but using dedicated Eclipse infrastructure will most likely make the work of contributors and project 
lead easier, than also dealing with a third involved party (GitHub/Microsoft) in case of troubles.
My 2 cents on that. Best regards, 
Martin
-------------------------------------------------- 
Dipl.-Ing. Martin Melik-Merkumians
Advanced Mechatronic Systems
Automation and Control Institute (ACIN)
TU Wien
DVR-Number: 0005886
Gusshausstr.27-29, room CD-04-24 
1040 Vienna, Austria
Phone: +43 (0)1 588 01 37688
Fax: +43 (0)1 588 01 937688
Email:melik-merkumians@xxxxxxxxxxxxxxxxx
http://www.acin.tuwien.ac.at/
--------------------------------------------------
Von: 4diac-dev <4diac-dev-bounces@xxxxxxxxxxx>Im Auftrag von zhaoxin@xxxxxxxxxxxxxxxxx 
Gesendet: Mittwoch, 23. März 2022 10:09
An: '4diac developer discussions' <4diac-dev@xxxxxxxxxxx>
Betreff: [4diac-dev] 回复: Foundation Code and Issue services reminder
Yes, I agree with Fabio. Regards 
Tibalt
发件人:4diac-dev-bounces@xxxxxxxxxxx <4diac-dev-bounces@xxxxxxxxxxx>代表Fabio Gandolfi 
发送时间: 2022年3月23日 17:05
收件人:4diac-dev@xxxxxxxxxxx
主题: Re: [4diac-dev] Foundation Code and Issue services reminder
Hi all, 
In my opinion if you want more people to contribute on 4diac as a open source project Github is the way to go because it has a big open source community.
Best regards, 
Fabio


On Tue, 2022-03-22 at 13:36, alois.zoitl@xxxxxx wrote:

Dear Friends of 4diac,
the long anticipated step of migrating from the current setup to a more modern is now here. Both options have quite some advantages. As I'm happy with both options I wanted to ask you the 4diac community what option you would prefer? Cheers, 
Alois
On Mon, 2022-03-14 at 10:25 -0400, webmaster@xxxxxxxxxxxxxxxxxxxxxx wrote: 
Hi Everyone,

You may not be aware but the Webmaster team has started the process of deprecating our current Gerrit[1] and Bugzilla[2] instances. We'd like to encourage
your project to discuss moving sooner rather than later to avoid migrations done against a specific timeline.

Your migration options are either the Foundation’s hosted GitLab instance [3] or our presence on GitHub[4]. Both options provide a more integrated tool
set (code, issues, wiki and discussions (GitHub only)) rather than our current disparate tool set.

Continuous integration with Jenkins works well for both options, and will be our focus for the foreseeable future. For GitLab we’re also investigating the
possibilities of using GitLab CI which is similar to GitHub actions, and could be used for features like dependency checks or GitLab pages.

You can start your move by filing an issue[5] letting us know where (GitLab/GitHub) and when you'd like to move, and we'll do our best to make it happen.

Do you have questions? Check out some of our documentation[6], or a comparison[7] to help you choose. You can also write to Webmaster, and our team will
do it's best to find an answer.

-Matt.

[1] https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/680
[2] https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/679
[3] https://gitlab.eclipse.org
[4] https://github.com/eclipse
[5] https://gitlab.eclipse.org/eclipsefdn/helpdesk
[6] https://wiki.eclipse.org/Gitlab#Migrating_from_Gerrit_and_Bugzilla
[7] https://spectralops.io/blog/github-vs-gitlab/
_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
_______________________________________________ 
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev


_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev


--
Martin Erich Jobst, M.Sc.
Computer Scientist

mailto:martin.jobst@xxxxxxxxx

Back to the top