Yeah but i only just realised google code does this and im always submitting bugs. There would be an element of user training but it could work.

 

This is the best example of it being implemented and working that I know off

 

http://feature.astaro.com/

 

That is a very good example.  I'm not so sure limetech has the time to do something like that.

 

On another note I looked for an SMF plugin and found this.

 

http://custom.simplemachines.org/mods/index.php?mod=1890

 

It allows voting on a post.

If there were a feature request board that had this enabled and you set the bad post threshold really high -1000 then you would see popularity of the feature request by the "respect: #".

 

Doesn't mean accepted or anything. Just an idea.

 

I've seen the googlecode issue tracking in use, that would work for issues, not sure how good it will be for feature requests.

The key to voting is that we will need some mods with powers to close. If something is closed via a mod then we shouldnt have to wait or even expect limetech to do something.

 

This is a key point alot of this will need run like a full on open source project with staff, helper, users etc

 

Done right it will be win win for limetech and users alike.

 

When i raised this my main focus was that I have always maintained that a forum is a good place for chat and certain types of support but its not that brilliant for anything else. And when V5 comes there will be lots and lots of other things we will want to do so best to deal with this as a community.

 

Perhaps a cheap ass domain and hosting and extract all of this from Limetechs workload.?

Perhaps a cheap ass domain and hosting and extract all of this from Limetechs workload.?

I could see this for the plugin's & addons, but not for the unRAID core.

I suggested use of google code a while back for the developer addons.

A quick search on google code shows it's not to be as popular as I hoped.

In any case, I'm open and supportive of either direction.

 

Having all the developed plugins etc in the one place..instead of a google code project per item or developer would help.

 

That might be the case already, but I'm sure last I looked it wasn't. Bring them all together and it would be much better.

Warning:  Mission Creep.

 

Plug-in management will likely come from the plug-in developers.  Look at the NMT community software (popcorn hour) for example.  Plug-in developers developed their own management and installation platform.

 

A bug tracking system was suggested ... let's stay on topic.

 

I see what your saying but to be exact a bug and feature tracker was what was originally proposed.

 

No doubt bug tracking is the most important but even those projects have evolved way beyond those bounds. Just look at what trac can do for instance.

 

Discuss what could be done.

Decide what should be done.

Do it.

 

At this stage it costs nothing to discuss

 

 

Warning:  Mission Creep.

A bug tracking system was suggested ... let's stay on topic.

 

LOL!  Thanks!.

 

I see what your saying but to be exact a bug and feature tracker was what was originally proposed.

 

No doubt bug tracking is the most important but even those projects have evolved way beyond those bounds. Just look at what trac can do for instance.

 

I'm liking trac the more I look at it.

Seems to support bugs/enhancement/tasks and allows attaching files.

Looks like XMBC uses

http://trac.xbmc.org/

I think for this project, seeing as it is really one developer working on it and not a massive team like XBMC (or others), Google Code would probably be the best idea.

 

It's easy to setup, there's no maintenance on the software, nothing to configure, just setup and go. Most everyone has a google accounts, it's easy to vote on features, you can add attachments, comments, etc. You can also set versions, "types" (feature, bug, etc.)..

 

 

 

 

I think for this project, seeing as it is really one developer working on it and not a massive team like XBMC (or others), Google Code would probably be the best idea.

But, that is not going to be true with the plug-in archeticture being developed...  There will be a number of us involved.. possible less than 6 or 8, but not just a single developer.

It's easy to setup, there's no maintenance on the software, nothing to configure, just setup and go. Most everyone has a google accounts, it's easy to vote on features, you can add attachments, comments, etc. You can also set versions, "types" (feature, bug, etc.)..

 

I like "trac" more than the others so far...

 

Joe L.

But, that is not going to be true with the plug-in archeticture being developed...  There will be a number of us involved.. possible less than 6 or 8, but not just a single developer.

 

...

 

I like "trac" more than the others so far...

 

Joe L.

 

I agree with Bubba's comment on page #2 .. Tom requested suggestions for a bug tracking system for unRAID. I think it's a bit off-topic to talk about something that's all encompassing and suitable for plugin developers as well. While I understand your point of view, if you look at quite a few other projects out there that use bug tracking software, 3rd party plugins don't necessarily get included in their tracking system. That's not to say someone here couldn't start a trac or other system for plugin/3rd party developers, but I think for a system specifically for unRAID, Google Code would fit the bill.

 

