487 karma · joined October 12, 2017
But I agree the bigger challenge than any tooling challenge is getting the team convinced that starting a PR/MR early is not only okay but also the way to operate. Creating physiological safety around it as well as making iteration a part of the day to day workflow is a challenge but an important one.
Note to self: Never say Ruby when you mean Rails on HN
When running "git init" on a fresh install, you also get a hint that the branch name may change. So I think they are still working on changing it to main upstream: https://lore.kernel.org/git/pull.762.git.1605221038.gitgitga...
In addition, you can just assign IAM roles to the runner EC2 instances themselves, placing ALL of the authentication and authorization in AWS rather than in GitLab. Then the runner will only be able to access the things that you allow through its IAM policy.
2.1 Caching isn’t available: GitLab has this everywhere.
2.2 GitHub Enterprise Server is behind GitHub Enterprise Cloud: GitLab ships the same code to GitLab.com as it does to our self-managed customers. This was a tough decision but has a lot of benefits...the central being feature parity and scalability for self-managed folks
2.3 Using Public GitHub.com Actions: This is a symptom more than the problem itself - relying on third-party plugins for build jobs is scary, and leads to many of the same issues we’ve seen in the Jenkins ecosystem - easy to get started, hard to maintain.
2.4 Dockerhub pull rate limiting: for self-hosted runners, you can use a registry mirror or Dependency Proxy to reduce your number of pulls from Docker Hub. The key is the entire platform has to be there to enable the right workflows.
3.1 No dropdowns for manually triggered jobs: GitLab also doesn’t have drop downs, but does have the ability to pre-fill these values.
3.2 Self-hosted runner default labels: I think this is also more of a symptom than a problem. 3.3 Being able to tag and use runners for specific tasks is key - so I understand the frustration and we’ve spent a lot of time on this.
3.4 You can’t restart a single job of a workflow: You can do this with GitLab.
3.5 Slow log output: I haven’t seen this be a problem, and is a benefit of our scalability features being built into the self-managed code.
3.6 You can’t have actions that call other actions: There are lots of ways to relate pipelines (parent/child, triggers. etc.) in GitLab.
3.7 Metrics and observability: The GitLab runner has Prometheus build in, and the dashboards we use to manage GitLab.com are partially public: https://dashboards.gitlab.com
3.8 Workflow YAML Syntax can confusing: This can be really hard to get right. I learned to stop worrying and love the YAML long ago, and I know we’ve got through a lot of iterations to try and get this right.
I'd love to know where folks think I got this assessment wrong. And is there value in writing more about it?
(edited for line spacing)
In GitLab 14.1, we added 91 features to our Core (free) offering, 8 to Premium, and 12 to our Ultimate ($99/user/month) tier.
We're always working to sustain and add to our open source offering while also using our buyer-based open core mythology to select the right tier for features. https://about.gitlab.com/company/stewardship/
More details here: https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-i...
These services have been restored. More information on the root cause can be found in the linked issue.
In addition, my #1 feature I shared was us moving our SAST feature from our paid version to the open source version. We're very proud of the value in our open source version, and are constantly reinvesting in it.
Does that help at all?
Things like family history, patient's history, cycle timing, age, weight, other risk factors all play a role in a smart radiologist making the right decision for that patient. And the pattern recognition on top of that is really hard - it's not just about the pattern you see at a particular spot in an image, it's the whole image in the context of what that looks like. Could ML get better over time with this? Sure...but they've been using CAD in mammography for decades and it still hasn't replaced radiologists at all.
Could a model be made to include those over variables? Sure...but again the complexity of that kind of decision making is something that requires a lot more "intelligence" than any AI or ML system exhibits today and in my mind in the foreseeable future. Just collecting that data in a structured, consistent way is more challenging than people realize.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1665219/
That's been in use for some time. But like many parts of radiology it really only can be a second look tool that as you mentioned proposes alternatives or suggests things. The false positive rate for CAD is substantially higher than for humans because of the human ability to see symmetry and patterns in very diverse tissue sets like one sees in screening mammography.
And the nature of screening tests like mammography means that actually percentages like "89%" isn't really good enough. You have to be more specific and sensitive than that to have a successful program, and I'm not sure that ML will ever be able to get there...there's a lot of experience and human intuition involved at some point that would be hard to replicate...and I know that because people have been trying to do that for decades.
I don't know...but for him to NOW turn it into a cult of personality and sell a fake story about "working hard" is at a minimum disingenuous
My father was an accountant for many years and he always said if you found evidence of fraud you shouldn't be congratulatory because what you found is maybe 10% of what is actually there if you found it by chance.
It started that way for sure, but we’ve evolved with boards, milestones, epics, swim lanes, burn down charts and a lot more.
We have a whole group in our engineering and product org focused on making it even better: https://about.gitlab.com/direction/plan/
What are biggest task management features from Phabricator you don’t find in GitLab?
I've filled an issue with our vendor to try and figure out what's going on with the modal.
There should be the same career progression possible in your QA department as any other engineering department.