Hi Robert, The process in general sounds like something close to what we want, although I am a bit uneasy about opening a new branch for every single modification (unless I missed the authors intent). I think we might want to moderate this a bit, especially while our "specs" are undergoing development, or for fixes to relatively obvious errors. For example, do we really want an open branch, check out, modify, test, check in, review, merge branch sequence because someone renamed a variable to meet a coding standard, or adjusted a counter by 1 to fix a logical error?
Jeff > From: Robert Lupton <[EMAIL PROTECTED]> > Reply-To: LSST Data Management <[email protected]> > Date: Tue, 21 Nov 2006 15:39:22 -0500 > To: LSST Data Management <[email protected]> > Subject: [LSST-data] DataChallenge: Thoughts on software process using trac > > Pursuant to my mail about using trac, Craig Loomis > ([EMAIL PROTECTED]) > commented: > >> If you are thinking in this vein, I'll commend a link I recently >> bumped into >> describing a (stupidly named) development cycle. It feels _doable_ >> on a >> personal/human level, mainly because of its essential clarity. And >> I can >> think of many code/management/human pathologies which would it >> would help avert. >> http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem. > > I found this a worthwhile read. We've talked about code reviews, and > this > is an interesting way of approaching the problem. > > R > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
