Isn't this stuff in the developer's doc?
It was at least at some point in time... (perhaps they need refreshing,
e.g., s/CVS/SVN/r).
Even if this info is in there, it would be our fault for not sending
the doc to Erich upon him obtaining commit permission. Something to
remember for the future!
On Aug 21, 2005, at 6:45 PM, Erich Focht wrote:
Hello John,
you (or DongIn) should send these rules to everybody who gets
write-access to
the SVN, when he gets write access.
On Friday 19 August 2005 19:34, John Mugler wrote:
Hey Erich,
Here are the svn rules for the project in my own lingo. I'm cc'ing
the core
list as a reminder to everyone. This is not a smackdown, because I for
sure do not want to stop any development or bug fixing.
1. On a frozen branch, you can only check in code to fix priority 9
bugs.
Additionally, since a 9 is a 'showstopper', it should not be closed
out
until tested/verified by a third party. In practice, if there's
something
you've been working on for the release and want to get in really
badly,
sometimes a new bug can be generated and upped. I think the system
should
support development and not squish it.
Bernard made me aware of this and I follow it since I know about it. I
reopen the sync_files bug until somebody checks it.
2. Only the release manager, currently me, or a designated alternate
can
up a bug to priority nine. If you just ask me directly, often i'll
just
say go do it (like with the patched c3 rpm's). Otherwise, it may take
me a
day or so to read the sf bug traffic and do something about it.
I must admit that I misunderstood your reply to my C3 query. You said
I should
open a bug, up it to 9 and fix it. It sounded like I could do this
with any
bug I consider serious enough as long as it is well documented (in the
bug
tracker). As you have seen from the bugs I filed the past days, I was
selective with raising priorities to 9. Now I understood how you meant
it. Thanks for clarifying. Feel free to revert checked in code from
branch and
reduce priority.
3. Our traditional rule is check in nothing that breaks the trunk. Of
everything, this is probably the worst, because it can shut down all
development. We have a database development branch now, and could add
another if the need is there.
While (1) and (2) are quite OSCAR specific, (3) is common sense. What
I'm
unsure about is how to proceed with bigger checkins:
- split them up in logically reasonable pieces and check them in
separately,
at the same time (more or less). Comments and checkin descriptions are
more
sensible in this case, code reviews are also easier, but until all
small
checkins are committed the tree might be broken for short time because
the
separate small pieces might rely on each other but touch different
parts of
code. This is how the linux kernel tree is handled.
- or: submit the concatenation of the small pieces at once, as one
single big
checkin. This way the tree is (hopefully) at no moment broken, but code
reviews get difficult, logs/comments make less sense and it is hard to
revert
small pieces of the change.
Do you have a rule here?
So lets OSCAR on in a friendly fashion, but please stay inside the
rules.
Once known... sure.
Thanks,
Erich
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
