Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove STLs from repository #43

Open
brad opened this issue Dec 7, 2011 · 8 comments
Open

Remove STLs from repository #43

brad opened this issue Dec 7, 2011 · 8 comments

Comments

@brad
Copy link

brad commented Dec 7, 2011

I don't think the STL files belong in the repository, it's sort of like putting a binary file like a .exe in a repository because they are compiled from code.
I would suggest releasing them every so often in packages, along with the compiled documentation (pdf, html, wiki. These should not be kept in the repo either, IMHO), just as releases are done with software.
What do you think?

@Spacexula
Copy link
Collaborator

We have people come into reprap from all skill points. Your right, for someone of your skill level that is the best answer, but if it's someone that wants to put a 3d printer together and the second you say "compile" they start shaking, it's not the right answer.

I say keep the STL, I know the 1st time I put together a Prusa, I did it from the STL because I was scared of the scad files.

@brad
Copy link
Author

brad commented Dec 7, 2011

I agree no one should have to compile. The STLs should always be available without compiling, just like software binaries are often available without compiling. That's why I suggested doing package releases of STLs. So right now there would be two packages, one for iteration 1 and one for iteration 2.

@brad
Copy link
Author

brad commented Dec 7, 2011

Also, downloading a zip is much more user friendly (for the average user) than using git. I know github allows you to download the repository as a zip, but that's not very intuitive on the download page with the message "Sorry, there aren't any downloads for this repository."

@DaleDunn
Copy link

DaleDunn commented Dec 7, 2011

It didn't take me too long to find the zip download option when I first came looking for the files as a complete noob in both RepRap and Git. It wasn't that long ago that I was getting started, so I remember well that I was glad I wouldn't have to track down a stash of stl files in some other location, or figure out how to make them myself. I'm very glad that those developing this printer take the time to include them so everyone else isn't forced to find or make them. That is in fact the very reason I include STEP file exports of the stls in my fork. They are temporary files for me, but may be a starting point for someone else.

What advantage do you see in doing releases separate from the development repository? If I understand Git at all (no guarantees), it seems that everything in the repository is something like a release already.

@brad
Copy link
Author

brad commented Dec 7, 2011

It sounds like your argument is that this will make it harder for lay-users to find the STL files. I think the opposite is true. Any packaged release would be on the same page as the current repo zip and additionally it would be clearly labelled "Prusa-Mendel-(version).zip" or similar, so no one would need to track them down any more than they do now.

It's also nice to have a nicely defined version for reference. This is nice for when people have a problem with a particular part. You can ask them "What version is it?" and they can have a coherent reply. As it is now the best we can do is refer to the commit hash and most people aren't going to know what that is.

It should be an almost transparent change to those who just need the STLs, the download will be in the same place it is now. Honestly I don't see any downsides to this change, only upsides.
To recap on the advantages:

  1. Packages can be found in the same place they are now, but more clearly labelled.
  2. More clearly defined versions
  3. No compiled files polluting the repository.

Disadvantages:
None

This really fits perfectly into the software development paradigm and I think that's the best approach to use here. It is rare that a software developer recommends including compiled files in the repository, in fact we usually take measures to ignore them (.gitignore, .hgignore) to avoid accidentally committing those files.

@DaleDunn
Copy link

DaleDunn commented Dec 7, 2011

It sounds like what you're really asking for is for the Prusa Mendel to adopt a system of releases. (The location of stl files being a secondary issue). The people who come to this repository, do they want a reference point like a release, or are they looking for the latest possible version? This is why I'm asking what advantage you see in doing releases with clearly defined versions. My own speculation is that people aren't much concerned with it. I don't see much need in the RepRap forum discussions for being able to identify which particular version of a Prusa part is in use. I don't monitor IRC though. Does the need appear in discussions there? Is there a need for those doing the development of Prusa? These things I don't know. If releases make sense, then storing the stls with the release makes sense as well. I'd still like them in the latest version too.

@brad
Copy link
Author

brad commented Dec 17, 2011

To be honest my main concern is removing compiled files from the repository. However, the STL files need to be available somewhere and release packages are just the only viable alternative.
I don't see why we should be so concerned about supplying users with the very latest STL files at every moment. There will probably be parts that break at times. One of the points of releases is to reduce those breakages.
Anyone else have an opinion on this? I think we may have reached a stale mate. Time for an IRC poll?

@DaleDunn
Copy link

Well, we can take a poll on IRC, or whatever venue the most reprappers frequent. Mr. Prusa will do what he thinks is right, I'm sure. I've been waiting to see him comment on this, actually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants