[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-open-discuss
Subject:    Re: [Open-discuss] Correcting Errors in Helix Community Code
From:       Greg Wright <gwright () real ! com>
Date:       2005-02-28 18:43:58
Message-ID: 4223666E.9020705 () real ! com
[Download RAW message or body]

 >Phil.Purvis@nokia.com wrote:
 >
 >I have a few questions about the general code change process for error
 >fixes in the Helix Community. I reviewed the "Submitting Patches for
 >Helix" webpage (https://helixcommunity.org/2004/patch/).
 >
 >I am most interested in knowing what has changed in my version of the
 >product from one build to the next. This information is useful to
 >assist in additional verification and/or general communication to
 >users of my product.
 >
 >
 >1. Is the "Change Notification" (CN) form required for all changes? CN
 >forms are attached to Code Review (CR) request to the various mail
 >distribution lists.

The CN and CR forms are one in the same. You first send out the code
review request (CR) filling in most of the blanks. Then, after the
review has happened, any changes have been made and the code has been
checked in, a Change Notification (CN) email is sent out. It is just
a note saying that the changes mentioned in the CR have been committed.
At that point you rill in who made the change, when it was done and
who reviewed it.

 >
 >2. Is a Bugzilla report ever required for a code change? Bugzilla is
 >never mentioned in the patch webpage.

This is something we have been talking about, but right now it is
not required. Sometimes it is much easier to track a patch if you
associate it with a bug because you will know when it gets closed
without having to look for a CN email. However, it is also overkill
for a lot of small changes. Either way however, a CR and CN email
is required, even if the change is associated with a bug number.


 >
 >3. Is there any difference in the process if the code change is a
 >"trivial one liner" update vs. a redesign of a module?

Not as far as the CR and CN emails go. However, a redesign is
usually associated with a SOD email (statement of design). For large
far reaching changes the design is researched by a individual or
team and then their findings and proposed solution are sent out to
the appropriate mailing list in a SOD email. The format of the SOD
can change a bit but usually includes at least a statement of the
problem, the proposed solution(s), research done and a estimate of
how much time it would take. After that there will be a public
discussion of the solution and the SOD would be updated to reflect
any changes coming from that discussion.


 >
 >4. There is a statement that the process is stricter when a branch
 >affected by the submittal is in code freeze or for STABLE and RELEASE
 >branches. The process is also stricter when the submittal involves
 >code shared with other groups. Is there any definition or guidelines
 >of what "stricter" means? Is the code looked at "in more detail"? Are
 >different fields of the CN form required? Or is it just stricter in
 >the sense that a lower threshold of risk is accepted.

It is a bit of all of them. For a frozen branch we really only want to
make changes that fix security related bugs and hard crashes or bugs
that greatly affect the usability of the product. These changes will
be looked at more closely and we will generally want the fixes to have
minimal impact on the code (very little chance of them introducing
other bugs). So, in some cases we may fix a bug in a very safe sub
optimal way on a frozen branch and fix the same bug on the HEAD with
a more optimal but riskier fix because we have more time for testing.
So, you may send out a CR for a fix on several branches and it may
be deemed OK for only some of them and might be asked to come up with
a 'safer' fix for any branch a release has occurred on.

 >
 >5. If the CR request is for a branch, is the same CR request valid for
 >the HEAD as well? (that is they do not have to create a separate CR
 >request with a separate CN form) Also, is the commit to the HEAD
 >required at the same time as the commit to the branch?

Yes, the same CR email is used for all branches. At the end of the CR
form is a place to list all of the branch you think the change is needed
on. In some cases we may suggest that it is good for additional branches
as well.

Any change made to any branch *must* be committed to all branches between
it and the trunk(HEAD). The exception being cases like the security bugs
mentioned above in answer to #4. For example, if you commit a change
to the 142NepX branch, you would need to merge that change to the 130NepX
branch as well as HEAD. 142NepX was branched from 130NepX, that is why
you need it there. All branches ultimatly come from HEAD so HEAD always
gets all fixes.


 >
 >6. Is the only difference between an error fix (i.e. patch) and other
 >code changes (e.g. Feature Development) the requirement to submit a
 >new project proposal for feature development?

Yes, that is correct generally. There will commonly be bugs associated with
'error fixes' and SODS with major new features. Things of that nature, but
overall the process for changing the code and getting it checked in remains
the same.

Let me know if you have any other questions,
--greg.



 >
 > Thanks for any input...
 >
 > Phil.Purvis@nokia.com
 > Video PD Software Quality Engineer
 > TP/S60/Apps/Multimedia
 >
 >
 >
 > _______________________________________________
 > Open-discuss mailing list
 > Open-discuss@helixcommunity.org
 > http://lists.helixcommunity.org/mailman/listinfo/open-discuss
 >



[prev in list] [next in list] [prev in thread] [next in thread]