My $0.02

I think we should first focus on a bug tracking system for unRAID, and later on bug tracking system for the plugin developers. So i think Google Code is the way to go...

I think it is short sighted to focus on one specific area when the tools that we are choosing between also cover the areas we will want later on as well.

 

This approach could result in us needing a complete project re-tool later.

 

As for trac here is the stuff redmine doers that trac wants to do

 

http://trac.edgewall.org/wiki/RedMine

 

trac definitely seems to be running ahead

 

 

Hmm, probably your right NAS. It is more work to setup, but doing it twice is not a option. I think unRAID bug tracker and the third party developers bug tracker should be separated. I will check out your link. The guy over at transmissionbt.com also use trac.

 

 

I think it is short sighted to focus on one specific area when the tools that we are choosing between also cover the areas we will want later on as well.

 

This approach could result in us needing a complete project re-tool later.

 

As for trac here is the stuff redmine doers that trac wants to do

 

http://trac.edgewall.org/wiki/RedMine

 

trac definitely seems to be running ahead

 

 

I don't see why each plugin developer/maintainer can't use their own google code account.

I plan to stay with google code for my plugins/scripts/binaries.

My stuff is small potatoes at the current time, but I have some big plans soon.

 

As someone mentioned, unRAID itself needs a bug tracking/feature request system.

The forum doesn't serve well for this purpose anymore.

 

 

One thing trac does is allow bugs and features to be tagged with a predefined set of project codes.

 

This means someone could easily mark a bug as unRAID or Plugin X. If they get it wrong the admins can change it for them. In essence having many bug tracs is just as easy as one.

 

Similarly you can tag a feature request with the same set of project codes.

 

It does not allow voting natively but 2 minutes on google found a mod to do it http://trac-hacks.org/wiki/VotePlugin

 

Lastly XBMC whom use trac managed to make the forum credentials work with trac. Personally i think this is a critical feature if we go this route as it increases the likely hood of users posting bugs by making it much slicker for them to login.

 

Using XBMC as an example you can also do milestones

 

http://trac.xbmc.org/roadmap

 

this really is a nice to have as well as it gives users visibilty of progress

 

 

I don't see why each plugin developer/maintainer can't use their own google code account.

 

absolutely true...

 

One thing trac does is allow bugs and features to be tagged with a predefined set of project codes.

 

This means someone could easily mark a bug as unRAID or Plugin X. If they get it wrong the admins can change it for them. In essence having many bug tracs is just as easy as one.

 

Similarly you can tag a feature request with the same set of project codes.

 

I think this solution is way easier to track everything.

 

 

If you want a easy way then use Google code. If you want a more advanced solution use Trac. Thats what i think...

 

 

I don't see why each plugin developer/maintainer can't use their own google code account.

I plan to stay with google code for my plugins/scripts/binaries.

My stuff is small potatoes at the current time, but I have some big plans soon.

 

This keeps all plugins and addons scattered about. Pulling them altogether centrally would be great. Alongside whatever unraid uses - even better, but just having *a* definitive repository somewhere of all the third party addons would be useful.

 

Otherwise you have to trawl the forums to find what you need and then find where they are hosted. As opposed to just having a one stop shop for it all.

 

This could entirely be done right now if there was a consensus.

 

You might think your stuff is small potatoes but lots of people find it useful, and lots of small potatoes in the same place adds up to..err..a big potato field. Or something

 

I guess I will put in my 2 cent...

 

With the advent of the plugin architecture I think there are going to be more and more things that are developed for unRAID.  It would be nice, but not necessary, to include the plugins.  Using something like Trac i think is the way to go and I think it is a more complete solution than google code at this point in time (and probably always will be).  The plugin Devs can keep there code hosting on google code but all the issues, bugs, enhancements, etc could be tracked through Trac which would be hosted by Limetech.

 

One central place for everything will go a long way to help get thing moving and keep it moving.

 

So, in summary:

Trac for Limetech use with core unRAID

Trac for issue tracking with core unRAID and plugins

 

 

 

If Limetech does not want to set up Trac then google code might be the next best thing.

Using XBMC as an example you can also do milestones

Boy, you are a dreamer!  

 

indeed I am

 

