Why so many Common Libraries?

[mkenyon2]

Never worked on an open-source project/code, but this would be one I'd love to work with. (Dabbled with a plugin myself.)

I know the base API (sub's code) is not open-source, and that's fine. But I agree, it would be nice to have an open-source set-up for plugin development. There are several plugins and utilities that have similar functionality and features, and I'm sure we'd love to see some of them get merged.

As far as the process of publishing finished ( or at least stable) code, this site might have some ideas:
http://www.opensource.org/faq

Also, Slashdot has a post about managing open source:
http://ask.slashdot.org/article.pl?sid=00/05/29/1715203

As far as tracking parts of this, I have a webserver, with 90% uptime (probably better than that, it's on an APC UPS.) I could set up something like TRAC (http://trac.edgewall.org/wiki/TracGuide) that offers Subversion support. I don't think I'd be a good code reviewer, but perhaps some of the long time members could take up that role.

Just throwing it out there.

[scb147]

I'd think for a project this size, either sourceforge.net or code.google.com are the best ways to go. They have version tracking, bug reporting, etc.

I'd think some of the seasoned GBPVR plugin writers would be the ultimate authority figures.

Things will be messy for a while, but I think in the long run this would be the best, for GBPVR, the plugin writers and the users.

My 2 cents, no refunds

[McBainUK]

I'd think for a project this size, either sourceforge.net or code.google.com are the best ways to go. They have version tracking, bug reporting, etc.

I agree, it makes sense to have it on a universally accessible site rather than a forum member's own box/site.

Who's willing to be the sourceforge guineapig? JavaWiz?

[fla]

Jorm and KingArgyle have had XSuite on sourceforge for years. I've used it pretty extensively and it works great.

[whurlston]

I agree, it makes sense to have it on a universally accessible site rather than a forum member's own box/site.

I agree with this as well. I have project collaboration software that can be installed on EPGTools but it's nothing like SourceForge. The only reason not to go that route would be if we wanted to limit it to the GBPVR plugin devs by having a (semi-)private setup.

I'd be willing to share code as well (I probably stole it all from the other devs here anyway). I've never actually worked in a collaboration setup before either though, I guess we'll all be getting a crash course.

[McBainUK]

Jorm and KingArgyle have had XSuite on sourceforge for years. I've used it pretty extensively and it works great.

Any experience of setting up a sourceforge project? Think we could do with a kick start. You seem to be the king of maintainers around here

edit: a few GB-PVR related projects on sourceforge already: http://sourceforge.net/search/?type_of_s...ords=gbpvr
edit2: and one project on google code: http://code.google.com/p/musiclibraryplugin/

[herrmannj]

Any experience of setting up a sourceforge project?

Its quite easy, you have to create an sourceforge account if you not allready have one. then you enter a project description. it takes about two days for the sourceforge staff to view and approve. after that you can add other devs (which need their own free account).

svn must be activated in a seperate page.

voila!- done!

joerg

[JavaWiz]

I am taking a look at both Google and SourceForge. Does anyone have any preference? Overall, they both seem to provide similar functionality.



I am more concerned on the process of managing the code and releases than the code repository. Once the code is put onto a repository, and is available for all,

• How do we decide what features make it into the next version? (ie. commitee, dictator,...)
  
• How do we insure good coding practices and proper documentation for new functions/features? (code reviews?)
  
• Who is responsible (or how) for validation testing of a release version.
  
• How do we manage patches between releases?
  
• ... (others?)
  

I also think we need to setup some rules (maybe on the Wiki) describing:

• Our approach to managing the common code. How changes will be included in the next version. (ie process for deciding on what is in a release).
  
• A clear definition of each common module, its scope/purpose. Somehow we need to insure each module remains true to its purpose and does not get bloated with code outside if it's functionality. BTW: the current WizTools probably should be repackaged as one of the first steps to follow above guidelines.
  
• Some loose coding guidelines/best practices.
  • Documentation in the code (to insure Sandcastle will generate docs for any new changes).
    
  • Naming conventions. etc...
    
  • others???
    

I don't want to get too anal about this, just want to make sure we have thought it thru and improve rather than complicate our environment.

[herrmannj]

absolute agree !

Google and SourceForge

personal view: sourceforge

How do we decide what features make it into the next version? (ie. commitee, dictator,...)

lets talk about new features in this forum. Some People may request functions, some people may want to add new functions. Before that a (short) open discussion makes sense to me. So we can see if the functions already can be done with the existing set of functions and we can discuss how the new functions should/may be implemented.

How do we insure good coding practices and proper documentation for new functions/features? (code reviews?)

because anybody who is willing may optimize the code that is written, there should be a process of continuous optimize the code. if we decide a svn based approach (either google or sourceforge) it will be possible to revert unwanted changes at any time (just like wikipedia works).

proper ducumentation is up to the writer (!!!) all changes should be documented in the code with date/author and so on.

Who is responsible (or how) for validation testing of a release version.

I wouldn't take special care. whoever add new features had announced that in this forum and probably add that features whilst developing a new plugin. So the new build will be tested with that plugin. Problems should be reported here. If there are issues, anybody is free to help fix it, the author will be the first who wants to do that. As a general rule: new releases have to be compatible to existing version under all circumstances !

If there are no issues (after say one month testing in the wild) than it is the next release version.

A clear definition of each common module, its scope/purpose. Somehow we need to insure each module remains true to its purpose and does not get bloated with code outside if it's functionality. BTW: the current WizTools probably should be repackaged as one of the first steps to follow above guidelines.

very important.

• UI components (???)
  
• UI helper functions (???)
  .... (???)
  

Some loose coding guidelines/best practices.

should we start a wiki page to write down that rules ? I think so.

Joerg

[mkenyon2]

Suggestions:
Perhaps in the Developers forum, we can have a sub forum, 'Common Controls'

In there, we could have threads such as:
Feature/Function request
Current Beta (.012)
Current Release (.011)

And then people could have a nice location to post. This could be listed on the forums.

It would be simple enough to start with, and could be expanded easily. As we move from one release to another, we could close the older threads.