You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/08/12 18:35:38 UTC
Did you submit code that got lost?
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 <bl...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Did you submit code that got lost?
Posted by Danny Angus <da...@apache.org>.
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 <bl...@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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Did you submit code that got lost?
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
+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 <bl...@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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>