The unRAID developer community.

[WeeboTech]

We have this ever growing developer community.

Threads of various subject matter, scripts pasted to the board, or uploaded to messages.

 

I've started releasing my code on google code considering it is free.

 

I think we still need some sort of Jump page or community blog to help provide a unified interface.

 

Let's open the discuission towards a unified approach.

[Joe L.]

We have this ever growing developer community.

Threads of various subject matter, scripts pasted to the board, or uploaded to messages.

 

I've started releasing my code on google code considering it is free.

 

I think we still need some sort of Jump page or community blog to help provide a unified interface.

 

Let's open the discuission towards a unified approach.

Sounds good to me...  It would be a shame to not put all the collective talent and experience to work. 

 

The actual specific "repository" is not significant... longevity and cost are certainly a factor.  I like google.code, as opposed to space on someone's server, since it is unlikely to go away.  I have plenty of space on servers I administer, and space is fairly cheap..  but it really should not be on an individual's server.

 

unmenu.awk is so small compared to some other projects it has easily fit in .zip attachments to posts... clearly, others like BubbaRAID cannot.  A unified approach is far better.  Whatever we use, the repository must be able to handle everything from a single shell script up to a full distribution of Slackware with development tools and unRAID drivers compiled in.  The only option I can think of better (in some ways) than the google.code repository is if Tom were to make space on the server he pays for... There is a downside there... if Tom ever retires, and no longer supports unRAID, the source repository might be lost when he makes the final payment to his service provider.  I'd expect google.code to live on long after I'm ready to retire.

 

Shall we partition Tom for a new/different sub-forum for unRAID developers/hackers?  Or do we need a few well-labeled threads and some items in the wiki?  Discussion anyone???

 

I'll start the discussion with this.. google.code says it allows me a max of 10 lifetime projects...  I can easily envision more then 10 extensions to unRAID.  I can easily envision my use of it for more than unRAID related code.  I see that unraid-powerdown is one google.code project.  Should it be by itself?  Or should there be a top level project "unraid-extensions", or "unraid-projects" ? and have all the other projects under it.  Should we all share one project, or group multiple projects under one project name per developer, or lead-developer.

 

I don't know how the administration of such a hierarchy works under google.code.  Perhaps the only easy way is to have separate projects all named similarly.  unraid-unmenu, unraid-email, unraid-powerdown, unraid-bubba-raid   Each managed by their respective lead developer.  Thoughts.

 

Joe L.

[WeeboTech]

I don't know how the administration of such a hierarchy works under google.code.  Perhaps the only easy way is to have separate projects all named similarly.  unraid-unmenu, unraid-email, unraid-powerdown, unraid-bubba-raid Huh  Each managed by their respective lead developer.  Thoughts.

 

This was how I was envisioning it from the start. We could have a google project for unRAID itself, then on that Wiki point to other projects.

This project would be bare and informational with pointers to the necessary limetech-pages and each google code's project related to it.

 

Or we could use the Limitech wiki as a jump page to each of the project's pages.

 

From what I was looking it, google code even has svn access. So I may move my source code there and use svn for source control.

 

 

A more unified approach is a website area either here or one we chip in for.

With that we can have a blog, news, forum uploads, downloads...

 

I think as a starting point, Petition Tom for a subforum, although user customizations fits, so do we need another forum?

For each unraid addition, setup a google code project.

 

That is.... unless we have a better way of doing this through a unified site.  I'm open.

 

[NAS]

sounds like were going the google code route. Should i shutdown the addons site? (actually i would allocate it to something else since ive already paid for it).

 

No biggy whatever works suits me thats all it ever intended to do anyway.

 

I say this with no offence meant yada yada but Toms not around enough to rely on him being part of the community. What i mean is if we get things like subforums etc and we then need something else it could take weeks to sort out or alternatively there could be a difference of opinion. We also should not be running forums without superuser powers to deal with the trolls etc that will inevitably turn up. Theres also the matter of official and unoffiical asplit nd that was hard enough to quantify on the wiki (and we never really all agreed on the route we took anyway). I say if this is seriously getting done then make it completely standalone.

 

