Reorganizing development for scalability

[tschak909]

okay...so...you...tested and glanced at a smattering of version control systems....

I can understand the familiarity with svn, with cvs..

however, given the sheer size of the code, the number of individual sub-systems within this code, and the potential for so many people to be working on these subsystems independently, it is much easier to test individual ideas within git, or darcs, or bzr, than it is to deal with svn.

I know i'm pressing hard on this issue, but i want you all to seriously consider and weigh the pros and cons. SVN and CVS are badly suited for this project in the long run.

-Thom

[darrenmason]

Lets not turn this into a "this tool is better than that tool" debate.

If someone sets something up and it meets the requirements, then use it.

The system that Pluto had was effective (at least from a user/developer end).
Although the code changes are important, the metadata is just as much so and often coupled together anyway.
For instance, if I add a new Device Template and maybe a couple of new parameters to go with it, then I write C++ code to implement that - then in order to contribute that back to the community I need to be able to submit the code as well as the database delta. Pluto had this working with their sqlCVS product  (that is part of the code they developed)
Changes would still need to be accepted by admins I believe.

At a minimum we need to setup the same system that Pluto has, they may still be open to us using their servers for it and granted some form of access, since most changes will directly benefit them.

I am not sure that free server space or a limited hosting arrangement will meet the requirements, but I don't have experience setting this up which is why I have kept out of it. I have only posted this as a clarification of what I think our(mine?) requirements are.

regards
Darren

[eloy]

Hey Daniel,

I agree with everything you said in your first post in this thread. Your reputation precedes you (thanks for your leadership and contributions to MythTV) so I hope you become involved in this project as well since I am sure that'll make things improve a lot.

Cheers,

Eloy Paris.-

[chriss]

Hey Folks,

personally, I don't see why SVN shouldn't be suited to handle that code size (I'm using way bigger repositories at work), but I think this debate is kind of obsolete at this particular moment. This project is suffering from a missing repository and the goal should be to set up one ASAP! Since Pluto used SVN and (as far as I remember) several forum members, including Paul, stated that they are using SVN, I see no reasong why we shouldn't start with SVN - it's just the easiest way to get this rolling

I agree, that we should discuss the matter of the right repository - espacially if it turns out that SVN does not work as expected. But please, don't discuss everything until it's dead :/

just my 2 cents,
Chriss

[hari]

I agree, that we should discuss the matter of the right repository - espacially if it turns out that SVN does not work as expected. But please, don't discuss everything until it's dead :/

so true..

[danielk]

Status report...

I've had some problems contacting Paul and Razvan, but I'm moving ahead with setting up a server with svn + trac. I'll just start the repository using what sources we have. The server I'm setting up for the SVN is an old P3, but it has a gig of RAM and a 1000 GB per month of download bandwidth, this should be enough for SVN. If we want to replicate the kind of nightly build process Pluto uses we'll need a more powerful server for that. I think the server Paul has is sufficient for that purpose and it's probably best to keep SVN on a separate machine anyway. Plus, I don't think the nightly build scripts Pluto uses will work for us, the scripts seem to be pretty hard coded with IP addresses and the like right in the scripts, so we'll need to edit these for our purposes before we can use them.

[chriss]

Another status report

We have a repository along with trac up and running. Right now, it only cotains the 0704 sources (as shared via BitTorrent). Daniel is working on restoring the LinuxMCE history after the 0704 release, i.e. apply all patches that are needed for the two updates.
In the meantime I'm setting up a mailing list to be used as a development list later.

The repository will go public as soon as we are in sync with the current updates

[chewi]

Awesome !!! Great to hear that...
I'm really looking forward to getting things to work...

So now the question arrises; who will be maintainer of the repository and who will receive commit-rights ?
Will you, chriss, be the liaison in matters of maintaining the source within the svn ?
Will you also move the bugs from the mantis-bug-tracking to your trac or will the bug- and wiki-stuff be deactivated or will we start over with ne bug-tracking in trac or is there someone who will judge the bugs from mantis and dublicate the "real" bugs to the trac-system ?

best regards, Chewi

[DTS]

Another status report

In the meantime I'm setting up a mailing list to be used as a development list later.

Why are you setting up a mailing list? What are the benefits compared to a forum like this?

[danielk]

DTS, the main benefit of the mailing list is more instantaneous communication.

Chewi, for commit rights we'll give these to those that contribute patches to trac. Initially it will be me, Chris and Paul, when we've committed a few patches from someone that person will be asked if they want commit rights and the responsibility that comes with it. Chewi do you want to move tickets over from Mantis? Someone needs to do it...

[chewi]

If I said, I'd love to, I guess it would be a lie...
But besides that, I'm working on my thesis and must not get enganged with any further work... Hoping that the svn will not screw the thesis up for me...

So will the bugtracking be trac only or is trac going to be the tracker for "real" bugs ?

[chriss]

Chewi, we have not decided where to track bugs yet. I have to admit that I actually don't know Mantis. IMHO it is more useful to have all development related stuff in one place (which obviously would be Trac...). This would also include the developer documentation from the current wiki.
The nice thing about having all this stuff together is to use Trac's real features, like automatically linking between commits, tickets, wiki and so on.

Edit:

So will the bugtracking be trac only or is trac going to be the tracker for "real" bugs?

Short answer: IMO it should be only Trac. And it should only be real bugs that we are tracking. Feature requests and all other stuff can stay in the forums 

[countzer0]

danielk,

are you the same as the danielk mythtv dev?

[danielk]

are you the same as the danielk mythtv dev?

Yup. And one of the reasons I'm getting involved is because the MythTV integration needs a little loving.

I also have a drawer full of X10 stuff I haven't unpacked since I moved recently and I think Pluto is a much better option than MisterHouse or my own scary scripts for setting something reasonable up. And since I moved, I've been planning to set up an Asterisk server as well. LinuxMCE is the only thing that promises to get all my hardware to play nicely together. I think it's pretty close, some of the MythTV issues I see will take me 10 or 15 minutes to fix once we have source repository to work with and a build process that will let me test the changes easily.

BTW I've yet to get LinuxMCE to compile from the ground up, but I've gotten some parts of it to compile. One of the things we need to do early on is get a proper build process in place. Right now I'm trying to reconcile the LinuxMCE 0704 code and Pluto's svn. Then I'll set up the public repository and mailing list with Chriss' help, then we'll see where things go...

[eloy]

Yup. And one of the reasons I'm getting involved is because the MythTV integration needs a little loving.

Glad you're here Daniel! :-)

I think it's pretty close, some of the MythTV issues I see will take me 10 or 15 minutes to fix once we have source repository to work with and a build process that will let me test the changes easily.

Could you elaborate on what some of the MythTV integration issues are, as you see them? Just curious...

My own pet peeve is the inability to configure LinuxMCE to use an existing MythTV frontend - I have a frontend that has been recording since September 2004. It's rock solid and my family relies on it heavily. I am not willing to replace that with LinuxMCE, at least not in the foreseeable future.

I did manage to get a media station to use my existing backend but I think it required me to do something from the command line; can't remember the details.

Cheers,

Eloy.-