Given that Bitbucket has to spend time on fixing performance problems caused by still using basic auth for their API (rather than allowing multiple, revokable API tokens), I don't have too much hope that they'll get around to fixing the most popular, important issues on their own tracker, e.g. mostly useless (and poorly documented) webhooks: https://bitbucket.org/site/master/issue/7775/post-service-do...

While Bitbucket is popular as a cheap (in every sense) clone of GitHub, in many cases you get what you pay for. Paying for GitHub is worth it in terms of less frustration compared to using Bitbucket in general (plus their webhook/integration support and UI is exemplary), but are other services, such as GitLab, any better?

I started using bitbucket for the private repositories and I have to say, never had a problem... maybe I am not a hardcore user that tries to use the most obscure functionality, far from it. But I find myself fine with it.

Bitbucket works for me, as long all you do is hosting a git repo there. For everything else, I agree that it feels clunkier and generally less polished than GitHub.

Point in case: I tried – and failed – to integrate Bitbucket services through their REST APIs in my upcoming Mac app (“git push assets” for designers - http://gemba.io).

After 2 fruitless days of trying to get an OAuth access token, I gave up. The Bitbucket way of doing OAuth felt weird to me, and the cluttered documentation (which felt a bit like Facebook’s developer documentation 3-4 years ago) didn’t really help.

Doing the same for GitHub was a breeze. OAuth was straightforward, and documentation was unambiguous, concise and clear.

I wouldn't move to GitHub even if it was to provide private repositories for free (which it doesn't). BitBucket just works flawlessly for my needs.

Aside: anyone with a .edu, .ac.uk or other education-ending email address can get 5 private repos for free.

Is there anything specifically about GitHub which puts you off, or is it just that BitBucket works so you don't want to change?

I'll just volunteer that BitBucket has worked flawlessly for me for years. Of course I use repos others have setup in Github, but I've never seen any reason to switch.

> Is there anything specifically about GitHub which puts you off, or is it just that BitBucket works so you don't want to change?

The latter + all the hype surrounding the GitHub (thousands of 10-line "Ruby gems" and "JavaScript frameworks" don't help the browsability either). I generally dislike monopolies of ideas/implementations.

> Is there anything specifically about GitHub which puts you off, or is it just that BitBucket works so you don't want to change?

Github has a much worse record vs. Egor Homakov than Bitbucket :)

Also, Github is Git-only, while Bitbucket supports both Git and Mercurial. I use both, but prefer Mercurial myself, despite it being less popular.

GitHub definitely isn't git-only. It supports SVN too, and can import from SVN, Hg and TFS

>Given that Bitbucket has to spend time on fixing performance problems caused by still using basic auth for their API (rather than allowing multiple, revokable API tokens), I don't have too much hope that they'll get around to fixing the most popular, important issues on their own tracker

To be completely fair, the speaker did mention in the video that it is probably better to migrate to API tokens.

Yeah, I did see that, but it's been ~nine months since the bcrypt change and from what he said, there still aren't any concrete plans to move to API tokens. But then, maybe that's why he said they're hiring!

That is one of many reasons why we are hiring. A dozen people can only do so much and we're looking for smart people with new ideas to help us start accelerating the development of BB.

My experience with GitHub is that the response times are very flaky, whether on a paid plan or not. I've given up on GitHub personally, and will only use it when the project is owned by someone else.

Bitbucket is maybe "cheap in every sense", but it's also reliable.

I've never had that problem. That said, I think it's indicative of bending Git a little too far in the direction of centralisation. But I guess if you depend on issue tracking and/or CI, you have to step that way somewhat.

That webhook ticket is awesome. And by awesome I mean I am in awe of how long such basic functionality has been broken.

That's nothing...

Customers of Atlassian's hosted SaaS service OnDemand (Jira/Confluence) have been waiting 3 years for basic CNAME support. (ie: wiki.companyname.com instead of accountname.atlassian.net)

https://jira.atlassian.com/browse/AOD-6999

Even though it is the most voted for issue, by a factor of three it was closed last week as WONT-FIX.

Shameful - pages upon pages of enterprise customers given the royal f-u.

Yep, shameful. Ooh, I've got another good one: https://jira.atlassian.com/browse/CONF-9993

Basically asking for the ability to turn auto-play off when embedding videos into their wiki product, which seems fair enough because they really hyped their wiki's multimedia power back then.

Ticket opened November 2007, got a bunch of comments and votes, finally fixed in March 2011. Or was it? From August 2011: "This issue shouldn't be closed. I still get this issue in numerous web browsers.", with a follow up in October suggesting it was still broken. No comment from Atlassian, of course.

Whatever else you want to say about Atlassian, their development process is glacial, and their customer communications are very lackluster. It's like a tar pit where good projects go to get preserved in amber.

Can you point me to another company with a public bug tracker that you would reference as the gold standard?

Whilst I know we can always improve (and we always try to), we always end up with some bug that has been open for 5+ years that has the most votes. By definition.

At least with Atlassian you can see the bugs, vote on them, provide comments. If there is another company with this level of transparency that does it better - I'll get in contact to find out how.

Scott, CEO Atlassian

Anyone know why they use two layers of pgbouncer? The speaker mentions this briefly in the Q&A but doesn't go into detail.

Layer one is for connection pooling on the application servers, layer two (on the database server) is mostly for control purposes.