View Single Post
  #8 (permalink)  
Old 02-24-2007, 02:53 PM
Sogarth's Avatar
Sogarth
PPCGeeks Regular
Offline
 
Join Date: Jan 2007
Posts: 129
Reputation: 0
Sogarth is a n00b
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
I mostly agree with luv2chill, but with a slightly different perspective on some of the ideas here.

Quote:
Originally Posted by luv2chill
I say step even further back than 1.1. Let us start with the helmi 3.3 kitchen and completely re-create AKU 3.5, fully documenting every change made along the way. This way we have a complete "cookbook" (sorry) for how that kitchen was created, which folders are affected by which hacks/fixes, and a more standardized process for implementing said hacks/fixes.
Nothing to comment on here.... Starting with the only package that's completely verifiable as not having had undue modifications from the beginning would probably give us the cleanest start. Besides of which, all of the fixes have happened recently enough that we probably remember what changes we would need to duplicate.

Quote:
Originally Posted by luv2chill
For one (and I've said this before), I strongly suggest that nothing goes into/out of the OS and LOC folders unless it won't work as an OEM package. By doing this we make the changes much easier to manage for everyone and easier to keep track of (because they're in one place). If one of our fixes turns out to cause problems down the line it is easy to just remove that folder from OEM as opposed to having to hunt down individual files/modules inside OS or LOC and trying to replace them from an old kitchen. It just makes for a cleaner kitchen (sorry again).

There may very well be some fixes that must go in OS/LOC because they won't work properly in OEM or would take up much too much space otherwise. In those cases so long as we all agree that they're necessary for the base kitchen and are thoroughly tested they can go into OS/LOC.
This, I don't know if I would agree with in quite this way. I feel that any modifications we make to files in the OS/LOC directories should stay in the OS/LOC directories, since that's where they came from in the first place. Case in point: I would think that any of the changes we're making to the GAC_* .NET CF .dlls should stay in exactly the same directory. Outside of that, I don't think we need to worry about this problem until we hit the customization phase, and the majority of that will happen in OEM anyways. I'll leave aside those customizations that will need to alter OS/LOC for the moment....

Quote:
Originally Posted by luv2chill
Anyway those are just some thoughts. Call me an idealist (it's true), but even if it means a bit more work, I think we should truly start from the beginning and properly implement and document each and every change we make to get it to the proper 3.5 base kitchen. Then that info can go into the wiki for all to see.
Wiki? Bah, wiki.

Honestly? All changes should probably go through a source control system (yes, I'm bringing that up now). That would ensure that we would have a good history, file by file or change by change, and everything would end up being documented in a sense. It would give us the ability to know exactly what happened, who did it, and why.