Maybe we should add something about how we do things in: http://www.gnu.org/software/grep/devel.html
It'd be useful for new developers. In particular, the life-cycle of a bug/patch should be mentioned. (Maybe it's already there, but I just couldn't find it) Cheers, TAA -------------------------------------------------- Tony Abou-Assaleh Ph.D. Candidate, Faculty of Computer Science Dalhousie University, Halifax, NS, Canada, B3H 1W5 Fax: 902-492-1517 Email: [EMAIL PROTECTED] WWW: http://www.cs.dal.ca/~taa/ ---------------------[THE END]-------------------- On Fri, 24 Jun 2005, Paul Eggert wrote: > Tony Abou-Assaleh <[EMAIL PROTECTED]> writes: > > > What's the purpose of having more committers if we have active ones? > > I'm a bit of a special case, since I helped maintain grep (though I > was never the official maintainer) and I understand parts of the > source code quite well. For some global changes (in particular > gnulib-related ones) it will be more convenient for me to install the > changes, as they may be a bit tricky to explain precisely via a patch. > > Obviously I'd want to work within any existing review process. What > is the process? Is it written down anywhere? I grepped for "review" > in the grep source and didn't find anything. > > Part of the motivation here, to be honest, is to improve the activity > rate of 'grep'. 'grep' was way too stagnant for quite some time. > It's gotten better, but it's still too slow. > >