I also think all projects should be under one install/group with default settings of disabled i.e. a user would install the unraid addons suite and activate the specific features they want. If we ever get to the point where the addons are bigger than the OS were doing something wrong anyway. (I too have no clue how the hiearchy works which would be a key factor). Also a design fundamental should be to aim the addons to the level of the official unRAID users. Going the one mega project route helps ensure continuity and ease for the end users. If we have lots of projects we will end up right back where we started.

 

 

[WeeboTech]

Should i shutdown the addons site? (actually i would allocate it to something else since ive already paid for it).

 

I thought it was a free site. Can you run cgi or php on it? Right not it's a single developer storage/jump point.

I figured google code would allow developers to handle their own code.

The issue is really having more then one person with access to a jump point, repository, etc, etc.

The way I see it, no matter what happens, we would need to provide code to the central manager which means we have to post and manage it somewhere.

 

Personally I was considering software like this

http://www.geeklog.net/

 

[NAS]

Should i shutdown the addons site? (actually i would allocate it to something else since ive already paid for it).

 

I thought it was a free site. Can you run cgi or php on it?

 

No its a proper paid up account that anything can run on. The reason i never said this before is that I didn't want to make people feel obliged to use it. On its own merits the repo has been a bit of a failure. Interest has been zero. Google code sparked more interest in one post. So what i would suggest is that we keep the ball rolling and use Google Code. If we out grow it capacity or feature wise we can take the lessons learned and start something dedicated rather than trying to predict what we need.

 

Until then we can use addons really for what it was envisioned as a bandwidth using file delivery dumping ground. I think this is a far better idea as it would take some time even to make it on par feature wise with google code and perhaps other things like a place to allow users to dump logs etc

 

If we need forums etc and google code wont suffice (no clue yet what it can be used for) then we should look at sourceforge which allows direct hosting as well.

 

Im keen though to keep at least most of the little projects encompased in one big project. For instance i have a couple of simple scripts that some users would like but i dont (as you know) have the time to work out how to make them slackware installables. You already know how to do this so seperation of workload and skill sets would allow users to create clever little command lines and have them delivered as one contiguous package. I feel strongly that if we start having lots of packages and projects we will end up with 30 different ways of diong things and users in complete confusions.

[jimwhite]

some of us  are already there.... 

 

[WeeboTech]

No its a proper paid up account that anything can run on. The reason i never said this before is that I didn't want to make people feel obliged to use it. On its own merits the repo has been a bit of a failure. Interest has been zero. Google code sparked more interest in one post. So what i would suggest is that we keep the ball rolling and use Google Code. If we out grow it capacity or feature wise we can take the lessons learned and start something dedicated rather than trying to predict what we need.

 

I apologize about my pushing towards goggle code.

I felt it was a good compromise because it allows authors to manage their own code through an environment conducive to that.

 

Can you explain what was actually paid for with the addon site you created.

I see yi.org as a Dynamic DNS jump point, but where is the hosting provider and what facilities exist?

I still feel we need a portal or jump point. (unless everything unraid related on google code starts out with unraid_)

I posted a link to possible code to use as a jump point or portal. From there we can discuss or provide alternatives.

 

I'm not in totally agreement that everything has to be so tightly knit in one all inclusive package.

In fact I think that complicates things unless there is a single portal, management system and A unified goal.

Currently, I see a collection of gifted people creating addons to satisfy gaps.

These gaps should be identified and then ideas formulated and chosen/delegated.

 

A unified method of package defintion, installation, and acquisition is needed.

Again, this was why I lobbied for curl. (more votes to Tom please).

Curl would allow us a single access method for automated downloading of files needed to accomplish the tasks.

 

If we use a unified package management system, then the rest follows,  allowing people to access, install and manage the addons.

 

I think the unmenu.awk satisfies wjat is needed quite close.

I have not installed it yet, but from what I see it's answered allot of what is needed.

 

 

On its own merits the repo has been a bit of a failure.

 

I think if people have to contact a single person to make something available it's going to be more difficult to move in that direction.

If there was a place where we could register, upload directly and then make a notification then that might work.

 

