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…
Announcing new tools, forums, and features
211–220 of 282 posts
Re: Announcing new tools, forums, and features
#212Re: Announcing new tools, forums, and features
#213Earlier quoted context omitted.
Take a look at Phabricator. It's a former Facebook project and been battle-tested at very large companies for years now. Huge open source projects like Blender, Haskell, Wikimedia and LLVM use it since it's the best open source code review tool and issue tracker. Wikimedia had a lengthy decision process and thoroughly vetted the alternatives. It has many enterprise features including code ownership, issue templates,…
I'm evaluating GitLab at work currently - primarily for its code review features and really like it. Read a lot about Phabricator yesterday as a possible alternative, and am considering testing it. I wonder how it compares to GitLab. Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch? Can I do a code review and then finalize it when I'm finished a…
Yes. I recommend (and my employer uses) a Herald rule that admits pushes to master only if the changes are in an approved Diff (unit of code review). This way you get an enforced 2-man rule, but anyone besides the author can approve the change.
This is currently impossible with Gitlab AFAIK, and is the main reason I won't use it.
You can also configure Herald rules to add blocking reviewers to other people's Diffs based on arbitrary criteria (i.e. touches X file and it's a Tuesday). A Diff cannot be considered approved until all blocking reviewers have signed off.
Reviewers can also be groups, so you could say, for example, changes that touch Y file must be reviewed by Security, but any member of Security can sign off.
>Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature?
Yes, everything you do on a Diff is batched and happens all at once when you click "Submit" at the bottom. Inline comments, the free-form text box, and the action all come as one email.
> What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
A Diff is really meant to be an individual's small, well-defined contribution. Multiple people submitting code to a one diff can get messy. This would be better modeled as many diffs.
You are allowed to land diffs against branches other than Master, however this gets messy. It is not a first-class use case. My employer does not collaborate on feature branches; instead we land half-finished features into master (and production) disabled by feature flags.
It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).
>Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello.
Issue tracking is totally solid, very configurable. Project workboards consist of tasks/issues, which are much more expensive to create than Trello cards: you fill out a pagelong form, pick type, severity, owning team, title, description, etc. vs just free-forming a title. However, you can drag tasks around the workboard just like Trello and it looks pretty similar.
>Can it be used by non-developers without giving them access to the code?
Yes. Permissions (and approval flows, and notification rules) are very configurable. Phabricator is well suited to a large organization with rules, but this suitability doesn't carry too much overheard.
I don't think you could collaborate on issues with customers. Nontechnical people in your company, though, totally - we do that.
Re: Announcing new tools, forums, and features
#214The main selling point of github is that companies can track what their developers are doing in great detail.
And all you people are hooraying them - "YES, we want to obey! We love to live in chains! We do not care for the crazy guys that talk about that stupid freedom thing!"
Maybe in a company project that kind of extreme privacy destruction is ok, when a well paid developer agrees to be monitored in such an extreme way.
But it is definitely not ok to make this the default and to not give you control over it.
Totally absurd that people made that site the new opensource mekka.
This could be only topped by something that would be really crazy, like e.g. if they had not an actual issue tracker for the product itself. Or, even more bizarr, if the product was not open source itself... oh, wait...
We lost a whole generation of develpers that do not even think about these kind of things and are completely ok with that extreme level of tracking and do not mind that they are hurting people that care.
Post-Snowden reality is almost surreal. Too many sheepminded followers.
Re: Announcing new tools, forums, and features
#215Earlier quoted context omitted.
I think particularly here on HN, I've seen a good deal of concern over github's social agenda and the perception that they've hired a lot of non-engineering folks to push that agenda.
I've only seen that among members of the alt-right.
It's always disappointing to see a self-described intellectual community give over so heavily to such an obviously broken thought process, but humans being the emotionally manipulable creatures they are, it makes sense.
Re: Announcing new tools, forums, and features
#216I'll be curious to see if they've made API granularity more sane. We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing…
Re: Announcing new tools, forums, and features
#217Earlier quoted context omitted.
I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project https://confluence.atlassian.com/bitbucket/projects-79249795... We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group lev…
> In BitBucket you have multiple repositories under one project however, unless i'm missing something, a "project" in bitbucket is basically just a folder to group your repositories in. there's no real features associated with it. A github project is project management tools based on a repository. If GitHub had called their feature something else, (for example, call it "the board") and nobody would be expecting it to…
In the future you will see us adding more capabilities to projects, such as permission management [1] or settings on a project level, which already exist in Bitbucket Server.
[1]https://confluence.atlassian.com/display/BitbucketServer/Usi...
Re: Announcing new tools, forums, and features
#218Earlier quoted context omitted.
I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project https://confluence.atlassian.com/bitbucket/projects-79249795... We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group lev…
Meta-comment: As a founder and engineer, I used to give a lot of shit to Social Media as a growth channel. GitLab staff are "on point" by commenting on anything relevant to their industry (code creation/management) where their target customers are (HN). To other founders, this is what good marketing looks like.
Re: Announcing new tools, forums, and features
#219Earlier quoted context omitted.
I think it was more the open letter to Github, which motivated both Github and GitLab (seen as an opportunity to compete). GitLab's roadmap yesterday surely didn't motivate or spawn the "New GitHub Universe," and I wouldn't think that Github is very nervous about GitLab currently due to it's massive lead in the market. Maybe this new round of funding made some of the folks at Github look over at Gitlab, but I doubt t…
> I wouldn't think that Github is very nervous about GitLab Just my 2 cents, but I think they very well should be
Re: Announcing new tools, forums, and features
#220This 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…
I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.