Howdy folks, This issue came up yet again on the IRC channel today, and myself, jesusphreak and a couple of others did yet more brainstorming, partly recycling earlier topics and partly moving things forward even more. It started about here:
http://simon.bofh.ms/logger/django/2006/10/04/15/30/ and then the "meat" of the discussion--skipping me being dense about Amazon S3, and some rehashing of earlier arguments--here: http://simon.bofh.ms/logger/django/2006/10/04/16/09/ Please take the few minutes to read through that discussion, as I doubt I'll remember to touch on everything in this email. Before getting into specifics, I have two requests: Sean, if you're still listening, can you please contact me to negotiate transfer of the domain names? Even if I'm not the eventual recipient of the registration, I'd be glad to at least take them off your hands for the time being. Ian, if/when you get time to read this stuff over and examine your own code, I'd just like to know what it looks like so I know how much we'd be duplicating work already done. No pressure, though! :) I tend to like writing my own stuff anyways (then again I think we're all like that to some degree). The basic gist is as follows: * Set up a combination Trac farm / web-app directory system. * Each app/project is stored in a Trac instance, complete with all the Trac goodness that is a SVN repository, wiki, tickets, and etc. * Each app *also* has an entry in a front-end directory, which contains: * metadata about the app - author[s], categor(y|ies)/tags, etc * a direct package download - ideally, one automatically generated from a tagged release in the SVN repository * a link to the "backend" Trac instance for the project * a comments section for those who just want to leave a note about the app without really contributing full-fledged documentation to the Trac wiki * The directory front-end app will necessarily aggregate the info for all the apps, providing various views to the data (e.g. "list all blog-related apps, and snippets", "show recently added apps", etc). Such a setup would provide the following benefits: * Ease of use/accessibility: * For users, the ability for one-stop shopping for pluggable apps, via the package download. The fact that apps are stored in SVN doesn't matter - they will still be able to grab the latest version of the app, with access to older versions if desired (similar to Sourceforge) as a ZIP or TGZ or egg or whatever. * For developers who want to just donate a singular version of an app and never touch it again, and/or who are not SVN-literate, curators (or an automated system, theoretically) can take an archive file and create a new project out of it, with no further action on the part of the original dev. * For developers who are SVN-literate, it will be the same as any other SVN or CVS like setup--they will get the keys to their particular Trac kingdom and can go to town. * Flexibility in storage: some folks don't like the idea of having to use SVN to get access to things, others don't like the fact that flatfile-based storage is terrible at versioning and so forth. This approach mixes both so that folks who just want to grab a .zip, can, and those who want to get SVN access, can. * The usual *forge-like directory interface: unlike *just* a Trac farm, as I originally mentioned, this setup allows us to have a facade in front of the Trac farm, so that we get all the metadata and organization and searching that is useful for something like this. * Note that unlike actually using Sourceforge or Google Code, we can customize this setup to behave the way we want. Google Code does not provide even a tenth of the functionality Trac does, and Sourceforge does not allow us to specify our own metadata for organizational purposes (plus its interface is, IMHO, very cluttered). I am willing to start hosting something like this as soon as it can be built, on my own dinky little VPS; I recall that Marc Fargas and a few others also volunteered hosting. In that case, I'd still like to volunteer my time and what little expertise I have, to running/curating the thing, as well as writing the front-end or modifying what Ian has started with. Thoughts? Regards, Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
