7 ms·

I complain every 6 months about their "releases" page - eg this one for my project https://github.com/rogerbinns/apsw/releases https://github.com/rogerbinns/aps

I complain every 6 months about their "releases" page - eg this one for my project https://github.com/rogerbinns/apsw/releases https://github.com/rogerbinns/apsw/releases They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. But the repository is in a maintainer state, so the "Source Code" isn't useful to an end user because various tools need to be run (eg building help, automake/autoconf, dependencies). The people mislead by Github due to this "Source Code" contact me, not github. Every six months for several years, I send the email explaining how this doesn't serve anyone's interest, how it hurts, and that I am happy with any solution (eg don't auto add, change the name to make it clear, be able to label an existing file as the "Source Code" etc). I get the usual response of understanding and sympathy, and vague suggestion that it may be addressed. Three years and counting ...

deleted 11y ago
[deleted]
wnevets 11y ago
>They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. I fall for this everytime I go to use that link.
- danielweber 11y ago
  The people who dogfood Github, by using it every day, know how to get around places. The people who is it once every week or two, like me, get lost each time. It's always a hunt when I want to figure out how to do something, even if I know I've done it before.
  - haberman 11y ago
    Totally agree. A few examples for me: - From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?). - At the top level of a repo (ie https://github.com/google/protobuf https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History". - continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmarks/ProtoBench.java https://github.com/google/protobuf/blob/master/benchmarks/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.
  - ValentineC 11y ago
    I'm wondering what's a good way for a dogfooding company to look at things from a fresh perspective. Perhaps the traditional focus group and user interaction studies?
    - hussong 11y ago
      Listen closely to anything new team members have to say. From the inside, it all makes sense, but from the outside, it's often obvious insanity ;-)
Sir_Cmpwn 11y ago
I also have a problem with the "download zip" button on repositories. It doesn't include submodules. I've asked Github several times to give me a button to remove it from my repo, or to add submodules, to no avail.
- rogerbinns 11y ago
  I'll bet they have zero positive feedback over the Source Code zip, and you confirm yet more negative feedback over it.
  - morgante 11y ago
    I like having it as a simple way to quickly download a git-free tree of simple projects. So there's one small piece of positive feedback.
    - kevin_thibedeau 11y ago
      It's also immensely useful for installers like pip that can pull an archive directly from Github using just a URL and no local git install.
      - rogerbinns 11y ago
        This issue is not about tools, but about humans being confused by the releases page. I have no problem with an archive of the repository being available - the issue is that github ui on the release page implies that is the best download to build and install the software, when it can be the least convenient hardest way.
    - rogerbinns 11y ago
      You can already get such an archive by clicking on the right bit of the release page. And I believe at any page reflecting a revision. It is easy to get a copy of the repository. It isn't the case for all projects, but for some there are some pre-build steps that the majority of people who want to install and use the project don't have or even know about. The project can put up the source after those steps are done, and the downloader does the final source building and installation with ease. As an end user looking at the release page, you can't tell the difference between the easy way (the pre-processed source that will work well for you) and the hard way (you'll need to install and invoke several tools for no real benefit). The underlying problem is that Github make it really easy for people to end up with the hard way, and not the intended easy way. This benefits no-one. I have no problem with them making the repository files available - I just want them to stop confusing people who go to a release page.
