Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
In my experience of human nature, authors don't tag because they don't have to. If they had to tag so that their addon would be accessible, then they would.
A "softer" version of this would be to introduce tagging support into the scripts but also keep the packing of the trunk. The latter could be marked as "UNSTABLE" or similar to discourage the average user from picking that one. This could also be seen as a way to make the transition to using tagging more smooth for both developers and users.
It seems to me there are two issues here, one is how to handle depricated or broken stuff, and the other is the request to have a release quality distribution mechanism.
In a way I feel for the second there are solutions. If I feel a version is release-quality I put it up on another site. So far this site is advertised as beta and stuff I commit here will get quickly tested and I get debug report. I know that a lot of people do use it for basically release-quality updating so that is a problem of sorts. I can dig requiring an SVN flag for release versions and having the zip packager make 2 different zip depending on the flag, but in a sense I feel that'll just go wrong. People will set it for the first time they go release and then forget about it and basically turn their betas.
A better way may be to actually introduce a parsed tag into the commit comments. You do have to actively write these for every commit so there has to be a conscious decision to include a "- This is a stable version." or something like this at that time. It also prevents simply accidental "I forgot to change the svn flags again", which is just an extra step in the process and can easily be overlooked. So keeping it in the current workflow seems like a good idea.
A thing that still remains is how to allow beta-testers to quickly still get betas if in fact the default is set to stable. Because of course I do want my beta testers to test the betas! So there is a need to mess with updaters as well, and it seems that WAU basically needs someone who has the time and is willing to put up with the abuse.
For the first (i.e. finding stale addons) I still think a script scanning download/version request activity is the cleanest solutions. I just checked through my installs and many sensible pieces I use (a bunch of fubar plugins for example) are very old but working and would all need to be touched if one does a high TOC cutoff. Yet there are things that are marked as broken on the trunk (not many, actually I only found Cartographer_HeatMap which marked itself as broken (and probably should be moved to branches/archived)). I'm sure there are quite a bunch of essentially stale addons on there too but an activity log would give a very good indication which ones these are (and have a very low change of false positives unlike a tight TOC cut-off).
I don't know who made WAU, but the app is great and with 2 filters you can eliminate a lot of the aggrivation there is about the svn.
You can add date filters for for instance 10,30,60,100,150,200 days or never with a radio button.
and category filters on which ones to include in the big list with checkboxes.
The date filter can easily be added to the files.wowace.com pages too.
Second point is a request to the authors.
Document your stuff please. I mean there is a wiki here and you got the forum to give some info on wtf your addon does. Yet the world need to figure out what it is and nuking it afterwards since it isn't something they are looking for. I don't ask for a new King novel, but lacking in providing a decent describtion is looking like you don't take pride in what you've created. You can do it even Industrial does it with his mods.
As for the svn itself well you can remove stuff like old broken ones or ones that have replacements and that are old and no longer maintained, but that is a big task.
So there is a need to mess with updaters as well, and it seems that WAU basically needs someone who has the time and is willing to put up with the abuse.
Seriously, where did you come from? So much reason and understanding in all your posts, even when surrounded by a sea of pedagogy.
Seriously, where did you come from? So much reason and understanding in all your posts, even when surrounded by a sea of pedagogy.
I <3 U
Can I say something?
I will get loads of hate for this but ... wouldn't getting rid of WAU solve some of the issues? No more need to update it, no more "this and this isn't working" .. Everyone gets it from the site, those familiar with it will have no issues there. And less stress for poor Sylv.
How would you get rid of it? Simply not offer it for download? People would use the old version, or one of the many other updaters. Get rid of the .zip files? I guess then you'd get tons of people discovering SVN clients - not such a good thing.
No longer support it, period. Eventually, something in the svn/files setup will change, which will inadvertedly render WAU useless (an old version I mean)
No longer support it, period. Eventually, something in the svn/files setup will change, which will inadvertedly render WAU useless (an old version I mean)
And how would that prevent people from going to all the other updaters? Some of which are (IMO) more powerful than WAU, anyway?
Take all the addons, scramble them together ... make random zip names :P Give people a run for their .. time..
Quote from Pusikas »
And how would that prevent people from going to all the other updaters? Some of which are (IMO) more powerful than WAU, anyway?
Read what I said again... Change the way addons are zipped up/stored (aka change the svn setup). Whatever other updaters do, is their business. The downloads are still offered anyhow (and would still be offered) but it would at least put a stopper to the "WAU did this and this and doesn't do this and that". Sylv stated it is no longer updated, that he spent heaps of hours into it and mostly got shit from people. I just took that statement into an idea, a thought. Didn't say it was a cure-all, because there's no such thing.
PS. In case someone missed it.. I was being sarcastic in my own lacking way. Though I do feel that here and there, some minor nuissances could easily be fixed.
I think the main problem when you would stop offering WAU(or any other Updater) that the SVN load would increase way way to much as it did before files.wowace and WAU existed and back then far less people used WoWAce.
Even now when you are not omitting externals the DL is quite slow from the SVN, imagine 1.000 or 10.000 people not omitting externals and abusing the SVN for smth it was never meant for...
Even if you would "scare" some thousand away it would still be much worse than before.
I thank sylvanaar for the work he (and the former author) put into WAU! But i can understand the pain he gets by it from the people with "issues"
If I read this thread correctly, the issue is WAU downloads a huge "index" file, and it is eating up bandwidth (read $)
A possible approach it to send only the changes since last update...
To do this create say 31 separate index files like so:
0.xml (changes made today)
1.xml (cumulative change since yesterday)
2.xml (cumulative change since day before yesterday)
3.xml (cumulative change since 3 days ago)
:
30.xml (cumulative change since 30 days ago)
all.xml (today's index)
etc.
each file gets larger. someone updating every Friday would download 7.xml, and the multiple updates/day riders of the bleeding edge would download the small 0.xml
the current process would be modified to create these 31 files instead of the single monolithic one today.
WAU would always attempt to download ##.xml where ## is the number of days since last update. if the server detected that ##.xml did not exist it would redirect to all.xml (or just send it's contents instead)
Adding a age based cutoff (say 180 days -- just tossing out a number) for the all.xml the size of it would be kept in check as well.
PROS: Lower bandwidth
CONS: changes to WAU to request the correct file, and the ability to update the local "database". changes to the index generating script, and the server redirection to all.xml on a ##.xml request when the file does not exist.
As a user, I can only offer a suggestion based off of my own experience with updating addons from various sites.
I'd suggest picking a cut-off TOC, announcing it, and giving people a chance to either update their addons. Do it as a multi-stage roll-out. Stage 1 would be allowing authors to update addons. Once that date rolls around, provide a list of the addons that haven't been updated. Allow time for people to offer to maintain the addon / test if the addon requires changes to be compatible with 2.4. After that, all other addons could be considered unsupported / broken.
While I understand that just because an addon isn't supported doesn't mean that the addon is in any way "broken", it doesn't necessarily make sense to host it here. Wowace has always seemed to be a development site to me, and if an addon isn't supported by anyone here anymore, I don't see why it couldn't simply be posted at wowi or curse instead. Or simply list them as "As-is" and leave them accessible via the page with the zips and not the updater.
To me, the main advantage of using an updater is to quickly pick up versions of multiple addons that change frequently due to ongoing testing. For the rest of the addons, I just check the 'Load Out of Date Addons' check box within WoW. ;)
The hardest part of the whole thing is chosing an option and sticking to it. No matter what you chose, there will be people that will be unhappy with the choice. But as a user, I'd rather the people that put the work into making the addons, maintaining the tools (such as WAU)and providing support are the ones that are happiest. After all, they're the ones that put the work in; we simply enjoy the results.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIn a way I feel for the second there are solutions. If I feel a version is release-quality I put it up on another site. So far this site is advertised as beta and stuff I commit here will get quickly tested and I get debug report. I know that a lot of people do use it for basically release-quality updating so that is a problem of sorts. I can dig requiring an SVN flag for release versions and having the zip packager make 2 different zip depending on the flag, but in a sense I feel that'll just go wrong. People will set it for the first time they go release and then forget about it and basically turn their betas.
A better way may be to actually introduce a parsed tag into the commit comments. You do have to actively write these for every commit so there has to be a conscious decision to include a "- This is a stable version." or something like this at that time. It also prevents simply accidental "I forgot to change the svn flags again", which is just an extra step in the process and can easily be overlooked. So keeping it in the current workflow seems like a good idea.
A thing that still remains is how to allow beta-testers to quickly still get betas if in fact the default is set to stable. Because of course I do want my beta testers to test the betas! So there is a need to mess with updaters as well, and it seems that WAU basically needs someone who has the time and is willing to put up with the abuse.
For the first (i.e. finding stale addons) I still think a script scanning download/version request activity is the cleanest solutions. I just checked through my installs and many sensible pieces I use (a bunch of fubar plugins for example) are very old but working and would all need to be touched if one does a high TOC cutoff. Yet there are things that are marked as broken on the trunk (not many, actually I only found Cartographer_HeatMap which marked itself as broken (and probably should be moved to branches/archived)). I'm sure there are quite a bunch of essentially stale addons on there too but an activity log would give a very good indication which ones these are (and have a very low change of false positives unlike a tight TOC cut-off).
I don't know who made WAU, but the app is great and with 2 filters you can eliminate a lot of the aggrivation there is about the svn.
You can add date filters for for instance 10,30,60,100,150,200 days or never with a radio button.
and category filters on which ones to include in the big list with checkboxes.
The date filter can easily be added to the files.wowace.com pages too.
Second point is a request to the authors.
Document your stuff please. I mean there is a wiki here and you got the forum to give some info on wtf your addon does. Yet the world need to figure out what it is and nuking it afterwards since it isn't something they are looking for. I don't ask for a new King novel, but lacking in providing a decent describtion is looking like you don't take pride in what you've created. You can do it even Industrial does it with his mods.
As for the svn itself well you can remove stuff like old broken ones or ones that have replacements and that are old and no longer maintained, but that is a big task.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSeriously, where did you come from? So much reason and understanding in all your posts, even when surrounded by a sea of pedagogy.
I <3 U
Can I say something?
I will get loads of hate for this but ... wouldn't getting rid of WAU solve some of the issues? No more need to update it, no more "this and this isn't working" .. Everyone gets it from the site, those familiar with it will have no issues there. And less stress for poor Sylv.
Take all the addons, scramble them together ... make random zip names :P Give people a run for their .. time..
Read what I said again... Change the way addons are zipped up/stored (aka change the svn setup). Whatever other updaters do, is their business. The downloads are still offered anyhow (and would still be offered) but it would at least put a stopper to the "WAU did this and this and doesn't do this and that". Sylv stated it is no longer updated, that he spent heaps of hours into it and mostly got shit from people. I just took that statement into an idea, a thought. Didn't say it was a cure-all, because there's no such thing.
PS. In case someone missed it.. I was being sarcastic in my own lacking way. Though I do feel that here and there, some minor nuissances could easily be fixed.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEven now when you are not omitting externals the DL is quite slow from the SVN, imagine 1.000 or 10.000 people not omitting externals and abusing the SVN for smth it was never meant for...
Even if you would "scare" some thousand away it would still be much worse than before.
I thank sylvanaar for the work he (and the former author) put into WAU! But i can understand the pain he gets by it from the people with "issues"
Create another branch called outdated. Write a script that checks toc files, for anything lower than the previous toc. Move said addon to outdated.
Also simply remove any /branch/'ed addon with an outdated toc.
If the addon still works, I'm sure -someone- will update it's toc, and if not, well it's still in the outdated branch.
no.. but you must draw a line somewhere and can't just add more and more to the svn without some sort of cleanup.
And I'd start with outdated mods without an developer.. those addons fit on download sites like wowi or curse but don't need to be in the trunk.
A possible approach it to send only the changes since last update...
To do this create say 31 separate index files like so:
0.xml (changes made today)
1.xml (cumulative change since yesterday)
2.xml (cumulative change since day before yesterday)
3.xml (cumulative change since 3 days ago)
:
30.xml (cumulative change since 30 days ago)
all.xml (today's index)
etc.
each file gets larger. someone updating every Friday would download 7.xml, and the multiple updates/day riders of the bleeding edge would download the small 0.xml
the current process would be modified to create these 31 files instead of the single monolithic one today.
WAU would always attempt to download ##.xml where ## is the number of days since last update. if the server detected that ##.xml did not exist it would redirect to all.xml (or just send it's contents instead)
Adding a age based cutoff (say 180 days -- just tossing out a number) for the all.xml the size of it would be kept in check as well.
PROS: Lower bandwidth
CONS: changes to WAU to request the correct file, and the ability to update the local "database". changes to the index generating script, and the server redirection to all.xml on a ##.xml request when the file does not exist.
I'd suggest picking a cut-off TOC, announcing it, and giving people a chance to either update their addons. Do it as a multi-stage roll-out. Stage 1 would be allowing authors to update addons. Once that date rolls around, provide a list of the addons that haven't been updated. Allow time for people to offer to maintain the addon / test if the addon requires changes to be compatible with 2.4. After that, all other addons could be considered unsupported / broken.
While I understand that just because an addon isn't supported doesn't mean that the addon is in any way "broken", it doesn't necessarily make sense to host it here. Wowace has always seemed to be a development site to me, and if an addon isn't supported by anyone here anymore, I don't see why it couldn't simply be posted at wowi or curse instead. Or simply list them as "As-is" and leave them accessible via the page with the zips and not the updater.
To me, the main advantage of using an updater is to quickly pick up versions of multiple addons that change frequently due to ongoing testing. For the rest of the addons, I just check the 'Load Out of Date Addons' check box within WoW. ;)
The hardest part of the whole thing is chosing an option and sticking to it. No matter what you chose, there will be people that will be unhappy with the choice. But as a user, I'd rather the people that put the work into making the addons, maintaining the tools (such as WAU)and providing support are the ones that are happiest. After all, they're the ones that put the work in; we simply enjoy the results.