| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Recall releases
# Background
I messed up. We released a version of Tink's Subtraction that was bugged. The trainer poked maximum values in the registries on every load. But the max value was different depending on the level chosen to play at. I did a quick fix and released the new one where this aspect was perfected.
Then it showed that it also loaded one of the levels differently if you selected another difficulty level, so I needed to make a new fix and then also another version.
# What conflicting interests to take into account?
I think it's fair view that if you release shit and are sloppy in your quality assurance, it's only right if there is a level of embarrassment involved. At least to some extent.
It's also a fair view that preservers want all versions. At least to some extent.
But it is also worth taking into account that we also don't want people to pick up the wrong version of a game and spread it.
# Suggestions:
> Having said the above, I don't see the value in bugged versions risking to be spread over the final ones.
I want to be able to recall a release. I know this collides with the "preserve all" and the that I'm not properly dragged through the mud for sloppy work, but the bugged one is out of circulation.
I can edit comments - why not as a bare minimum give me the right to adjust (including removal) a release for the same duration as editing comments?
> If this is not possible, then I would want the option to issue a "replacement". I need to upload a new version which has a clear indicator that there was a previous - bugged version - that got replaced. Mud dragging and no spreading of the bugged one. Only counter argument is the access for the handful of people who see the benefit in that, intermediate, version.
> At least delete the download link for broken and replaced releases, and give the three people globally interested in preserving such bugged and replaced releases the option to download them separately. |
|
| |
hedning
Registered: Mar 2009
Posts: 4731 |
My view:
We all mess up. All my and other's sins are here to see and explore. Many times I would have liked to "recall" a release, but how do you really do that? It only takes one (1) download for the file to be potentially spread everywhere, thus being released. It's a fact that you can't recall a release. If something is released it's released. If we revoked the release we would be lying. I fully understand that people would like to have embarrassing (whatever reason) releases taken away and forgotten, but if we did that we would be promoting historical revisionism.
The rule to preserve everything here actually have two purposes: 1. The file was officially released, and thus it should have an entry here, fuckuped or not. If it's not 100% working; well - then we have purpose 2: Don't fuck up. Test the shit out of your releases and make sure you don't screw up. Test it even more, and then release it. The rule actually promotes better quality releases - hopefully.
Your third solution makes more sense. The release is archived and the interested people can still keep it, but it is not spread to other normal users, and unregistered leechers, that only want the working crack. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
imho uploading a release equals copying it to a disk and mailing it to your contacts. its out. deal with it.
if anything, it should make you think about whether rushing out these cracks for silly firstrelease points is the way to go in 2017.
(you can switch download link to "only visible when logged in" if you really give a damn) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
My suggestion is:
* Allow to upload a new file - and marking the old one as not valid - giving a reason. (Keep the old one for reference if this is important to some people)
* Give a rating for how well a group or person maintains only the first upload of their program.
=> S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate ...
Please mind:
If I release a game with file loader and then release an IFFL version, then that IFFL version is a new version. They should have separate CSDB entries.
If I release a version with a graphics bug and then correct it, this is the same version. And they should have the same entry.
Debugged and functionally different must be different. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
Isn't the "Proper release" flag a sufficient indicator to let people know that a version is bugged and shouldn't be the one downloaded to play? Maybe it makes sense to put that indicator in the list view as well. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Adding a field that says this release is an updated version of <ID> would solve the problem neatly. Everything gets a new entry, the way it should be imho, but deprecated entries can be clearly marked as such with a link to the preferred release. Especially useful for tools, e.g. when theres a new exomizer or sidwizard or ULoad etc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Quote:S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate
csdb collects all releases, and all releases get their own entry. its that simple.
and what seven said. and magervalp :) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Isn't the "Proper release" flag a sufficient indicator to let people know that a version is bugged and shouldn't be the one downloaded to play? Maybe it makes sense to put that indicator in the list view as well.
It's confusing to have multiple version of the very same program from the same group with only small patches as difference. If you are on one of the bugged, there is no automatic way of telling where the proper one is. That needs to be posted in the comments.
# Hold the same version together as a release - one entry - but allow upload of an updated binary.
# Keep all binaries and maintain a comment why it was made obsolete. I'm perfectly fine with the remark "Bacchus fucked up - pick up the fixed version and this one".
# Warn the user if they insist downloading the bugged version.
# Bonus: Keeps score of groups maitaining quality by never needing to upload a second version.
Please mind that we already replace broken versions if the error are due to transfer error or such. There it's important to share the proper version and not the bugged ones. There the originator can provide a new one.
But I guess that if I post the release with an external URL then I can update the d64 as I want and nobody could have any opinion about it. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
How about we only keep the BEST version of ANY game to protect poor users from downloading an inferior version?
There's a clear difference between a transfer error due to a degraded disk, and a group release that just happens to be borked because the cracker couldn't be bothered to test his work properly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
external links will be replaced by internal ones asap for exactly this reason (and because they disappear sooner or later).
anyhow, this all is hardly a problem.
and the confusing part is that it takes fairlight 3 tries to make a working crack of a children education game. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Quote:S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate
csdb collects all releases, and all releases get their own entry. its that simple.
and what seven said. and magervalp :)
Well MagerValp at least wanted a way to automate deprecation of old versions. So in a sense he proposes a vehicle to obsolete versions that are no longer current. I strongly support that.
All I add that that is that for minor adjustments I strongly suggest that this is done within the same release.
99% of all want the working release of program x. But we might want to facilitate that the 1% keeping all versions - including the bugged ones - and that we ensure that all the people who are keen to prevent sloppy releases, are also properly satisfied.
I think a fair balance is having minor iteration inside the release (as per my suggestion) and then the major version between releases (as per MagerValps suggestion).
On the "csdb collects all releases, and all releases get their own entry. its that simple." that it is how it is today. There is nothing saying that you cannot improve. This is not a BBS - we are allowed to make progress. It is that simple today. Nobody questions that. Does it hav e to be that tomorrow? No indeed not. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
for users that just want the working version there is gamebase. this isnt what csdb is about. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: external links will be replaced by internal ones asap for exactly this reason (and because they disappear sooner or later).
anyhow, this all is hardly a problem.
and the confusing part is that it takes fairlight 3 tries to make a working crack of a children education game.
I'm talking principles.
In the BBS world, it has always been possible to delete a version from a board and replace it with a new one. It's been done countless times. Why is that old principle no longer applicable?
It was always possible to give the swapper the game and in the middle of his copying you realise the issue and gave him a new version. More copying for the swapper, but no big deal. Why is that old principle no longer applicable?
=> Please tell me again the pros of having CSDB have multiple entries of games with five byte differences. Who benefits from that? That is still the main question? Is this place for the guys anal of having every iteration or for the greater good of the community?
To me, there is a clear and objective benefit of the community to steer users towards the debugged versions. I don't mind having the others as part of the same release if they are marked as made obsolete. But having people finding the wrong version and risking having the wrong version downloaded is NOT an ideal situation. I still don't see any valid argument for why that is a good thing.
On discussion individual releases, please take that discussion separately. That release was an instance of where the system would benefit but I can talk principles without using the examples. Here is a good place for that other discussion: http://csdb.dk/release/?id=160818&show=review |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
And I moved that discussion to where it belongs, to the discussion area (instead of comments, which I had to close now): Release id #160818 : Tink's Subtraction Fair +. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
first you are saying this isnt a BBS, now you say it should be?
indeed, principles. csdb collects all releases. its that simple. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
CSDb is NOT the scene. CSDb is no substitute for the BBS. If you want your first release, and what other reason is there for a rushed and buggy release, you should've uploaded to the BBS, deleted your bugged version there, uploaded the other version, deleted that too cause it was bugged as well, and maybe not uploaded anything to CSDb at all.
Since bugged version can be marked as such, a user can clearly differentiate. You're trying to redefine the rules that have been in place for quite some time because YOU messed up. If you don't want users to run into bugged versions, test your stuff. Ian did your work for you. Twice.
Don't get me wrong, I personally don't understand the need for X similar releases either, but those are the rules, deal with it.
We all know CSDb has issues, there are long lists of features missing, but there's also a 10+ year old codebase and a lot of people who claim they know how things are supposed to be done, but when it comes to actual commitment they're gone faster than you can point out a bug in a Failright release. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: CSDb is NOT the scene. CSDb is no substitute for the BBS. If you want your first release, and what other reason is there for a rushed and buggy release, you should've uploaded to the BBS, deleted your bugged version there, uploaded the other version, deleted that too cause it was bugged as well, and maybe not uploaded anything to CSDb at all.
Since bugged version can be marked as such, a user can clearly differentiate. You're trying to redefine the rules that have been in place for quite some time because YOU messed up. If you don't want users to run into bugged versions, test your stuff. Ian did your work for you. Twice.
Don't get me wrong, I personally don't understand the need for X similar releases either, but those are the rules, deal with it.
We all know CSDb has issues, there are long lists of features missing, but there's also a 10+ year old codebase and a lot of people who claim they know how things are supposed to be done, but when it comes to actual commitment they're gone faster than you can point out a bug in a Failright release.
Principles, ok? This discussion *springs* from that release - this is not *about* that release.
That release was a fuck up - I deal with that. No need to question that. It's a separate discussion. Follow Hedning's thread for that.
THIS discussion is how CSDB should handle such cases (and others) and how CSDB is continuously striving to serve the scene, in the best way possible.
First: Rules can change - if enough people with voting power agree. It's not like CSDB cannot change. It can. If the relevant people want it to. And it's implemented. So YES, I am trying to change a principle on CSDB. I indeed do. Being a layer by education I know that better than most; the rules we have now is what we have now.
We can agree on a change here, and if noone feels like implementing it, then it will still be the same. But let's target the discussion on what would be the best for the scene. In what way will CSDB best serve the scene? I don't deal with rules that are stupid by accepting them. I try to influence to change! This is the purpose of the discussion.
Secondly: CSDB CAN be a substitute for a BBS if it wants. For many people it already is. But Skynet is not yet self-aware. The forums are active which is a clear substitute for BBSes. I personally rather see CSDB as the place to officially release on. ZipCoding and uploading to a few selected BBS:es is IMHO pointless when CSDB could easily have that role. You say I should't upload to CSDB at all. Would the scene benefit from that?
I don't have any insight in how CSDB is run, but that will not prevent me from having opinions.
As per my suggestion; one release is one release, including the failed attempts, being presented as one. If fulfils the objective of logging all versions, it shames the group releasing it for it sloppy QA, it doesn't confuse the visitors with a plethora of version that have no interlinking (minimising the risk of the users getting hold of the wrong version). So all I am suggesting is the presentation layer! |
| |
Pitcher
Registered: Aug 2006
Posts: 61 |
To be honest, I agree on some parts, The biggest I also don't understand is the need for zipping a disk into 4 parts, then spending the best part of an hour uploading those to 3 different bbs's just to time and date stamp a release. We have multiple users on csdb at the same time so no arguments on lines could or where tied up on purpose, like we've seen in some recent threads ?
Be a lot easier First upload here wins? |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Bacchus:
1. Moderators run CSDb and rules can change, that is correct. We have heard your arguments. Thank you. You have the right to your opinions.
2. CSDb was a first release site for quite a long time, and had another approach. This inflicted, however, with the original idea with this site: being THE source of information regarding the C64 Scene. We had to take part in scene politics, and had rules on what first releases should be here or not etc etc. Quality ranks and so on. This made CSDb incomplete, so the rules changed. Fighting and drama between groups took a lot of work and energy and together with CBA's The Digital Dungeon FTP (which was a first release site too) CSDb stopped being part of scene drama and first release fights, and the first release scene moved to the BBS world completely, which made things a lot more easier for everyone. Boards was always part of the first release world though, Antidote has been one of the counted boards for very long, and the 100% move to three boards was also due to more boards emerging on the scene. There has been no complains over this move until you became active again. You do not like calling boards in 2017, and you do not like how the CSDb rules are written. And that is completely ok opinions, but regarding the boards, you have to talk to the guys running the first release lists (and all major groups have agreed on what boards to be first on). |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: To be honest, I agree on some parts, The biggest I also don't understand is the need for zipping a disk into 4 parts, then spending the best part of an hour uploading those to 3 different bbs's just to time and date stamp a release. We have multiple users on csdb at the same time so no arguments on lines could or where tied up on purpose, like we've seen in some recent threads ?
Be a lot easier First upload here wins?
If you want to play the game, follow the rules. You guys need to talk to the other players. All other major groups agreed on the current way of doing it. And: It has nothing to do with CSDb. Talk to the major first release groups. CSDb is only mirroring what they do and release, and do not want to take part in scene politics. |
| |
Pitcher
Registered: Aug 2006
Posts: 61 |
Im sure given the choice, that most people would rather download something from here in seconds and run it in an emulator or slap it on a memory card and pop it in a real c64, than take 10-15 mins downloading and to then start reconstructing a disk out of it.
If you had the option, to download from either source, which one makes more sense ? Especially when alot of releases end up on every source at the same sort of time.
I know what I would choose.
I'll quite happily follow rules, as I wasn't around when they where written, but I'm sure something somewhere could be updated a little.
And then we've also seen arguments here recently of blaming people tying lines up, hogging them while they get an intro linked game together, to get a first release, all that would be gone too ? |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Pitcher: All releases end up here as well, so no problems there. The boards are there to show who were first. If people want to download here, let them do that. If they want to enjoy the boards, let them. We are all playing with old computers here, why rule out the BBS world, when you guys are cracking games from 1985 for the C64? Enjoy the little magic that is still with the C64 scene, and that includes the boards.
If people hog lines they will be kicked out from the boards. Simple. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Several things at the same time, but it's me bringing them up so noone else to blame.
- The main topic is still the presentation layer; aggregating multiple versions of the same release with minor differences is IMSO enhancing the usability of the site. There is no usability advantage of splitting them. And this can be accommodated without deleting entries that the archivers want and proper bad karma for sloppy QA still lands on the cracker and group.
I haven't heard any relevant argument against that. The closest was seven saying he agreed it was stupid but it is like it is.
- The other topic, how to count and the rules around that is a separate discussion, where I totally agree with Pitcher of course, but still refrain from adding any comments. When ready to dive into that fully, then let's start a separate thread. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
<Post edited by hedning on 12/12-2017 00:32>
The relevant argument is of course that every release you do ends up here sooner or later as this is a database that aim to be as complete as possible. If you dont want your crack archived, don't upload it anywhere, or spread it. Pretty simple. If you do various versions, all versions ends up here too, so make sure you only upload stuff you know is 100% if you only want one version archived. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Bacchus:
1. Moderators run CSDb and rules can change, that is correct. We have heard your arguments. Thank you. You have the right to your opinions.
2. CSDb was a first release site for quite a long time, and had another approach. This inflicted, however, with the original idea with this site: being THE source of information regarding the C64 Scene. We had to take part in scene politics, and had rules on what first releases should be here or not etc etc. Quality ranks and so on. This made CSDb incomplete, so the rules changed. Fighting and drama between groups took a lot of work and energy and together with CBA's The Digital Dungeon FTP (which was a first release site too) CSDb stopped being part of scene drama and first release fights, and the first release scene moved to the BBS world completely, which made things a lot more easier for everyone. Boards was always part of the first release world though, Antidote has been one of the counted boards for very long, and the 100% move to three boards was also due to more boards emerging on the scene. There has been no complains over this move until you became active again. You do not like calling boards in 2017, and you do not like how the CSDb rules are written. And that is completely ok opinions, but regarding the boards, you have to talk to the guys running the first release lists (and all major groups have agreed on what boards to be first on).
Can I just add one thing;
I love CSDB. If I didn't I would care. I care, I hence like to see it improve. I'm pressed by how it's run. I subscribe to almost all of the principles it's based on. But nothing is perfect. And as I care I see that my suggestion would improve usability. I care, and see a gap where I don't agree with the principles.
All I say is that IMO, version with minor patches are iterations of the SAME release - not separate releases. Be it adding a missed greeting or typo in the intro scroller or a gfx bug in the game - still iterations of the same.
You insist on separating them which in my opinion makes sense for noone. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
I hear you. And I am just trying to explain how things work. My own views are for the moderators eyes only if and when we discuss this. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
somehow it shows that bacchus is a noob regarding csdb :=) |
| |
Smasher
Registered: Feb 2003
Posts: 520 |
"lateral thinking" is solving problems through an indirect and creative approach. for more info: https://en.wikipedia.org/wiki/Lateral_thinking
so in this case: send your girlfriends/wives to Ian Coog, Ian will (hopefully) lose interest in debugging kindergarten games on c64, nobody else will ever find any bugs, no need to upload new versions, no need for this discussion, problem solved. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
leave ian alone! |
| |
Tim
Account closed
Registered: Mar 2002
Posts: 467 |
Well.. if nothing else this thread made me realize there actually IS a field that can be used to mark a release as broken by the maintainer. . Would genuinely have loved to know this recently.. and, although off and on over periods of time, I am by far new to csdb so thanks!
Nitpicking though, Id like to add that this field is almost as well hidden as the Youtube link field, which I only found purely accidental recently after seeing Hedning comment to a user placing a Youtube link in the comments (and even then it still took me a while to find the actual field).
IMHO Bacchus has a valid point that, from a layout perspective, there is room for improvement, or at least I find his comments valid as long as visuals such as marguee-scroll are displayed in a very prominent place near a download, rather than useful information regarding the actual file(s). |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Tim: These fields are pretty new, so no worries. And if you are active on CSDb, using it for research, uploading lost releases etc, helping the database (as all users should, and is the main purpose of getting an account here), you should see these fields often as they are there when you add a release. |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
ZeSmasher: I am not a dumpster for used/old wives, I only accept unused or mint conditions, and possibly, young girls. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Still haven't seen any argument why grouping minor revision of the same release being a bad thing.
I for one appreciate if bugs are found and could be corrected. And I sympathise with the idea of being shamed for fucking up.
All I say is that I feel the users are penalised with a cluttered user interface that could be solved by grouping the minor iterations as one. Would be kewl if someone addressed the issue if why that wouldn't be beneficial for all. |
| |
Didi
Registered: Nov 2011
Posts: 487 |
I second the request to show the mark "broken" in list view in some way (different icon? little bug?). Makes it easier on search to skip broken versions.
The CSDb "keep it all, even it is broken or shit" policy has been discussed quite often. The best way to cope with it is to test your releases carefully before publishing them. Especially with old games there is no need to rush. Take your time for intense testing and maybe even let someone neutral check it because often you do not recognize your own mistakes. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I'm still in favor of keeping separate releases for the fuckups. It keeps the pressure on devs to test their shit before releasing, and it's a core tenet of the site that I agree with. My workaround for when I iterate (or just plain screw up) is to add a comment with a link to the fixed release (see Ultima IV Remastered V2.2 for an example).
I'd love it if we could formalize that with a field in the db, where e.g. 137951 is marked as being replaced by 138772, with the appropriate presentation changes. Multiple releases or downloads on the same page sound to me like more work for Perff, and more confusing for users. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: I second the request to show the mark "broken" in list view in some way (different icon? little bug?). Makes it easier on search to skip broken versions.
The CSDb "keep it all, even it is broken or shit" policy has been discussed quite often. The best way to cope with it is to test your releases carefully before publishing them. Especially with old games there is no need to rush. Take your time for intense testing and maybe even let someone neutral check it because often you do not recognize your own mistakes.
Good idea. Some bugged release-icon should be easy to implement as "broken" already is tagged, as well a field for pointing to a fixed release, if available.
I agree on the rest as well: best way to cope is to make sure your release is ok before a release. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
I agree, the best way to ensure this is no issue is that you never release anything with bugs. Anybody who ever dealt with software will know: this is utopia. We need to have systems to cope with bugs. A world of software will inevitably have bugs. Always!
I made the effort in illustrating how I would like to see it presented:
https://www.dropbox.com/s/wb8kcfjkvdk8v3j/example.png?dl=0
(And my Paint Program Fu sucks - it's a mock-up ok?)
# It satisfies the need to archivers to have all versions available.
# It satisfies those interested to play the games to find a current version that actually works (minimises the risk of picking the bugged one)
# It satisfies the cracker that the release is kept as one (and gives a framework for updates)
# It satisfies the need for the scene to put relevant shame and bad karma over those providing sloppy releases
Status Broken would then only be used to mark the most recent version as broken. The old versions are obviously inferior if they needed to be replaced.
Please mind that would give incentives to update cracks. I would consider making IFFL version of games that I previously released as file based. On some cracks you realise that adding a new trainer or two would be beneficial. The above would be a great vehicle to accommodate keeping the versions together, as they are logically the same but with minor adjustments.
There is no contradiction between this and MagerValps opinion of keeping major releases separate and have references between them. Up to the uploader to tell if the new version is a minor or major update.
Pleas elaborate over which aspects this doesn't satisfy! |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
I don't think grouping multiple files / versions in one entry is the way to go as this would only work for buggy cracks / demos and not for tool updates (i.e. version number in the release title). But I agree that it would be nice to have a place for the information about newer / bugfixed versions somewhere else than only in the comments.
In this special case: If you want to avoid confusion, just use the release title:
Supergame+
Supergame+ Final
Supergame+ Final V2
;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
cool a mockup \o/
i like how you make it appear as if it'd be a huge problem. you are planning to fuck it up often, are you? |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Groepaz - how about picking up on the questions?
How is my suggestion NOT a valid improvement?
I would be kewl if you say it's a good thing but it's on spot 1007 on the priority list for implementation. Or that it sucks for reasons X, Y and Z (like you do on the VICE list). Here you are just being arrogant. "Fuck you - things are good as they are" kinda attitude.
No I don't plan to fuck up. But users of CSDB don't deserve to be the victims when it happens! |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: I don't think grouping multiple files / versions in one entry is the way to go as this would only work for buggy cracks / demos and not for tool updates (i.e. version number in the release title). But I agree that it would be nice to have a place for the information about newer / bugfixed versions somewhere else than only in the comments.
In this special case: If you want to avoid confusion, just use the release title:
Supergame+
Supergame+ Final
Supergame+ Final V2
;-)
As I say in my text above;
- One solution for cracks and demos that get updates/fixes and tools with minor releases
- One other solution for major updates |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
i think you are still missing the point on what csdb is about, and what it wants to be and what not.
what csdb is about:
- csdb is an archive, csdb collects all releases, buggy or not, intended or not, liked or not.
what csdb is not about and does not want to be:
- a software development platform with version tracking (use github or sourceforge or whatever else you prefer)
- a release outlet (use your homepage, upload to some ftps, use the boards, use forums)
- a BBS (use telnet for this)
- a fronted for gamers to find the best release of a game (there is gamebase for this)
- part of the warezdrama scene (use the BBSs for that)
what you are proposing just doesn't solve an actual problem. it would be very much needed IF releasing different versions of the same release would be a common thing in c64 world. but (thank god for this) it is not. quite the contrary - its pretty rare and doesnt happen often at all. so sure, once all the other much more important things on the 100 miles long TODO list have been added, someone may have a look at it and give it a go. at the current speed of development your grandchildren may enjoy flawless versioning on csdb.
that said, i actually really think that those who fuck up their so called first-releases should get punished and exposed. and that csdb shouldnt actually encourage this nonsense by adding features that makes it easier or less annoying to handle. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Thanks - fair answer. Not witty reply but something you really put your head into. Much appreciated!
I'm more than happy to have a conclusion that in order to best support the *visibility* it might make sense to do it like as per my mock-up. But that it was silly low in priority.
Then I have achieved something with the discussion. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
And adding to that;
- It's indeed *not* Github. If it was then we'd add all builds of a program - possibly some archiever would want that in order to capture EVERY revision of work in progress :-P
- It's indeed a release outlet for a number of people. Scene releasing is separate, but it happens on CSDB as well. Why shouldn't it? There is no point in adding stuff to CSDB much later than putting it out somewhere else, is there?
- A BBS is a function for files and discussions - CSDB has both. The Forum is for sure a discussion boards as good as any BBS.
- A front-end to pick up games? Well people are using it for that. I would argue that that is what a lot of people primarily use it for. So here the internal perception might be in total disharmony with the external...
- And I agree that the warez scene is separate. It's an agreed mechanism for what releases to count and how to count. Having said this, I can't see why they couldn't count stuff that was put online on CSDB if they chose to, and CSBD can't do anything about that someone else is making a point system based on what appears on CSDB. But that's a discussion for those making the point systems.
And;
I assume the "real problem" by your definition is the releases of bugged versions. I agree that is a problem.
But that should be a scene problem. And did someone just say that CSDB is not the scene - is merely an archiving site. It's not the place to cast bad karma and involve in scen politics. And yet that seems to be a few people main objective. I think a few people need to think that over another round ... I have my mind clear on the matter! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
csdb _was_ counted as a release "board" until some years ago. and the result was that csdb admins had to take part in silly nonsense related to it all the time, which became really time consuming and boring to handle. (around that time CBA removed the entire "warez" section from TDD because of similar reasons).
thank god some time later the warez ppl decided to move to BBSs.
and obviously csdb can do everything about who uploads what and what stuff can be here and what can not. there were times when cracks were not allowed at all, for example :) |
| |
Seven
Registered: Jan 2002
Posts: 202 |
Your mockup is oversimplifying things. It would be insufficient to simply "deprecate" binaries as the different versions will most likely have different meta data attached to it. Different date, potentially different credits, _especially_ if, as you suggest, it would motivate people to "update" their cracks.
I do think that you're actually struggling with the definition of the word "release" though. If it's out, it's a release. If you put another version out, it's another release. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quoting Bacchus
- A front-end to pick up games? Well people are using it for that. I would argue that that is what a lot of people primarily use it for. So here the internal perception might be in total disharmony with the external...
Mad people. When I need a game, I often out of bad habit go to CSDb and search for the game, just to find 2000 various cracks of the game which is REALLY annoying. Then I go to gb64 instead, like it's supposed to be. :)
That being said, chaining releases to each other in a more structured form than exploiting the comments section would be good for many reasons like: deprecation as Pontus mentions, other versions, party-version of a demo vs the 100% 101% and 110% versions, etc. Updated tools with new features and so on. There are many reasons why you'd like to chain / connected releases to each other. I think as for preservation this "meta data" would give you context, which you otherwise kind of lose. And for the rest of us it would just be a nice thing to have. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: Your mockup is oversimplifying things. It would be insufficient to simply "deprecate" binaries as the different versions will most likely have different meta data attached to it. Different date, potentially different credits, _especially_ if, as you suggest, it would motivate people to "update" their cracks.
I do think that you're actually struggling with the definition of the word "release" though. If it's out, it's a release. If you put another version out, it's another release.
This. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Quoting Bacchus
- A front-end to pick up games? Well people are using it for that. I would argue that that is what a lot of people primarily use it for. So here the internal perception might be in total disharmony with the external...
Mad people. When I need a game, I often out of bad habit go to CSDb and search for the game, just to find 2000 various cracks of the game which is REALLY annoying. Then I go to gb64 instead, like it's supposed to be. :)
That being said, chaining releases to each other in a more structured form than exploiting the comments section would be good for many reasons like: deprecation as Pontus mentions, other versions, party-version of a demo vs the 100% 101% and 110% versions, etc. Updated tools with new features and so on. There are many reasons why you'd like to chain / connected releases to each other. I think as for preservation this "meta data" would give you context, which you otherwise kind of lose. And for the rest of us it would just be a nice thing to have.
This. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
That's really moving the discussion forward, reposting voices that support your side and not addressing any of the issues pointed out in your own suggestion and flawed grasp of vocabulary.
Carry On Cracker. |
| |
Pitcher
Registered: Aug 2006
Posts: 61 |
OK, I tried to keep out of this, I do agree partly on both sides, but there are a few flaws :
Part of what I did read by different people brought up the same subject :
Csdb wasn't a release site, which obviously by the first release rules if a bbs is down they are, If they like it or not.
Or that Csdb had stopped being part of the scene because of all the politics or the time tied up with with first release issues, but scene rules are still classing Csdb as part of the scene to be able to use the time/date stamps of releases as/if/when a bbs is down. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: OK, I tried to keep out of this, I do agree partly on both sides, but there are a few flaws :
Part of what I did read by different people brought up the same subject :
Csdb wasn't a release site, which obviously by the first release rules if a bbs is down they are, If they like it or not.
Or that Csdb had stopped being part of the scene because of all the politics or the time tied up with with first release issues, but scene rules are still classing Csdb as part of the scene to be able to use the time/date stamps of releases as/if/when a bbs is down.
It's one thing to actively being part of it, and another to use it from outside as a backup plan as all releases should end up here as well.
CSDb do not want to be part of the first release dramas, and the first release groups seems very helpful to keep true and with that support the BBS scene as much as possible. They are doing a good job, and more and more boards are popping up, and with modern wifi modems for the c64 the popularity seems really good these days. It's just as odd making demos and cracking games on the c64 in the year 2017 as it is to call boards running on real hw. For me, the scene would lose some of the charm if we did not use all possible ways to explore and enjoy the C64, which is why we are here.
I know Bacchus has been complaining about having to call boards for at least the latest year or so on Facebook, he has been very clear about that on various occations, and it seems Fairlight is the only active cracking group complaining about it, and very strongly tries to change how the first release scene should work out. The rest of the first release groups clearly support, like and run boards themselves, and accepts the rules that is. Jazzcat always ask around when changes are being made, so you should discuss with him, and then he can orchestrate a discussion about what rules that you guys want to change in The List in Vandalism News, which is his diskmag. If he think they are sound that is. It is really up to him.
Or you can start a list in a diskmag of your own with your own rules, and try to convince all other groups to join in on that one instead of the rules we have been working with for years and years. Good luck! |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
The thread runs our in all sorts of directions, and I try to stay with the original line of thought;
- I still insist that from a usability perspective, grouping releases fulfils all relevant parties interest in this.
The only counterarguments I heard are
1) The wish list for development is LONG (fair argument - it says I have a point but one that is quite unimportant in priority)
2) Groepaz said "those who fuck up their so called first-releases should get punished and exposed" This second one I find VERY hard to combine with the notion that CSDB should not involve in "scene drama". Or "csdb admins had to take part in silly nonsense related to it all the time".
So who is it really for? If it was really "first release scene agnostic", then the idea of "punishing and exposing" people people for what they do on that scene seems a bit odd, doesn't it?
And Seven, if the other meta data for release is changing, then that is a strong indicator that a release is a new one. But if the same people involved change ten lines of assembly and build the project again, I still fail to see how that justifies a new entry with repeated metadata, clogging up searches and all of that.
But it's like social media arguments - people digging trenches, where listening to valid arguments it out of trends. People use the pause in their own talk, not to listen to others but to breath in so they can say more things. It's not a dialouge without the listening part, and it's not decent to others if you don't try to take in what others say. I REALLY try to find arguments in what I see here. It's just that I don't really find any ...
This must start with "Who is CSDB for and what are their needs?"
= It's not for the 1st release scene? Fine, then all the arguments that has this perspective as their starting-point are void in the discussion I guess. (Including #2 above)
= If it's only for the archievers, then the more versions the merrier isn't it?
So who is it for and what are their needs? How does CSDB best serve them? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
if only you had put as much time into testing and fixing the damned crack as you put into writing posts in this thread...... :=) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
I very well did, and then some ... This 1984 game was one of the more difficult I have done given it's quite clever loading system, as is well described in the docs supplied.
But this discussion is not about that crack - it's about what CSDB is, who it serves and how to best fulfil that task. And it's saddening to see that the arguments for stiff positions are so lame, poorly founded, inconsistent and contradictory. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
this thread is all about this crack. it wouldnt exist if you didnt fuck it up. get over it. move on. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Such releif - so you can focus your replies towards that and not the posts in the thread :( |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
whats the point, everything has been said already. you are just writing more and more, ignoring what has been said. |
| |
lemming
Registered: Oct 2009
Posts: 44 |
Hi. Nice discussion. Just wanted to personally affirm, what most people have kept repeating here, is that an updated release is an updated release, whether it's from 2017 or 1987.
This does not go just for cracks, you can find demos and intros and gfx and music from the past 35 years just the same.
Whether it's a legendary demo from 1987 or a poor crack from 2017, the difference could be anything from an minor variation in some routine to a simple testament of one's failure to test sufficiently. Most times it'll make a cool or interesting story after some time has passed.
Test the shit out of your releases. Get a tester if you don't have the patience to do it yourself. Sleep a night or two after you've finished something which was more or less of an effort. Give it a go again after you've rested enough in order to not be blind to your own mistakes.
If you were working on a deadline, everyone will understand why a fixed version is out there. If you were simply being hasty, just put out a fix, let folks know what was wrong with it originally, deal with it and move on. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Cutting out the core:
This must start with "Who is CSDB for and what are their needs?"
= It's not for the 1st release scene? Fine, then all the arguments that has this perspective as their starting-point are void in the discussion I guess. (Including #2 above)
= If it's only for the archievers, then the more versions the merrier isn't it?
So who is it for and what are their needs? How does CSDB best serve them? |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: Cutting out the core:
This must start with "Who is CSDB for and what are their needs?"
= It's not for the 1st release scene? Fine, then all the arguments that has this perspective as their starting-point are void in the discussion I guess. (Including #2 above)
= If it's only for the archievers, then the more versions the merrier isn't it?
So who is it for and what are their needs? How does CSDB best serve them?
It's not for the 1st release scene, and it's not just for archivers. Click "Help" and you can start reading there: http://csdb.dk/help.php?section=intro |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: It's not for the 1st release scene, and it's not just for archivers. Click "Help" and you can start reading there: http://csdb.dk/help.php?section=intro
"...and as much information about these [released etc.] as possible."
I.e. how releases relate to each other in terms of linking releases is a very valid meta data to have. Not just to cover fuck-ups but also f.e.
"Booze Design, 1991" ----> "Some old demo I forgot the name about." Reason: Refers to this demo as breaking the previous dot-ball record by 56 extra dots.
"That demo over there" ----> "The other demo here" Reason: Part 2 ripped but font changed.
or finally.
"Bacchus release #2" ----> "Bacchus release #1". Reason: He screwed up badly and Groepaz is furious, the old release is borked. This new one is the one to use.
And so on...
Not that I really care, for me CSDb is something else. Just trying to give Bacchus some extra quite valid arguments. But then, if it's low prio it's low prio. At least he has a point. It would be fair if at least that was acknowledged. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Of course you could do different links between releases. The connections are as many as there are releases though, why often a link in the comments field is enough. You can find that everywhere on various releases. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Everything seems to have been said here now. Things are only repeating. Mods have all the info - don't call us, we will call you. Time to focus on new releases, everyone. Be creative. Closing thread. |