speg 11y ago
> They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?
- striking 11y ago
  A ZIP file is less helpful than the GitHub interface pointed at that specific commit ID.
  - JonathonW 11y ago
    It's not immediately obvious, but the tag and commit links to the left of the release (under the green "latest release" label) actually do that. The tag link points to the tree (in Github's file browser UI) for the release, and the commit ID link points to the specific commit for that tag (in Github's diff UI). Trouble is, this isn't very discoverable, given that those two links aren't styled as links-- they're the same font and color as is used for the subheading with date and commits since, which aren't clickable elements.
    - striking 11y ago
      Sure. The issue is less with the functionality and more with how it's presented to the user.
- david-given 11y ago
  Source distribution packages aren't necessarily a simple snapshot of the repository. For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
- maaku 11y ago
  Any reasonably complicated project has some pre-processing that has to be done for a source release. e.g. creating the configure script for autotools repos, or building the documentation. These steps can and should be automated, but github is not providing hooks to perform these automated tasks.
grk 11y ago
I'm not sure if that's what you're looking for, but you can edit release assets using Github's API: https://developer.github.com/v3/repos/releases/#list-assets-for-a-release https://developer.github.com/v3/repos/releases/#list-assets-...
mietek 11y ago
Adding a script that builds the project from “maintainer state” and referencing it in the README may save you some aggravation.
- rogerbinns 11y ago
  Not really. Not many people have the whole autotools/automake tool chain installed, let alone document building tools, and whatever other processing the project does (eg SQLite uses some TCL scripts). So they'd have to go and get all those, obeying any version constraints. And after all that they'd end up at the same point as getting an archive intended by the maintainer for them to build and install.
  - mietek 11y ago
    That is the intended outcome.
pravka 11y ago
Absolutely. This feature is such an integral part of a repo that distributes releases that I'm surprised it hasn't gotten more attention from Github. I, for one, would love to see them provide the checksum for the archives that are published via Releases -- it's not currently available when you create a release and relies on the operator to implement a workaround that creates a digest and publishes it on an external endpoint.
sytse 11y ago
We have the same 'Source Code' link in GitLab on our tag/release page. Should we rename it into 'download source' to be more clear?
- mdaniel 11y ago
  Or I am always a fan of putting a checkbox in the project's Settings page "show 'download source code' link" and a text box underneath it with "source code download label", enabling the project to use language they are happy with That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
  - sytse 11y ago
    We're indeed pretty hesitant to add options for these things, it makes it harder to refactor the UI if you have to account for all settings.
- rogerbinns 11y ago
  Google Code used to have labels, in particular one named "featured". You can label files in the release with it, and the ui put those at the top. Consequently it was clear to users which release files would be best. "Source Code" has two meanings. One is the preferred form of contributing to the project. The other is the preferred form for building and installing it on a system. Sometimes they are the same. However I argue someone going to a release page is more interested in the latter, and the former is confusion. I'd suggest making your UI reflect the page visitor's goals. "Repository Archive" is better wording, but still not that good.
radarsat1 11y ago
Glad someone else acknowledges this.. the number of times I've had to answer questions about how to get automake to work, etc., from people who should be just downloading the tar and running `./configure`. People are starting to get this tendency to check out the whole repository just to use the software. (I've been guilty of this too! There is something about it..) But people: If you're not going to work on the software, use the release distributions! In one project I went as far as making a "releases" branch, and actually putting the "make dist" output there, in full, and tagging that instead of the master branch. This was a pretty good compromise, since the github download link now points at the actual release tarball, and you can easily see from `gitk` which commit from the development branch each releases branches from. However, it's annoying not to be able to use tags as a way of navigating the development branch, and since I wasn't the one officially putting together final releases, eventually it was found that this was just too complicated to keep doing for each release. And it's just a dumb trick to satisfy github's weird releases interface anyway, so I couldn't justify the complexity.
trevorrowe 11y ago
The GitHub API allows you to provide much more useful content for a release. See this project as an example: https://github.com/aws/aws-sdk-ruby/releases https://github.com/aws/aws-sdk-ruby/releases - Notice that it has links for build artifacts, generated docs, and even contains links to issues closed by the release. Also, its pretty easy to automate a "release" from travis.
- cdcarter 11y ago
  The problem isn't that you can't add more content to a release, it's that you can't remove the misleading zipball/tarball links which are labelled source code but break traditional tarball conventions (e.g. not running autotools first).

deleted 11y ago

[deleted]

wnevets 11y ago

>They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. I fall for this everytime I go to use that link.

danielweber 11y ago
The people who dogfood Github, by using it every day, know how to get around places. The people who is it once every week or two, like me, get lost each time. It's always a hunt when I want to figure out how to do something, even if I know I've done it before.
- haberman 11y ago
  Totally agree. A few examples for me: - From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?). - At the top level of a repo (ie https://github.com/google/protobuf https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History". - continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmarks/ProtoBench.java https://github.com/google/protobuf/blob/master/benchmarks/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.
- ValentineC 11y ago
  I'm wondering what's a good way for a dogfooding company to look at things from a fresh perspective. Perhaps the traditional focus group and user interaction studies?
  - hussong 11y ago
    Listen closely to anything new team members have to say. From the inside, it all makes sense, but from the outside, it's often obvious insanity ;-)

Sir_Cmpwn 11y ago

I also have a problem with the "download zip" button on repositories. It doesn't include submodules. I've asked Github several times to give me a button to remove it from my repo, or to add submodules, to no avail.

rogerbinns 11y ago
I'll bet they have zero positive feedback over the Source Code zip, and you confirm yet more negative feedback over it.
- morgante 11y ago
  I like having it as a simple way to quickly download a git-free tree of simple projects. So there's one small piece of positive feedback.
  - kevin_thibedeau 11y ago
    It's also immensely useful for installers like pip that can pull an archive directly from Github using just a URL and no local git install.
    - rogerbinns 11y ago
      This issue is not about tools, but about humans being confused by the releases page. I have no problem with an archive of the repository being available - the issue is that github ui on the release page implies that is the best download to build and install the software, when it can be the least convenient hardest way.
  - rogerbinns 11y ago
    You can already get such an archive by clicking on the right bit of the release page. And I believe at any page reflecting a revision. It is easy to get a copy of the repository. It isn't the case for all projects, but for some there are some pre-build steps that the majority of people who want to install and use the project don't have or even know about. The project can put up the source after those steps are done, and the downloader does the final source building and installation with ease. As an end user looking at the release page, you can't tell the difference between the easy way (the pre-processed source that will work well for you) and the hard way (you'll need to install and invoke several tools for no real benefit). The underlying problem is that Github make it really easy for people to end up with the hard way, and not the intended easy way. This benefits no-one. I have no problem with them making the repository files available - I just want them to stop confusing people who go to a release page.

