(REVISED) PPCGeeks Unified ROM Project: Process Proposal - Page 2

Glossman · #11 (**permalink**) 02-21-2007, 01:36 PM

Quote:

Originally Posted by schettj

Version control would be nice, but unless you go with some web-based cvs it's not gonna work with the distributed development you're going to have here. I I don't think sourceforge is gonna work... hm Maybe it would.

We could check in the non-binary bits of the kitchen (no one should be patching binaries anyway) and that way we can track the changes/merge etc. I use CVS on my own kitchen (after getting burned myself making too many changes, and not having a known good version left

)

So... that should not be a legal issue with MS (no MS code) - setting up the tree would be a bit of work, but you should then be able to check it out and overlay it on top of a kitchen with binaries.

Schettj, I was contemplating your post here on my long drive into work. I understand the complexity and your concerns with distributed development, as it relates to version control. And I began thinking, "What's the simplest way that we could do this?", and here's what I came up with:

We have no shortage of people willing to help with this project. Why not get a volunteer to be the "keeper" of the code. Once the developers deliver their changes, it would be this person's job to merge these changes into the new build and track the changes. Since we're really only delivering files and registry changes, off-the-shelf tools are available to make this easier. This would require that person to have a developer's level expertise, but I think it's better than having to setup a source control server, which is overkill for what we're trying to do.

What do you think?

Glossman · #12 (**permalink**) 02-21-2007, 01:38 PM

Quote:

Originally Posted by Wideawake

R U serious? I must have missed that damn this new job and training. I've been so busy. I can provide a private forum for development were only users of a group could post in it. Guys interested in firing this project back up? Anyone? Letme know here or PM.
~Mike

A private forum would be great once work begins. For now, everything we do requires member input. Do you think a private forum can be setup by the end of next week?

**Wideawake** · #13 (**permalink**) 02-21-2007, 01:42 PM

One could be setup by the end of the day

Alwaysbelieve1 · #14 (**permalink**) 02-21-2007, 01:43 PM

I would love to be in on this in order to provide the community with only the best.

Glossman · #15 (**permalink**) 02-21-2007, 01:51 PM

Quote:

Originally Posted by Wideawake

One could be setup by the end of the day

Super cool! Set it up whenever you get a chance!

Thanks!

Glossman · #16 (**permalink**) 02-21-2007, 01:56 PM

Open question:

How do we select the ROM that will be the basis for our Unified ROM?

Do we select one that one of our gurus built? If so, how do we select it? Do we create one through collaboration of the developers on this project?

Should this question be in a separate thread?

psiphi · #17 (**permalink**) 02-21-2007, 02:13 PM

It seems reasonable to start with the ROM that has the least know bugs and go from there... I would suggest putting together a formal bug list for all the canidate ROMs, then cross checking each ROM with every list to see which ones work best or have code to be added later the the ROM selected to start with...

Glossman · #18 (**permalink**) 02-21-2007, 02:23 PM

Quote:

Originally Posted by psiphi

It seems reasonable to start with the ROM that has the least know bugs and go from there... I would suggest putting together a formal bug list for all the canidate ROMs, then cross checking each ROM with every list to see which ones work best or have code to be added later the the ROM selected to start with...

Agreed.

It looks like we need an evaluation process for all the available ROMs. The thing is, we may need to evaluate earlier versions of all the ROMs that are out there. I know from experience that some ROM got more buggy as they added functionality.

**luv2chill** · #19 (**permalink**) 02-21-2007, 02:48 PM

OK, rested and refreshed now.

Glossman, I'm a bit of an idealist and therefore not always pragmatic, but my humble suggestion is that we actually start with the beginning--either helmi_c's AKU 3.3 kitchen, or the very first AKU 3.5 kitchen (which I believe was created by ImCoKeMaN). The reason I say this is so that we can track (and therefore understand) exactly what fixes are going in and where they are going in. I think this will be important for bug tracking later.

So if ImCoKeMaN can tell us how he created the 3.5 kitchen from helmi_c's 3.3 one, then I suggest we "start over", in a sense, from that point and then re-incorporate each fix in the proper fashion.

Right now it is somewhat unclear which ROMs have which fixes in them, and there's been as yet no standard for incorporating said fixes. So colonel might have done it one way while saridnour might have done it a different way. I think each bug fix needs its own OEM package that is clearly identifiable, and includes the name of the person who discovered it (a living tribute of sorts

). That way if any of these fixes cause problems down the line we know where to find them.

I am glad that we are seeing so much support for this idea. We will make much more progress working together than separately.

**colonel** · #20 (**permalink**) 02-21-2007, 03:02 PM

Count me in too I guess

.

My initial thoughts are that a 3.3 version would be a better starting point. Yes, it is not the latest, but fixes and tweaks are more documented. It allows for more concentration on the processes and problems with creating a web based kitchen. Plus, it also allows for a usable version at a sooner time for the masses. 3.5 still has some monstrous issues such as the issues with IDTransfer and Live Search and their interaction with some of the GAC .dlls.

A secret forum? Nifty