611–620 of 662 posts
Earlier quoted context omitted.
For a 50 person group, $430 is peanuts, it's just peanuts. I'm sorry, I just don't feel for these people, this is getting upset about the $0.10 charge for butter when you paid $10.00 for the popcorn.
Yeah, who cares if they hiked the prices up by an insane amount, right? /s
The incentive changes for this are so massive, nice "experiment" from an economics perspective. 1. penalizes OpenSource organizations that need a few private repos for password, server configuration or other things. Was 25$ before, now for example Doctrine with 48 collaborators it would be 394$. Even if just the admins have access to that repository. 2. penalizes collaboration, inviting every non-technical person in…
> These users do not fill a seat: Outside collaborators with access to only public repositories
https://github.com/blog/2164-introducing-unlimited-private-r...
Earlier quoted context omitted.
I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"? But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build su…
Gitlab has the ability to do that. http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....
This is way too expensive! Self-hosted GitLab is cheaper and has better uptime! Not to mention, they should have made you pay only for users with commit rights!
Only if you assign no value to your own time, and assume you can do a better job with availability and durability than a dedicated Operations team and a multi-million dollar budget.
Earlier quoted context omitted.
I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"? But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build su…
I agree, especially when all you really want to do is make a small change. (I'm less likely to contribute then - preferring to open an issue and nag someone on the team/who already has a fork to implement my one-liner!) But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork. It needs to wor…
This would be so much easier than the pull-request dance that I bet it would lead to a lot of simple fixes or improvements being contributed by people who otherwise wouldn't get involved at all. Those have value in themselves - but it would also go a long way toward helping recruit new project members, if people could dip their toes in easily before having to go through all the mumbo-jumbo of a private fork and configuring the upstream and all that.
Earlier quoted context omitted.
I've used Bitbucket in the past. They charge per-user[1], and their pricing is significantly better free for 5 users and then once you eclipse 5 users it's $1/user up to 100 users and then $200 for unlimited users. [1] - https://bitbucket.org/product/pricing
This. I use bitbucket too and I can't understand why people are still paying github when bitbucket does exactly the same and is free.
GitHub is actually painfully slow too; just not as slow.
That's the main reason I pay GitHub and use them for those projects where I need something more than just a git server for collaboration.
Earlier quoted context omitted.
I've used Bitbucket in the past. They charge per-user[1], and their pricing is significantly better free for 5 users and then once you eclipse 5 users it's $1/user up to 100 users and then $200 for unlimited users. [1] - https://bitbucket.org/product/pricing
This. I use bitbucket too and I can't understand why people are still paying github when bitbucket does exactly the same and is free.
GitHub is actually painfully slow too; just not as slow.
That's the main reason I pay GitHub and use them for those projects where I need something more than just a git server for collaboration.
Earlier quoted context omitted.
How could we convince you that at GitLab we take security very seriously?
Creating a Security page on the site to explain your infosec policies would go a long way. I like that we're able to view previous disclosures [1] and active security issues [2], but I had to dig a bit to find them. Surface those. [1] https://about.gitlab.com/vulnerability-acknowledgements/ [2] https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B...
Anyway, I've added most information to https://about.gitlab.com/disclosure/ with https://gitlab.com/gitlab-com/www-gitlab-com/commit/eab7e345...
That page is linked from https://about.gitlab.com/contact/
Earlier quoted context omitted.
How could we convince you that at GitLab we take security very seriously?
Make a dedicated site on gitlab.com about security (make it bold) and about private repos. Some buzzwords: Countermeasures, security tracking, rate limiting, DDoS attacks, Backups... what do you do to ensure security, privacy or that nothing is lost? It's a littlebit in the dark. I would love to see comparisons between gitlab, bitbucket and github if possible (but I'm guessing that's not easy) or I would love to see…
We try to achieve a good reputation by taking security seriously every day and being responsive to disclosures.