Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear GitHub

github.com

Post reply on HN
Print view View original

361–370 of 491 posts

Re: Dear GitHub

#361

Post by jacalata »

simoncion wrote: post #251
pvorb wrote: post #136

Earlier quoted context omitted.

That's why you shouldn't use Google Docs for such an article (even if it comes in the form of a letter). Nobody expects the concept of pages on the web (as in books, not as in web page).

Comments like these baffle me and I have to wonder * Are "we" in such a huge hurry that we don't look at our scrollbar to see if there's more to the document that we're viewing? * How did "we" get so incurious that we don't even attempt to scroll down to see if there's more information to read? I mean -seriously- the intended audience for this particular open letter is technical people .

Did you....not read the open letter? Or not realize that the scrollbar for this one goes all the way to the end of the page, and then there's an inline link saying 'see more signatures'?

Re: Dear GitHub

#362

Post by sytse »

pvorb wrote: post #338
sytse wrote: post #325

Earlier quoted context omitted.

We would love for Travis CI to offer support for GitLab, they can use our new commit status API. But you'll find that GitLab CI is a pretty complete replacement. If you don't want to use a shared runner you indeed have to use a shared runner. Running on your local machine can indeed include your notebook.

Thanks for the answer.

Welcome. I see an error in my answer. If you don't want to use a shared runner you indeed have to add one yourself. Please be informed that shared runners can run Docker images and that we plan to add runner auto scaling with 8.4 to reduce the queue.

Re: Dear GitHub

#363

Post by jondubois »

joncalhoun wrote: post #90
jondubois wrote: post #54

I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems. I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.…

Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it. I don't think the authors are requesting that this be made mandatory f…

My project's main repo has 150 issues (only 7 still open) and it works out pretty well. Usually contributors will answer each other's questions and help close issues.

I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub. Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?

Re: Dear GitHub

#364

Post by jondubois »

rco8786 wrote: post #64
jondubois wrote: post #54

I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems. I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.…

The request was to allow maintainers to define a template or have the ability to add fields. So the formats would be on a project by project basis. > Maybe if your software was better designed, people wouldn't be asking the question to begin with. This is just silly.

Not so. For my project, I noticed on several occasions that different people were asking the same questions and that prompted me to rethink the design of the project a bit and it greatly improved the community engagement as a result.

Re: Dear GitHub

#365

Post by simoncion »

jacalata wrote: post #361
simoncion wrote: post #251

Earlier quoted context omitted.

Comments like these baffle me and I have to wonder * Are "we" in such a huge hurry that we don't look at our scrollbar to see if there's more to the document that we're viewing? * How did "we" get so incurious that we don't even attempt to scroll down to see if there's more information to read? I mean -seriously- the intended audience for this particular open letter is technical people .

Did you....not read the open letter? Or not realize that the scrollbar for this one goes all the way to the end of the page, and then there's an inline link saying 'see more signatures'?

When I read the letter, I saw that it extended across two printed pages. Were these printed pages not the pages to which pvorb was referring to?

After re-checking the link:

Ah! See, the document that you are looking at is hosted on Github. At the time of my comment (~six hours ago), it was a two-printed-page document hosted on Google Docs. dang comments here: https://news.ycombinator.com/item?id=10907271 (four hours ago) that he changed the link from the Google Docs document to the Github document.

(And now that I know that, the wave of downvoting makes a lot of sense. (even though pvorb explicitly says that he's looking at a document hosted on Google Docs))

Re: Dear GitHub

#366

Post by justincormack »

notabot wrote: post #196

My company pays me to work on a fairly old-school free software project and we run our own git service. Our workflow is email based so we won't ever consider switching to GitHub. That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is…

FreeBSD has worked out a means of accepting pull requests on their github mirror, guessing using the API.

Re: Dear GitHub

#367

Post by kbart »

slavik81 wrote: post #346
kbart wrote: post #345

Earlier quoted context omitted.

Agree. I've had literary thousands of libs/tools/apps dependencies in one of my projects that was built using automatic tools (Bitbake + Yocto). It's simply impractical to go through all these README's manually, so a tool to detect depreciated projects is a must in such situations. Of course, one could implement some tool to scan all README files for keywords ('DEPRECIATED', 'UNMAINTAINABLE' etc.), but that's just a…

What if the maintainer never marks the library as deprecated? What if they're just hit by a bus? I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many. Whoever decided it was OK to depend on that library should be able to follow it closely enough to say when it cannot be depended on.

"What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?"

There are a lot of "if's" and many things might go wrong -- there's almost never 100% guarantee, but every mean that makes end product more reliable is a good idea.

"I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many."

Such number of dependencies is common when building custom Kernel/OS + application. Also, I've never mentioned direct dependencies, some are just tools to build tools. It wasn't event that big of a project -- a relatively small (~150 Mb) custom OS with Qt application for an embedded device.

Re: Dear GitHub

#368

Post by progx »

peterfpf wrote: post #243
krschultz wrote: post #130

Earlier quoted context omitted.

An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request. My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other…

I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed. Another good example is harthur's "[UNMAINTAINED]" [1] [1] https://github.com/harthur/brain

I watch the project and did not see "UNMAINTAINED", cause i scroll automatically on github projects down to the readme.

I search and then i see it in the title.

Better would be an Option in Github to set a project to unmaintained or deprecated, with an optional link to the new project (if some exist).

Github could then change the background color from white to an other color or add a border around the page, so that it is really obvious that this project es EOL.

Re: Dear GitHub

#369

Post by haynes »

pvorb wrote: post #169
pvorb wrote: post #125

The problem is that GitHub has a monopoly and is considered _the_ current standard for Open Source. But I think that once some of the major projects move to alternatives like GitLab (which has many of the features described in that letter) GitHub will have to obey its user base. Unfortunately no Open Source project with a large user base will dare to do the first step.

I went ahead and created an account on GitLab.com. So far I can tell the transition is seamless. You can import a repository from GitHub with only a few clicks. Issues will be inherited, but the single PR on the repo I tried to migrate got lost on the way.

Importing Pull Requests will be possible with the next version of gitlab that's going to be released on the 22nd january. See this MR for more information: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2168

Re: Dear GitHub

#370

Post by felhr »

I just created and maintain a little Android library (a very rewarding experience by the way) so most of the complaints about Github doesnt really apply to me because the size and reach of my project (I understand the point perfectly though).

But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have to deal with. This is what I've found:

- People with little to zero experience in the language/framework that simply state that my project doesn't work without providing more information and sometimes they didn't reply to my "give me more info" inquiries.

- Guys who just want to get their homework done and They are basically trying to get it done using me as non-paid freelance.

- And my favourite one, junior dev in a company, he needs to get their work done with more pressure than the previous one so became anxious about their problems and I feel it even via email. Eventually He gets the thing done but He notices I changed the build system to Jitpack for better dependency handling and and start to complain about Man in the middle attacks to his company and black-hat hackers replacing my lib with a malicious one (I guess it could happen but come on).

But it is a very rewarding experience besides these anecdotical cases

Post reply on HN