Recent comments

It's all fine to hope that Github will never disappear, but the fact remains that it may for some reason

Just to add to this: we don't have to worry about Github just disappearing, but also taking Github in a direction that's incompatible (or just interferes) with how Drupal and its contributors work.

At least with a Free software tool, like Gitlab, we can exercise some control over it with patches (or even participate in a fork, if necessary).

let's raise more awareness and really schedule the move, is all that people want really, no politics please!

I take exception to this framing of the discussion in a way that precludes talking politics.

I know we all love to be jaded about it, but politics is important. The difference between living in a dictatorship and a modern bourgeois democracy is politics, moreover my reasons for disliking GitHub aren't really technical but boil down to politics: I dislike the idea of taking (some) control of the way Drupal is developed away from the pro-Drupal, non-profit, free software based organisation we have now and moving it to a not necessarily pro-Drupal, for profit, proprietary based organisation.

Personally, I don't find the arguments very convincing. For a start they are just personal preferences followed by the supposition about 'fear of change', I also use GitHub every day (for some private contracts) so the 'fear of change' argument doesn't really wash, it's also pretty rude to assume that's what people's problems with Github are.

Why would I be forced to create an account on Github and hand over all my data to an external entity (obviously I am not talking about the code itself here, but about one's profile, activity, etc), when all I want is to contribute on drupal.org? If you really want to use PR, why would you need an external centralised platform, when it is actually a matter of adding a remote? (Even though I am personally fine with our current patch workflow).

If the community believes we need more specific tools, I prefer self-hosted ones like Gitlab.

Honestly from the comments of the critical people, Gitlab is likely the better match. Do however note that its written in Ruby and they may need to do a bit of tweaking to handle the Drupal scale. But it should bring many of the benefits of Github with more control over the hosting and code. BTW with git anybody can choose to collaborate on other platforms anyway.

there are dependencies yes, but they are solvable. Code in a business is stored safely if it is important. I mean production code. An open source project can rely on a good third party service from which it will profit in collaboration, tradeoff that is far advantageous.

the problems you are trying to make are already solved by all other businesses relying on github, via mirrors and inhouse if needed enterprise edition or others. It is nothing new, those arguments have been dealt with. Drupal is not the only project. Yes is big and all but it is not the only one.

We don't need to reinvent the wheel, Drupal reuses code, like Symfony, like shell, like mysql, no need to have Drupal reinvent a database system, a shell terminal, etc etc, nor distributing and collaborating software like github either.

The case is extremely weak, imo is no case.

it is not honest not serious to deal with what ifs in that manner. what if google disappears! yes we can be even prepared for that. we just have mirrors into other third parties? an example

On the contrary, what ifs need to be dealt with, and contingency plans need to be made. This is the proper/professional way of dealing with large projects like this. It's all fine to hope that Github will never disappear, but the fact remains that it may for some reason.

Now that said, your idea of having alternate mirrors sounds like an acceptable solution to the problem. This of course increases the complexity of the issue however, as we will need to ensure that the mirrors contain the updated code, and that switches exist to pull from the mirrors.

this is typical response from an insider, not trying to insult or anything, but the propaganda of drupal sometimes get in the way, we are big, nobody will be able to handle us, we conquer the world with millions of websites, when in reality is ok, but it is not that we cannot use github normally like the rest of the planet

This does not address the issue. The issue is that by using a 3rd party service, we are at the mercy of that 3rd party service. If we can get some sort of guarantee out of them, or have a backup plan of some sort, then the point becomes moot. But without a guarantee or a backup plan, using a 3rd party service is not reasonable.

the advertisement is clear, drupal should be a CMF, be good at that, not at maintaining legacy code that deters its advancement

1) The legacy code does not deter advancement. We've advanced this far with our current code.
2) We don't need to keep legacy code, we can write our own code that does whatever we need.

We should be focusing on making our own system work the way we want, not relying on 3rd parties.

let me deal with your points one by one

1. it is not honest not serious to deal with what ifs in that manner. what if google disappears! yes we can be even prepared for that. we just have mirrors into other third parties? an example

2. this is typical response from an insider, not trying to insult or anything, but the propaganda of drupal sometimes get in the way, we are big, nobody will be able to handle us, we conquer the world with millions of websites, when in reality is ok, but it is not that we cannot use github normally like the rest of the planet

3. the advertisement is clear, drupal should be a CMF, be good at that, not at maintaining legacy code that deters its advancement

Again as i have been saying all along, I have dealt with those excuses and there is no grounds or case.

let's raise more awareness and really schedule the move, is all that people want really, no politics please!

I don't want this. I think it's a bad idea - we should be improving Drupal.org if there are problems, not moving into a 3rd party service. There are three primary reasons for this:

1) What happens if github disappears someday? It's not likely, but it wouldn't be the first time a big company crashed.
2) If/when github goes down with technical issues, we are at their mercy as to when they get the issues fixed. If they take a week, then we all have nothing to do but wait for a week, hoping that they get it fixed ASAP. For those of us who are developing with Drupal for our companies, being at the mercy of a 3rd party is not an acceptable risk.
3) Drupal related projects/issues etc should remain on Drupal.org. What kind of advertisement is it for Drupal if we cannot even build infrastructure on Drupal to handle the things it needs? It would be like going to Microsoft to download Apple updates.

yes you can

the process is explained on the link i provided but i can repeat it

git is distributed so you can fork and have a branch in which you merge both works yours and the one you are trying to merge into. Also you can send a PR without having to wait, with the former changes to the main repo or to the fork of the other person you are collaborating.

In addition and further superior you can have guidelines for patches if you want to still do them on a github thread. This I have seen done often. However the commenting on code feature is so powerful that it either is a comment or a PR to a submitted PR that solves it.

Further you can do a gist. Do the example and link to it very quickly.

I think is more about educating people. It is like living in the past and clinging to the past in things that honestly have no excuse.

kind regards, you guys know a lot, but i suggest please you review this carefully