Live data from Hacker News

Announcing new tools, forums, and features

github.com

271–280 of 282 posts

Re: Announcing new tools, forums, and features

#271
post #253

Earlier quoted context omitted.

No-one said it was. But the answer of self-hosting is a perfectly valid answer for "Why the love for GitLab?" when one = $0 in licensing, and the other = > $2,500/year in licensing.

so basically, you like it because it's free. doesn't speak well for their business prospects.

Actually, we pay for GitLab EE.

GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).

Re: Announcing new tools, forums, and features

#272

This is a rough summary of what all I read in the blog post: 1. projects. replaces trello, waffle.io, zenhub and many other similar services. 2. code reviews allow approval/request changes as sunny's screenshot shows 3. reviews can be made mandatory. 4. github platform integrations is getting a roadmap 5. a graphql api to query their database 6. enforce 2fa in organizations (much love for this one) 7. summarized time…

re: enforced 2FA, it does not appear to play well with bot accounts -- it's either all on or all off, and bots don't count as using 2FA.

Re: Announcing new tools, forums, and features

#273

Earlier quoted context omitted.

One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?

> One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager,…

I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ...

Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together.

And your problem of searching for issues assigned to one person across multiple repos is not a problem any more.

There are already many good examples of managing multiple modules inside one repo:

https://github.com/apache/thrift

https://github.com/rails/rails

Re: Announcing new tools, forums, and features

#274

This is a rough summary of what all I read in the blog post: 1. projects. replaces trello, waffle.io, zenhub and many other similar services. 2. code reviews allow approval/request changes as sunny's screenshot shows 3. reviews can be made mandatory. 4. github platform integrations is getting a roadmap 5. a graphql api to query their database 6. enforce 2fa in organizations (much love for this one) 7. summarized time…

I thought the stuff about Github's pace was funny too. People have short memories, I guess.

Re: Announcing new tools, forums, and features

#275
post #225

This is a rough summary of what all I read in the blog post: 1. projects. replaces trello, waffle.io, zenhub and many other similar services. 2. code reviews allow approval/request changes as sunny's screenshot shows 3. reviews can be made mandatory. 4. github platform integrations is getting a roadmap 5. a graphql api to query their database 6. enforce 2fa in organizations (much love for this one) 7. summarized time…

This all seems like baby stuff compared to Atlassian though. JIRA, Confluence, Bitbucket, HipChat. That's hard to beat.

If Atlassian's competition is baby stuff, give me a pacifier and a bottle.

Re: Announcing new tools, forums, and features

#276
post #258
post #257

Earlier quoted context omitted.

Objectively, that's such an odd thing to be unsettled about. Have we reached a point where all pleasing tones are considered marketing and PR? That we distrust people for acting earnestly? It's in gitlabs best interests to be a superior product, right now they're an underdog, and their ubiquity on hackernews is not a coincidence, they're a YCombinator backed start-up. Talking directly to people tends to focus the con…

I fully admit that I'm a cynical and cranky bastard.

At least you're polite and well-spoken.

Re: Announcing new tools, forums, and features

#277
post #225

Earlier quoted context omitted.

This all seems like baby stuff compared to Atlassian though. JIRA, Confluence, Bitbucket, HipChat. That's hard to beat.

> baby stuff JIRA doesn't support markdown. That seems like baby stuff to me.

It does. For years.

Re: Announcing new tools, forums, and features

#278
post #253

Earlier quoted context omitted.

so basically, you like it because it's free. doesn't speak well for their business prospects.

Actually, we pay for GitLab EE. GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).

Ok, so change "free" to "cheaper", and the point remains: you like it because they charge less.

Still, most people in HN threads use it because it's free. Which is great for an open source tool, but bad for an unprofitable, VC-funded startup.

Re: Announcing new tools, forums, and features

#280

This is the example of how hard it can be for companies, especially successful companies, to alter their course even slightly. Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository. This is b…

One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?

Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.
Post reply on HN