Build it and they will come

 

I am all for keeping it central. XBMC started with plugins and skins ebing all over the shop. They just spent 3 months recoding because that quickly became unmaintanable and you ended up with no one able to find anything and when you did it was often no longer hosted or applicable to an old version.

 

Also not all coders are made equally. having one repo allows other coders to fix mistakes or at the very least deprecate things.

 

 

Put it this way look at the effort people have went to when unRAID essentially didnt really support other developers. Now that it will make it easy for third parties i truely expect there to be a trcikle ending in a flood. A modecum of central control should be maintained for qualtiy control. After all nothing else matters on a NAS

Using XBMC as an example you can also do milestones

Boy, you are a dreamer!  

Gotta dream big.  I dream in Infrared  (Queensryche).

 

Actually slightly off topic but funny. There are times when I dream I'm programming and see the code in my dream. at times I would play with hemi-sync go into theta state and litterally write the program in a semi-dream state on the way to work, Once I was at work all I had to do was churn it out in physical reality.

 

Back on topic. I'm not against Trac. In fact, I'm all for it. It seems there are many people voting towards it.

In the meantime I'm going to stay on google code until I see more progress and decide later.

 

This could entirely be done right now if there was a consensus.

I don't know if a consensus is the only thing needed. This all takes time and money. Limetech seems quite busy.

 

By all means, continue the discussion, It is educational and a positive direction for the community. Perhaps if there are enough contributors this can flourish further.

 

With all of the recommended tracking software, is it worthwhile to post a poll?

I guess I will put in my 2 cent...

 

With the advent of the plugin architecture I think there are going to be more and more things that are developed for unRAID.  It would be nice, but not necessary, to include the plugins.  Using something like Trac i think is the way to go and I think it is a more complete solution than google code at this point in time (and probably always will be).  The plugin Devs can keep there code hosting on google code but all the issues, bugs, enhancements, etc could be tracked through Trac which would be hosted by Limetech.

 

One central place for everything will go a long way to help get thing moving and keep it moving.

 

So, in summary:

Trac for Limetech use with core unRAID

Trac for issue tracking with core unRAID and plugins

 

 

 

If Limetech does not want to set up Trac then google code might be the next best thing.

The issue I see is with a central shared repository for programs is control.    So far, Tom has not relinquished any control of the forum, and barely in the non-user contributed portion of the wiki.  Somehow, I cannot see that changing unless he has a fundimental change of heart.

 

As a developer, I want to have full control of the code I write, and not have to rely on Tom to manage the deployment of anything I write.  For that reason, I use google code for unMENU.  I also use an alternative ID when accessing my google code repository, to eliminate issues with it colliding with my personal stuff.

 

I do not plan on changing at this time and would need convincing it is in the better interest to migrate it.  I would have no issue using a shared bug tracking system.  It can have a page with links to everything else.

 

Joe L.

The issue I see is with a central shared repository for programs is control.    So far, Tom has not relinquished any control of the forum, and barely in the non-user contributed portion of the wiki.   Somehow, I cannot see that changing unless he has a fundimental change of heart.

 

As a developer, I want to have full control of the code I write, and not have to rely on Tom to manage the deployment of anything I write.  For that reason, I use google code for unMENU.  I also use an alternative ID when accessing my google code repository, to eliminate issues with it colliding with my personal stuff.

 

I do not plan on changing at this time and would need convincing it is in the better interest to migrate it.   I would have no issue using a shared bug tracking system.  It can have a page with links to everything else.

 

Joe L.

 

Which I fully understand and is the reason why i suggested the the issue tracking and enhancement related parts of the plugins should be tracked on Trac which will be under Limetech.  GoogleCode can and probably should be used for the code hosting for the plugins.  The setup you currently have for unmenu is quite nice and very useful (just did another install, first one from scratch since the unmenu_install was implemented).  The install process the way you have it set up is great. All you really need now is some way to plug into the main unRAID GUI to make a button that a user can push to install unmenu and get it running.

 

There I go... off topic again...

[offtopic]

I notice there are XBMC users over here. I want to build/buy a XBMC machine so suggestions are very welcome. Love to talk to you guys!

[/offtopic]

 

With all of the recommended tracking software, is it worthwhile to post a poll?

 

Good idea...did take a look at the trac software. Looks good.