Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Suggestion: "pre-made packages"

2»

Comments

  • 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.

    Posted: Wednesday, 29 August 2007 at 9:36AM

  • 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.

    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).
  • Flavors of vanilla, brilliant.
  • 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>

    Posted: Wednesday, 29 August 2007 at 5:38PM

  • 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.

    Posted: Wednesday, 29 August 2007 at 5:47PM

  • 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?
  • Fair 'nuff, the exercise seemed pointless to me but I see that something good might come of it as a by-product.

    Posted: Wednesday, 29 August 2007 at 7:30PM

  • 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)

    Adam.
  • edited August 2007
    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.
  • How many projects can you have at Google code? As many as you like? Can you bundle any number of extensions in on project?
  • I don't think there is any limit in the number of project you can have. The size limit for one project is 100 MB.
  • 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?
  • edited August 2007
    I think you can do what ever you want with your project svn:
    wiki/ vendor/ plugin1/ trunk/ tags/ branches/ plugin2/ trunk/ tags/ branches/ ...
This discussion has been closed.