Google code allows us to manage source, make it available, provide news, updates, and instructions for usage.

 

So what about using the jump point/portal with software allowing members of a developer community to contribute directly?

The Wiki worked out well. A Blog hosted somewhere might work well.  I ghought the geeklog.net sofrware would have sufficed.

I'm open to other suggestions.

 

[RobJ]

I personally think that unified storage, while a bit less confusing, is not near as important as a unified presentation and access.  After all, storage is just a URL to the user.

 

So I moved the old and almost unused Add On Scripts wiki page to UnRAID Add Ons, to make it a more generalized page for describing and linking all add ons, projects and scripts.  It's just a beginning, to get it started, and no one is required to use it.  I won't be offended if there are better ideas and ways to do it.  It's mainly a few stubbed entries for demonstration, in a bulleted (?) style, and please feel free to radically change both the overall style and formatting, as well as the detail.

 

The other thing that would greatly unify and simplify these add ons, is if we agree that the Unmenu Package Manager (and any future replacement) is the recommended way to install all add ons.  It would be nice to see full documentation for the package conf file (hint hint Joe!), and agree to make it the standard.  In other words, I fully agree with WeeboTech (once I realized he had basically already said the same thing!).

[Joe L.]

The other thing that would greatly unify and simplify these add ons, is if we agree that the Unmenu Package Manager (and any future replacement) is the recommended way to install all add ons.  It would be nice to see full documentation for the package conf file (hint hint Joe!), and agree to make it the standard.  In other words, I fully agree with WeeboTech (once I realized he had basically already said the same thing!).

BubbaQ had indicated interest in using the exact same package.conf file format in a bubbaRAID package manager as the in package manager I wrote for unmenu.awk, so in that respect, the package.conf file has support from others besides myself.  (He indicated he would be putting together a "package manager" for bubbaRAID that could use the same files. )

 

I would say the format is still open for change, although it is been used for a quite a few packages... there is a possibility I'd need to add a field in it for something special I've not considered or needed yet.

 

I'll put the package.conf file-format description in the unmenu.awk thread.

 

Joe L.

 

 

 

 

[Joe L.]

I'll put the package.conf file-format description in the unmenu.awk thread.

 

Joe L.

I put the package manager configuration file description in the WiKi. 

http://lime-technology.com/wiki/index.php?title=UnMENU_documentation#unmenu_package_manager_package.conf'>http://lime-technology.com/wiki/index.php?title=UnMENU_documentation#unmenu_package_manager_package.conf

 

There is a lot remaining for me to document about unmenu.awk.  The wiki will allow others (hint hint) to help with wording, etc.

I did put an outline for most of the documentation in place.  You can find it here: http://lime-technology.com/wiki/index.php?title=UnMENU_documentation

 

If you see an item I missed in putting together the documentation outline, please add it.  If you see where wording can be made more clear, go for it.

 

Joe L.

PS.

I'll also add a note to the unmenu.awk thread pointing to the documentation.

 

[josetann]

I'm just throwing this out there, not trying to steer anybody in any particular direction.

 

I have multiple dedicated servers.  One has no restriction on bandwidth.  I have no problem pushing out lots of data, in fact I have two webservers running on it; one is apache for regular pages, another is lean and mean just to push out images and file downloads.  Anyways...

 

If you're looking for a place to store large-ish files, or just a place that isn't going to limit the amount of bandwidth you use, then I can help out.  If you'd like a dedicated section on my site (wiki, subforum on my main forums, etc.), that's fine too.  If you want your own domain name and the ability to create multiple users, then I have another server that could be used, but it doesn't have unlimited bandwidth (still has a pretty high limit though).  Basically, the server with tons of bandwidth is dedicated to my main site, and if that isn't good enough I can set up an account on one of the servers I use to host other people's sites.

 

Just to give you an idea, it'd be no problem if you wanted to host vmware images that were gigs in size, files downloaded by thousands a day (would be nice to see the server stressed a tiny bit), etc.  I could even set up svn if you guys wanted, but perhaps google or sourceforge would be better for code development, and somewhere else to host stable releases.