There are two approachs to handling SCR in this:
1. For every checkin, ask the developer what bug has been fixed. Do this
regardless of what branch the checkin occurs on.
Assumption
* bug fix in file version is unaffected by other file versions
Advantages
* you know precisely which file version fixes which bug
* this is done via a relatively simple checkin trigger
Disadvantages
* finding what bugs merged into a nightly build can be tough
** its a complicated DAG traversal that follows merge arrows
* developers will tire of the constant "what bug?" trigger question
** environment variable overrides might help -- or hurt!
2. Have a checkin trigger on the build branch alone that requires a (list
of) bugs fixed for every checkin -- leave developer branches alone.
Assumption
* if developer fixed bug on branch, the whole branch impacts the fix
Advantages
* far less questions to the developer -- they might answer them more easily.
* finding bugs fixed in build involves only looking at build branch.
Disadvantages
* checkin trigger is more (but not a lot more) complicated
* developers may forget what bugs they fixed by the time of the merge
-----Original Message-----
From: Configuration Manager [mailto:cm_mbox@yahoo.com
Sent: Thursday, February 24, 2000 10:09 AM
To: Masterson, David; cciug@Rational.Com
Cc: julier@techapp.com
Subject: RE: [cciug] Build Procedures/Policy
Hi, how would change management/tracking be done in this situation
(ie. CC/CQ integration, systematic baseline creation, change set
tracking, etc...)
The original poster seemed to want to tie SCRs to file versions and
use SCRs as a basis for baseline creation for the builds, instead of
simply /main/LATEST.
Mechanically, I can see how what you write below could work. But as
far as change management/tracking, knowing what SCRs are actually
completed, what files version hold there changes, and ensuring the
integrity of the tracking system (are the states of the SCRs really
reflective of where the changes are, in develop, awaiting build, in
testing, etc) I don't fully understand how that can be done in the
process described below.
I say the original poster is on the right track. Tying tracking
"numbers" to file versions at checkin is the easiest and least
burdonsome on the developer (as opposed to having them create labels
or attibutes manually themselves). And can lay the foundation for
better code and build management stategies and most important, a
fully automated baseline/build/delivery CM system.
Just my thoughts, I think the original poster is on a good path.
Mark
--- "Masterson, David" <David.Masterson@kla-tencor.com> wrote:
>
> Wouldn't it have been easier to enforce a policy where all
> developers must
> do their work on a private branch and, when they deem their work
> ready for
> submission, they must merge it to the nightly build branch?
>
> Advantages:
> * Developer is still responsible for deciding when to submit and
> doing
> submission.
> * If necessary, build branch can be locked against developers until
> the meet
> submission guidelines (for instance, unit test logged and passed).
> * Nightly build uses simple config-spec that picks up latest code
> on the
> build branch and locks the build branch while build is going on.
>
> -----Original Message-----
> From: Krishnan Srinivasan
> [mailto:Srini.Krishnan@nmg.sms.siemens.com
> Sent: Wednesday, February 23, 2000 12:44 PM
> To: 'Julie Rudinski'; cciug@Rational.Com
> Subject: RE: [cciug] Build Procedures/Policy
>
>
>
> I had the same situation. My policy works great, and the developers
> are very
> happy with this scenario:
>
> - Enforce a "submission scheme" to the nightly build. i.e., every
> identified
> component will have a submitted label (say, COMP_A_SUBMITTED).
> Then, the
> responsible engineer will label the code of the component A with
> the
> submitted label.
>
> Advantage of submission scheme: the developer decides when his/her
> code is
> fit for going into the build/foundation. you dont need to worry
> about
> whether that code is tested or not..
>
> - Before you start your build:
> 1. set the config specs pointing to the set of submitted labels
> (I have
> this automated in the build script in such a way that config specs
> is under
> version control, so that I can go back to any old build)
> 2. lock these submitted labels (so that no one submits anything
> new when
> the build goes)
> 3. Perform your build..
> 4. ci bins and label bins and src with a build label (which
> later
> becomes a baseline label during releases)
> 5. unlock the submitted labels for next build submission
>
> As vobadm, one needs to worry about growing size of bin location.
> For this,
> I keep only last (say) 5 build binaries and delete the previous
> versions of
> the DOs.
>
> This works great for me. no hazzles!
>
> good luck!
>
> -Krish..
>
> -----Original Message-----
> From: Julie Rudinski [mailto:julier@techapp.com
> Sent: Wednesday, February 23, 2000 1:19 PM
> To: cciug@Rational.Com
> Subject: [cciug] Build Procedures/Policy
>
>
> Hello everyone,
>
> I was wondering if I could get some input on how everyone manages
> their
> build schedules.
>
> Currently we have a development branch which all the work is done
> on. The
> developers check in their code when they are finished and when it
> comes time
> to build I pick up the latest elements on the development branch.
> This has
> caused a few problems with files not being checked in, and
> developers not
> testing their code.
>
> I want to enforce a more "strict" policy. My idea is as follows:
> All changes to the code are related to a software change number
> and I
> have a script prompting for the SCR# upon check in. An attribute is
> then
> placed on the element. <This is the new part --> I want the
> developers to
> submit the SCR# with a listing of all changed files (I have a
> script for
> this, they just need to run it). Then I can build based only on the
> submitted SCR#'s.
>
> Unfortunately, the developers are adamantly against this idea
> because it
> requires them to do extra work (running a script) and remembering
> to submit
> their SCR's. (since I said non submitted SCRs would not go into the
> build).
>
> So I am back to square one, building the latest elements which I do
> not
> think is adequate procedure.
>
> Does anybody have any suggestions?
>
> I would appreciate it greatly.
>
> Thank you,
> Julie Rudinski
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> can also
> unsubscribe
>
> http://clearcase.rational.com/cciug/mailing_list.html
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> can also
> unsubscribe
>
> http://clearcase.rational.com/cciug/mailing_list.html
>
=====
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:26 EDT