each of us gathers bugs reports, usually via
mail lists and private mail from internal at&t users
there is very little code owner intersection between the 3 contributors
that simplifies a lot of the bug fixing
as ast has matured, the bugs have become harder to isolate
but the other side of maturity is that the scope of the
bugs tend to be localized
i.e., mature and ubiquitous apis tend to isolate bugs in
the api implementations rather than across all api usage
so we usually knock heads to get an understanding about the
scope of a bug, and then to parcel out the work
usually that parceling is ``I'll (one of the three) do it''
the big win is putting a lot of up front work into the apis
and then using those apis as much as possible
e.g., { sfio vmalloc cdt vcodex codex cmd dll expr pp shell sum uu }
there is no sccs/bugzilla-like infrastructure
instead there is an integrated build-test-package infrastructure
with a corresponding honor-system update of the appropriate
RELEASE files
On Fri, 11 Apr 2008 08:39:23 -0700 (PDT) David Thompson wrote:
> Yes, thanks for the insights! Pardon my curiosity,
> but could you elaborate more?
> By "filter through me", are you using sccs, rcs,
> svn, cvs, clearcase, bugzilla, yellow sticky notes?
> Even with 3 contributors, I presume that you and
> the other two must use tools to coordinate and track
> your changes? How do you track bugs? How do you
> track the source code changes made to fix a bug?
> These process tidbits are extremely interesting;
> ast is a non-trivial body of code.
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
