| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Please stop "cleaning" disk images
... or at least after you do so, test if the damn release still works after doing so. not seldomly there is other stuff on the disk that is needed - and its not necessarily obvious, or even visible in files. it really sucks to find those non working things when it is obviously the result of someone trying to "optimize" the image. ideally also attach the non cleaned image - that also keeps the context with the other games on the disk intact, which is sometimes kinda interesting to see.
thanks. |
|
... 21 posts hidden. Click here to view all posts....
|
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: This is the wrong reason but thanks for adding cleaned disks :-)
The real reason for adding cleaned disks is of course that the release entry is about a release and not about a spreaded disk where the release was on. There are other sites for dumping disk images.
We have many comment fields for a release entry for preserving info that is found on a disk or on a release. No need to add uncleaned disks for this.
Anyway, always add a clean disk to a CSDb release entry. The uncleaned disk might be added but really not needed. It only makes the release entry 'dirty'.
Bottom line is that after cleaning a disk, always test the release and double check if all the files from the release are present. Also check for useful info on the uncleaned disk that can be added to CSDb.
If you're unsure that you missed something from a disk, you can always add a comment from which disk of which collection the release was found.
That is also my view. The entry is for a specific release and nothing else. If people are lazy and just add a whole disk with all kind of crap on it is harder to find the release and the rest of the content on the disk is considered noise. I understand Groepaz’ view on preserving the whole spreaddisk etc, as it puts the release in a context, but I do not agree this database is the right place for that. The collections that the release is part of are more important for that. If you are interested in the content context my view is that the collections available online are a better place to look.
That said, I agree completely on that the releases uploaded here must contain all files of the release in question, and that it must be tested prior upload. Sloppyness and lazyness can never be an excuse. Also: context can be added as info in various fields. And do not forget to add screenshot(s) and credits. Read intro scrolltexts, help your fellow researchers with info and trivia, and add sources for the added info. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:The collections that the release is part of are more important for that.
unless there is a link to that disk in that collection right in the entry here, or adding all that info that gets lost when cleaning the disk becomes mandatory, thats just invalid blabla. (and there are also more than enough disks that dont come out of some "collection", none that is publicly available anyway) |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
Many releases appear on many different spread disks, should we add all of them to the entry then? |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Many releases appear on many different spread disks, should we add all of them to the entry then?
Good point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
the disk that the respective group made. there shouldnt be too many of them.
but yeah, i'd rather see some more d64s added than yet another stupid idea that removes info from the db for no good reason. what problem does this "cleaning" solve exactly? (dejavu >_<) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: the disk that the respective group made. there shouldnt be too many of them.
but yeah, i'd rather see some more d64s added than yet another stupid idea that removes info from the db for no good reason. what problem does this "cleaning" solve exactly? (dejavu >_<)
Sorting out a release from a disk full of other stuff, is reducing redundant data, it saves space, and keeps away inconsistencies. Which I think is part of good database design - if what we mean with every entry here is an entry for the release in question, and nothing else.
For a "Scene Original Disk Database" it's bad however. Then we should feed cbm8bit.com and their 8bit Disk Image Search. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
It's removing useful info. period. It doesnt solve a problem either. It's almost as bad as creating a silly new release type for something that should be an additional tag, and removing info in the process.
And all that doesnt even matter - because STILL properly testing a multifile game is something that is close to impossible - and noone will bother doing so. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: It's removing useful info. period. It doesnt solve a problem either. It's almost as bad as creating a silly new release type for something that should be an additional tag, and removing info in the process.
And all that doesnt even matter - because STILL properly testing a multifile game is something that is close to impossible - and noone will bother doing so.
<Post edited by hedning on 24/3-2019 22:56>
We are a very small fraction of users filling the database. I'd say a vast majority of the users here don't bother to do shit at all to the database. They are not uploading, they are not adding info, they are not researching... That is the main problem.
And hell yes. Everyone should make sure that every release they upload is complete. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Even more important: they should make sure to not destroy the data they upload by "cleaning" it. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Even more important: they should make sure to not destroy the data they upload by "cleaning" it.
Correct. They should make sure that the release they upload works. But I thought we already established that. The data we ask for is the release, and all credits etc. Nothing more.
I am sure that uploading full untouched disks instead of only the release in question never has been the common practice at any time here on CSDb. |
| Previous - 1 | 2 | 3 | 4 - Next |
