--- "[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. > 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. > > 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. > > 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. > > I am sure there are many more questions of this ilk that can be > asked. No doubt. > > -- Bhaskar > === Gregory Woodhouse <[EMAIL PROTECTED]> Metaphors be with you. ------------------------------------------------------- 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&kid=120709&bid=263057&dat=121642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
