+1 I agree with Noel.Following the conventions makes life a lot easier for committers. Charles
Noel J. Bergman wrote: > Unfortunately, I am spotting a lot of submissions that didn't follow > convention, and appear to have been "lost" on the mailing list. For > example, it looks like the code from this message: > > http://www.mail-archive.com/[email protected]/msg01721.html > > got lost in the shuffle, and it was even asked for by Danny and Serge. I > can't find any indication that it was rejected, just lost. That is just an > example of possibly lost code. In this case, I suspect that the code was > "lost" because Blas Rodriguez Somoza <[EMAIL PROTECTED]> submitted DIFF > files, and Serge had asked for complete files to go into the proposal > section. > > Also on the subject of virtual hosts (one of the most frequent requests), > here were two other submissions: > > http://www.mail-archive.com/[email protected]/msg02643.html > http://www.mail-archive.com/[email protected]/msg01718.html > > If you've submitted code for JAMES that hasn't been either incorporated, > placed into proposals/ for others to view, or rejected, please don't take it > personally. Consider updating it to match the current CVS tree, and > re-submitting it. > > Not all code will be accepted, but you should at least find out why it is > rejected. For example, the above referenced archive messages address > virtual hosting in three different ways, sometimes with other items. > Eventually, one way will be added to James. It may be one of the above, or > it may be a completely new mechanism. Changes need to be made in the > context of other changes that are planned. > > SUGGESTION: if you are working on an area, please start a discussion on the > mailing list, and get feedback on your approach. Others may be working on > the problem, too, and you may be able to merge efforts. Also, you may get > feedback suggesting a change in your approach that works better in the > overall picture. For example, a virtual hosting solution that works only > with one type of user repository won't be accepted into the mainstream > (although it could be put into a proposal), because we need a uniform > mechanism that hides the repository implementation from the rest of James. > (Plus we need it to properly work with the admin tools, such as they are.) > Anyone who read the discussions on Mailet API v2 (and mailet logging) early > this summer should understand that although discussion can involve heated > disagreements, the discussion is about CODE and APPROACH, not about > personalities. > > Steps: > > 1. Please make sure that the code is based upon > the current CVS, not an older snapshot! > > 2. Please DESCRIBE the problem being solved, and > HOW THE SUBMISSION WORKS. > > 3. Please submit a DIFF (cvs diff -u) in the case of > a patch, and be prepared to submit a whole source > kit if the decision is to make it a proposal before > incorporating it into the mainstream code. > > 4. PLEASE *TAG* YOUR MESSAGE PROPERLY. > > The convention is to prefix the message with [PATCH] if you are submitting a > patch/change. I don't know if we have a convention for marking code that > isn't intended for the mainstream, yet, but you can clearly indicate that in > your message. AND STILL TAG THE MESSAGE so that it doesn't get lost. Often > the [PREFIX] is used to filter higher priority items, especially when people > are very busy. > > If there are other [PREFIX] conventions of this nature, perhaps someone can > fill us all in, so that they can be used properly. > > --- Noel > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
