I recently added this page http://jakarta.apache.org/james/contribute.html to address some of these issues, as always you can submit patches for the website xdocs too.
i'm +1 for [PROPOSAL] but would extend it to cover any kind of discussion intended as a precursor to a vote, not just code added to ~/proposals/ (eg JDK 1.3/1.4 dependancy) d. > -----Original Message----- > From: Charles Benett [mailto:[EMAIL PROTECTED]] > Sent: 12 August 2002 20:24 > To: James Developers List > Subject: Re: Did you submit code that got lost? > > > +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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
