I understand all the points of view above, however reality bites!
I have often spent days with my (oh so humble attempts at) writing extensions, testing back and forth with obliging testers and racking my tortured brain as to what the solution to bugs could be. When a fix is finally implemented and testers give the OK, the last thing on my mind is "...now let's spend a day or so commenting the code and creating a Nobel prize winning read-me..."
Of course, in the commercial world, that's what's expected and part of my real job is just that, making sure documentation is up to scratch. My insistence on this often holds back the release of updates which annoys everyone involved, but the customers are the ones that cause riots if instructions are not clear, correct, precise and with pretty pictures.
So in the real world where $$$ are at stake we do things right, in the "other" world we slack off a bit because there are no $$$ at stake and no kick in the pants if we stuff up.
No, not an ideal situation but reality nonetheless.
Vanilla is free software, yes? Every bit as free as Linux, yes?
So nobody really needs permission to create their own pre-packaged Vanilla "distribution".
The sticky part is fixing bugs. You can't just update someone else's extension because you run the risk of getting out of sync when the author finally does fix it himself. You could fork the extensions you want and maintain your own "shadow" versions, but that's a hell of a lot of work, not to mention a potential licensing problem.
In any case, it would be great to have add-on status like AlexL mentioned (alpha, beta, stable, mature). Of course, some people have differing standards (hint: If it isn't documented, it isn't fucking finished yet).
Another vote for alpha, beta and stable rating of extensions. Of course, if it doesn't count as "stable" until it's documented, most stuff will stay beta forever
Can I also suggest release histories? That way people can use older versions if they *really* want to.
squirrel, no one does need permission to create their own pre-packaged Vanilla distro, no. However, it is polite to see what Mark thinks about it no?
<thinks aloud>How may variations and permutations would there be, of add-ons that could be pre-packaged or not with Vanilla? Just look at the current situation where people have so many varied opinions, needs and wants. Seems to me it's a backwards step to even consider such a thing. The whole point of add-ons is to allow us to tailor-make to our hearts' content. You don't need a crystal ball to see that any package, no matter who puts it together will contain add-ons you won't want and those that are missing so it's back to disabling some and installing others which is where things are now. Unless of course you're in the group who think umpteen variations of Vista is a good thing, lots of variations which almost suit some and don't suit many.</thinks aloud>
I agree that nothing will ever satisfy everyone, but why not make things a little easier for some? If you want to roll your own, that's still the recommended route to go after all
If a package *is* perfect for you, then you have the added knowledge that the addons have all been tested together and function well — for some people, this will be just what they need/want.
It's easy enough as it is mate, certainly no difficulty to justify the effort required to create packages which will have limited appeal in any case.
Now if we are talking tried and tested add-ons you have my attention. But shouldn't all add-ons be good-citizens? I don't see the link between compatible add-ons and packages.
It's easy enough as it is mate, certainly no difficulty to justify the effort required to create packages which will have limited appeal in any case.
This is as far as I'll take this part of the discussion as I'll feel we have a different view on this matter and that's fine, but there's no point trying to convince each other otherwise . I understand you don't see any value in bundled packages, but from the rest of the responses in this thread I'd say there's a reasonable appeal.
I completely agree that all extensions should be good-citizens, but as we all know, they're not. Mine have been the cause of some problems and so have many others. The link between compatible extensions and bundled packages is simply that some extension, by their very nature, conflict. Bundles will be guaranteed not to include conflicting extensions. That's all
Also, If someone is actually putting time and effort into putting together a bundle, they'll mention any conflicts between extensions that should work together to the extension authors and push a little harder. It's also possible that extension authors may feel a little more incentive to fix things if it looks like their extension is going to be put in a bundle because it's flattering
Also, some people will be interested (maybe) in putting together bundles who aren't necessarily interested in writing extensions, which will create more eyes to look at the problems and hopefully improve them.
Every add-on should be well tested, excellently documented and never conflict with anything else, but this isn't how things are or ever will be (not 100%), so anything that gives an incentive for this to happen has got to be good right?
Wanderer, I think that packages are beneficial even from a promotional stand-point... they say "Hey, you know this basic but stable forum software, look what it can do - just add sprinkles!", they average user is used to coming to a forum, bloated with useless crap, and I think it's great that Vanilla doesn't, but some of that crap they will still want - I am just suggesting that packages that sanitise Vanilla in a way that is familiar to what your average administrator comes to expect from a forum will give them a foot in the door as to the potential of Vanilla... they will soon realise, that they can remove and install extensions and will get the hang of it, but it isn't entirely obvious to begin with.
I think that beta, alpha and stable extensions are a great idea.
As for lack of documentation - where it is nice to have it, I don't think it is necessary - I have recently been taking apart Jazzman's MultiRoles extension, which is largely undocumented, but it didn't take long for me to understand his logic, and I am well on my way to reaching my goal with it. Perhaps a lack of documentation weeds out the poor coders? (not that I am particularly good... maybe it weeds out the undedicated xD)
Extension authors should use Google code for development and the Vanilla repository for publishing the stable version of their add-ons.
Using Google code would allow collaboration. Also for those who customize add-ons, adding the modification from the author will simplify; they will just have to create a patch.
From the Google Code page: Note: you have a lifetime creation limit of 10 projects in total. If you need more, please come to the google-code-hosting Google Group to discuss.
Wonder if there's a way to make it so you can have all your extensions under one project?
Comments
I have often spent days with my (oh so humble attempts at) writing extensions, testing back and forth with obliging testers and racking my tortured brain as to what the solution to bugs could be. When a fix is finally implemented and testers give the OK, the last thing on my mind is "...now let's spend a day or so commenting the code and creating a Nobel prize winning read-me..."
Of course, in the commercial world, that's what's expected and part of my real job is just that, making sure documentation is up to scratch. My insistence on this often holds back the release of updates which annoys everyone involved, but the customers are the ones that cause riots if instructions are not clear, correct, precise and with pretty pictures.
So in the real world where $$$ are at stake we do things right, in the "other" world we slack off a bit because there are no $$$ at stake and no kick in the pants if we stuff up.
No, not an ideal situation but reality nonetheless.
Posted: Wednesday, 29 August 2007 at 9:36AM
So nobody really needs permission to create their own pre-packaged Vanilla "distribution".
The sticky part is fixing bugs. You can't just update someone else's extension because you run the risk of getting out of sync when the author finally does fix it himself. You could fork the extensions you want and maintain your own "shadow" versions, but that's a hell of a lot of work, not to mention a potential licensing problem.
And, of course, some problems with extensions are due to bugs in Vanilla itself.
In any case, it would be great to have add-on status like AlexL mentioned (alpha, beta, stable, mature). Of course, some people have differing standards (hint: If it isn't documented, it isn't fucking finished yet).
Can I also suggest release histories? That way people can use older versions if they *really* want to.
squirrel, no one does need permission to create their own pre-packaged Vanilla distro, no. However, it is polite to see what Mark thinks about it no?
Posted: Wednesday, 29 August 2007 at 5:38PM
If a package *is* perfect for you, then you have the added knowledge that the addons have all been tested together and function well — for some people, this will be just what they need/want.
Now if we are talking tried and tested add-ons you have my attention. But shouldn't all add-ons be good-citizens? I don't see the link between compatible add-ons and packages.
Posted: Wednesday, 29 August 2007 at 5:47PM
This is as far as I'll take this part of the discussion as I'll feel we have a different view on this matter and that's fine, but there's no point trying to convince each other otherwise
I completely agree that all extensions should be , but as we all know, they're not. Mine have been the cause of some problems and so have many others. The link between compatible extensions and bundled packages is simply that some extension, by their very nature, conflict. Bundles will be guaranteed not to include conflicting extensions. That's all
Also, If someone is actually putting time and effort into putting together a bundle, they'll mention any conflicts between extensions that should work together to the extension authors and push a little harder. It's also possible that extension authors may feel a little more incentive to fix things if it looks like their extension is going to be put in a bundle because it's flattering
Also, some people will be interested (maybe) in putting together bundles who aren't necessarily interested in writing extensions, which will create more eyes to look at the problems and hopefully improve them.
Every add-on should be well tested, excellently documented and never conflict with anything else, but this isn't how things are or ever will be (not 100%), so anything that gives an incentive for this to happen has got to be good right?
Posted: Wednesday, 29 August 2007 at 7:30PM
I think that beta, alpha and stable extensions are a great idea.
As for lack of documentation - where it is nice to have it, I don't think it is necessary - I have recently been taking apart Jazzman's MultiRoles extension, which is largely undocumented, but it didn't take long for me to understand his logic, and I am well on my way to reaching my goal with it. Perhaps a lack of documentation weeds out the poor coders? (not that I am particularly good... maybe it weeds out the undedicated xD)
Adam.
Using Google code would allow collaboration. Also for those who customize add-ons, adding the modification from the author will simplify; they will just have to create a patch.
Wonder if there's a way to make it so you can have all your extensions under one project?
wiki/ vendor/ plugin1/ trunk/ tags/ branches/ plugin2/ trunk/ tags/ branches/ ...