521–530 of 567 posts
Earlier quoted context omitted.
If you pay everyone equally, I don't think I'd want to work there.
Maybe it isn't a thing wherever you are but here: we pay and treat everyone equally and equitably. ... means that we do not discriminate unfairly. Do I really need to spell it out?
Earlier quoted context omitted.
The list of key MS acquisitions isn't that long and out of several products only Nokia is a definite failure. Skype gotten worse but I wouldn't count it as failure just yet. Remaining big acquisitions (Forethought PowerPoint, Hotmail, Visio, Navision Dynamics, LinkedIn) where rather successful.
Success for Microsoft doesn't mean success for the users of the acquired product, e.g. Skype users on Linux, and anyone using RoboVM.
Really hope these talks fall through and nothing comes of it. Too many bad experiences with Microsoft buying something out, mismanaging it, and it goes down the drain. As much as I love GitHub, I won't be using a Microsoft-owned GitHub for any of my company's work.
GitHub clearly needs change of management. I havent seen much inmovation from them compared to GitLab. Microsoft is very strong on innovation since change of management.
Many people mention Microsoft's past history as reasons for worrying about this. However, I disagree. I don't think this would be bad because it's Microsoft. I think it would be bad because GitHub wouldn't be a generally independent entity, with no business interests besides making a product good enough that people will pay for it anymore. Currently, GitHub doesn't really have any incentive to care what tools and pla…
This is what I was thinking also (though you articulated it much better than I would have). A large company doesn't make an acquisition like this without a business incentive. For them, it's driving people to their products. Maybe making the tooling in github for interacting with microsoft-y products a little bit better. Maybe adding whatever licenses microsoft likes to the front of the default licenses you can pick…
Seems like the view here is pretty negative. I feel like most people here haven't worked with Microsoft dev products recently. They're getting better. I guess the crowd here isn't typically in the .NET world.
I constantly remind myself that HN does not actually represent what most customers want and/or need in the real world. Most routine jobs/contracts at the coalface are still Java/.NET (possibly with a bit of Kotlin thrown in) - I even see companies looking for PHP developers on a weekly basis. They are definitely alive and kicking, though if you judged based on this website alone, they all ceased to exist 10 years, re…
I can't help but be insanely sceptical. Microsoft has a massive legacy of Embrace, Extend, Extinguish and I don't want the GitHub ecosystem to suffer from the same reoccurring pattern. Call me jaded by Microsoft's past behaviour, but I just cannot forget the numerous times Microsoft has absolutely ruined thriving ecosystems by using the same tricks.
Earlier quoted context omitted.
I don't trust them to be compent at operating a large scale service after their insane meltdown february last year. https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
Unrelated to that incident, but I feel their web UI to be extremely slow lately. Working with PRs (or "merge requests" as GitLab calls them) and CI pipeline is a pain, you're looking at 1 second response times.
Earlier quoted context omitted.
Some of us are old enough to remember Microsoft of the 90's and early aughties. "Embrace, Extend, Extinguish" was the name of the game then, many of us haven't forgiven Microsoft for that yet (and nor do we plan to).
Right, I know that, and that's just idiotic behavior. You should concentrate on what is happening today, not what happened decades ago and hold grudges. That attitude leads you into unhappy places.
Earlier quoted context omitted.
Unrelated to that incident, but I feel their web UI to be extremely slow lately. Working with PRs (or "merge requests" as GitLab calls them) and CI pipeline is a pain, you're looking at 1 second response times.
We're not happy with the merge request speed either. We're close to converting the merge request view to Vue, this should speed it up considerably.
I don't know if it's an optimisation issue with the software itself, or if it's just GitLab.com being overloaded..
Earlier quoted context omitted.
Well that's the beauty of git, as long as anyone anywhere has a checkout of the Repository nothing will be lost. If tags are GPG signed you don't even have to put any trust in the surviveing source. That said for mantained code 99.9% of the time you would just use one of the core develops local copies.
Except for issues and pull request metadata, which are important part of the project knowledge.