speg 11y ago

> They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?

striking 11y ago
A ZIP file is less helpful than the GitHub interface pointed at that specific commit ID.
- JonathonW 11y ago
  It's not immediately obvious, but the tag and commit links to the left of the release (under the green "latest release" label) actually do that. The tag link points to the tree (in Github's file browser UI) for the release, and the commit ID link points to the specific commit for that tag (in Github's diff UI). Trouble is, this isn't very discoverable, given that those two links aren't styled as links-- they're the same font and color as is used for the subheading with date and commits since, which aren't clickable elements.
  - striking 11y ago
    Sure. The issue is less with the functionality and more with how it's presented to the user.
david-given 11y ago
Source distribution packages aren't necessarily a simple snapshot of the repository. For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
maaku 11y ago
Any reasonably complicated project has some pre-processing that has to be done for a source release. e.g. creating the configure script for autotools repos, or building the documentation. These steps can and should be automated, but github is not providing hooks to perform these automated tasks.

grk 11y ago

I'm not sure if that's what you're looking for, but you can edit release assets using Github's API: https://developer.github.com/v3/repos/releases/#list-assets-for-a-release https://developer.github.com/v3/repos/releases/#list-assets-...

mietek 11y ago

Adding a script that builds the project from “maintainer state” and referencing it in the README may save you some aggravation.

rogerbinns 11y ago
Not really. Not many people have the whole autotools/automake tool chain installed, let alone document building tools, and whatever other processing the project does (eg SQLite uses some TCL scripts). So they'd have to go and get all those, obeying any version constraints. And after all that they'd end up at the same point as getting an archive intended by the maintainer for them to build and install.
- mietek 11y ago
  That is the intended outcome.

pravka 11y ago

Absolutely. This feature is such an integral part of a repo that distributes releases that I'm surprised it hasn't gotten more attention from Github. I, for one, would love to see them provide the checksum for the archives that are published via Releases -- it's not currently available when you create a release and relies on the operator to implement a workaround that creates a digest and publishes it on an external endpoint.

sytse 11y ago

We have the same 'Source Code' link in GitLab on our tag/release page. Should we rename it into 'download source' to be more clear?

mdaniel 11y ago
Or I am always a fan of putting a checkbox in the project's Settings page "show 'download source code' link" and a text box underneath it with "source code download label", enabling the project to use language they are happy with That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
- sytse 11y ago
  We're indeed pretty hesitant to add options for these things, it makes it harder to refactor the UI if you have to account for all settings.
rogerbinns 11y ago
Google Code used to have labels, in particular one named "featured". You can label files in the release with it, and the ui put those at the top. Consequently it was clear to users which release files would be best. "Source Code" has two meanings. One is the preferred form of contributing to the project. The other is the preferred form for building and installing it on a system. Sometimes they are the same. However I argue someone going to a release page is more interested in the latter, and the former is confusion. I'd suggest making your UI reflect the page visitor's goals. "Repository Archive" is better wording, but still not that good.

radarsat1 11y ago

Glad someone else acknowledges this.. the number of times I've had to answer questions about how to get automake to work, etc., from people who should be just downloading the tar and running `./configure`. People are starting to get this tendency to check out the whole repository just to use the software. (I've been guilty of this too! There is something about it..) But people: If you're not going to work on the software, use the release distributions! In one project I went as far as making a "releases" branch, and actually putting the "make dist" output there, in full, and tagging that instead of the master branch. This was a pretty good compromise, since the github download link now points at the actual release tarball, and you can easily see from `gitk` which commit from the development branch each releases branches from. However, it's annoying not to be able to use tags as a way of navigating the development branch, and since I wasn't the one officially putting together final releases, eventually it was found that this was just too complicated to keep doing for each release. And it's just a dumb trick to satisfy github's weird releases interface anyway, so I couldn't justify the complexity.

trevorrowe 11y ago

The GitHub API allows you to provide much more useful content for a release. See this project as an example: https://github.com/aws/aws-sdk-ruby/releases https://github.com/aws/aws-sdk-ruby/releases - Notice that it has links for build artifacts, generated docs, and even contains links to issues closed by the release. Also, its pretty easy to automate a "release" from travis.

cdcarter 11y ago
The problem isn't that you can't add more content to a release, it's that you can't remove the misleading zipball/tarball links which are labelled source code but break traditional tarball conventions (e.g. not running autotools first).