After noticing that in the community, some people are seeking a central community 'hub' Feature Server via which to upload and share their Features, I bought featureservers.org and set up http://community.featureservers.org to do exactly that.
Of course, the design of Feature Server is such that Feature Servers can be 'distributed'. You can run your own Feature Server autonomously, and I think that's definitely the way to go. In my opinion, distributed models are often more powerful - consider Git/Bzr as opposed to SVN/CVS (albeit some of the reasons there are different).
On the other hand, some people simply don't want to run their own feature server for this purpose. The other thing is, for people to use your features, they need to know where to find it. I've already seen that the list on OpenAtrium's community hub, while small, may quickly become difficult to maintain, and people need to navigate through some documentation to find it.
This is why I set up this community feature server: it's one location, one URL, that people can come to to look for features. You can freely register and upload your own project and point people to the site. You can search for Features by tag or name.
As new projects are created, news of this is automatically tweeted to @featureserver on Twitter, so you can be alerted to new features that are created.
I also aggregate the RSS feeds of other distributed Feature Servers and will continue to maintain this list.
So, if you want to use it, it's there! That's all :)
P.S In case you aren't sick of me blowing this trumpet yet.. yes I built it in just moments with Drush Make and my Feature Server install profile, and maintain it with the Drush Make/Aegir/Git workflow :)
Thanks Mig
Sounds useful. I'll give it a try tomorrow. In the meantime, any ideas on how we should proceed with handling bug reports/feature requests?
Hi R.J, do you mean re: the
Hi R.J, do you mean re: the site itself or the features therein? I admit I didn't think of this when I began :) I think I'll try and work in CaseTracker there... and maybe fiddle with it to make it automatically create a CaseTracker project per feature.. watch this space
I think the case tracker for
I think the case tracker for a feature would best reside on the feature server hosting the feature. If it's not there, then it needs to be very apparent to people where the case tracker is for that feature. It would be ideal to have a case tracking solution baked into the Feature Server profile/.make/whatev.
Perhaps we should move this conversation to http://groups.drupal.org/packaging-deployment?
Right: I'm still not sure if
Right: I'm still not sure if you're talking about a feature having its own casetracker (makes sense) and/or casetracker being a dependency in my Feature Server install profile itself in a make file (also makes sense, and I use CaseTracker on my first featureserver features.mig5.net)
I think what I'll do is add CaseTracker to community.featureservers.org. Users that are uploading features to that 'hub' are free to also create a CaseTracker Project if they wish to accept bug reports and whatnot.
I don't think I want to add CaseTracker as a dependency of the FeatureServer install profile itself in its make file, as it feels optional.. remember that a Feature can simply contain a URL to a git server like github, and the user may wish to accept bug reports in github's issue tracker (what a horrible thing that is), and instead treat the feature server as more of a showcase where one can grab the latest version at any time (consider http://code.developmentseed.org)
Sure, we can take this discussion to g.d.o. Or even make a forum topic on community.featureservers.org :)
Cheers for the ideas! I'll add casetracker to the hub for sure in any case.
Post new comment