james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Did you submit code that got lost?
Date Mon, 12 Aug 2002 22:35:04 GMT
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:charles@benett1.demon.co.uk]
> 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/james-dev@jakarta.apache.org/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 <blas@puertareal.com>
> 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/james-dev@jakarta.apache.org/msg02643.html
> >
> http://www.mail-archive.com/james-dev@jakarta.apache.org/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:james-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:james-dev-help@jakarta.apache.org>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:james-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message