On 5/15/06, Greg Woodhouse <[EMAIL PROTECTED]> wrote:
--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > Since the primary intent of the VistA Community Meeting is to provide > opportunities for the members of the community to interact, what is > planned for the session is what you and other members of the > community > want in that session. Actually, I don't plan to attend this meeting.
[KSB] That's too bad. I was hoping to meet you after having corresponded and spoken on the phone for so long.
> Although I am not active in VistA development, > let me hazard some guesses about the issues that need to be hashed > out > at the meeting: > > 1. Who should have the authority to make decisions about what makes > it > into the repository? How does the community decide who is a > committer > and who is not? That's a good question, and I don't think I have a very good answer. The group should be small and consist of people with real expertise in the area for which they are responsible. To some extent, I think such groups have been somewhat self-selecting. But VistA is different from most development efforts in that there is an existing body of code at the start. More typically, there is a small group of developers who built the product in the first place, and they form the natural core of the group of committers.
[KSB] I agree with you. But we are agreeing on generalities, and my hope is that there will be enough critical mass of developers in Pittsburgh to work through the details.
> 2. What procedures should be followed with respect to checking things > into the repository? What criteria must be met before anything can > be > committed (design, code & test reviiew requirements, minimum test > coverage, functional documentation, etc.)? What are the commit > requirements (check-in comment requiring tracking number, reviewer';s > name, etc.)? I suspect developing a checklist wouldn't be too hard. The nastiest bit is likely tracking numbers because patches (in the VistA sense) only get sequence numbers after release. There is no formal mechanism for tracking changes to development versions of the software. However, I'd expect that the software used would provide this type of functionality.
[KSB] Yes, but this would be changes by the community to FOIA releases, so their changes will have a different series of tracking numbers from VA patches. The check list must reflect the software lifecycle of community changes to VistA. The interesting questions are things such as the level of formality required for code inspections (e.g., should 100% of the code be peer reviewed before check in?), who signs off that the criteria have been met, etc. None of this is rocket science, but the devil is in the details.
> 3. How do we manage non-code aspects of version control (e.g,, using > a > code repository to track deltas in the database schema)? If KIDS is used, then this shouldn't be a problem, because it automatically includes updates to the database schema. The tricky thing, though, is that when checking out code, you don't get a build definition, so it's not clear how to connect before and after versions. Fileman does include version numbers for files, but this has traqditionally been used for the package number (e.g., Kernel 8.0) not the build number (a concept that doesn't yet exist in VistA). If it were me, I'd add a new node to the DD (and to other components) and use it to track build numbers. This would involve patches to Kernel and Fileman at a minimum. It also presents a problem for compatibility with the standard (VA) version of VistA unless the same mechanism is adopted.
[KSB] Yes, but is KIDS the right tool outside the VA? [I can argue the case either way depending on whether the price of gas rounds to an even amount in cents or an odd amount.]] And, although the VA is comfortable with "VistA as a stream of patches" CIOs in the commercial world may not be. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
