You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2005/12/02 03:28:05 UTC
Committer cleanup
I'd like to go ahead and remove all the committers from subversion for
commons, and then add back anyone who has committed in the last 6
months.
We have 105 commons committers, and 36 additional sandbox committers.
We've had 43 committers committing to proper, and 7 extra committing
to sandbox in the last 6 months.
Then we'd add back anyone else on request if need be.
Anyone against the idea?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Committer cleanup
Posted by Henri Yandell <fl...@gmail.com>.
On 12/1/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/1/05, Henri Yandell <fl...@gmail.com> wrote:
> >
> > I'd like to go ahead and remove all the committers from subversion for
> > commons, and then add back anyone who has committed in the last 6
> > months.
> >
> > We have 105 commons committers, and 36 additional sandbox committers.
> >
> > We've had 43 committers committing to proper, and 7 extra committing
> > to sandbox in the last 6 months.
> >
> > Then we'd add back anyone else on request if need be.
> >
> > Anyone against the idea?
>
>
> 6 months seems quite short if you're only counting commits. Would the
> numbers be significantly different if we use 1 year instead?
I'll find out. Probably not.
> Where do you plan on keeping the list of people removed? It will need to be
> somewhere that we can get at, so that we know who can be added back without
> question.
I'll start a file in the Jakarta PMC area in the committers module.
I'm aiming to do this for all of Jakarta, so it'll be the start of
that. It'll list each svn module, and who's commit karma has been
removed.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Committer cleanup
Posted by Henri Yandell <fl...@gmail.com>.
On 12/1/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/1/05, Henri Yandell <fl...@gmail.com> wrote:
> >
> > I'd like to go ahead and remove all the committers from subversion for
> > commons, and then add back anyone who has committed in the last 6
> > months.
> >
> > We have 105 commons committers, and 36 additional sandbox committers.
> >
> > We've had 43 committers committing to proper, and 7 extra committing
> > to sandbox in the last 6 months.
> >
> > Then we'd add back anyone else on request if need be.
> >
> > Anyone against the idea?
>
>
> 6 months seems quite short if you're only counting commits. Would the
> numbers be significantly different if we use 1 year instead?
FYI,
In the last year, 53 committers committing to proper, and 8 extra
committing to the sandbox.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Committer cleanup
Posted by Martin Cooper <ma...@apache.org>.
On 12/1/05, Henri Yandell <fl...@gmail.com> wrote:
>
> I'd like to go ahead and remove all the committers from subversion for
> commons, and then add back anyone who has committed in the last 6
> months.
>
> We have 105 commons committers, and 36 additional sandbox committers.
>
> We've had 43 committers committing to proper, and 7 extra committing
> to sandbox in the last 6 months.
>
> Then we'd add back anyone else on request if need be.
>
> Anyone against the idea?
6 months seems quite short if you're only counting commits. Would the
numbers be significantly different if we use 1 year instead?
Where do you plan on keeping the list of people removed? It will need to be
somewhere that we can get at, so that we know who can be added back without
question.
--
Martin Cooper
Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Committer cleanup
Posted by Henri Yandell <fl...@gmail.com>.
On 12/2/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Henri Yandell wrote:
> > I'd like to go ahead and remove all the committers from subversion for
> > commons, and then add back anyone who has committed in the last 6
> > months.
> >
> 1 year - and if possible take the user/dev mailinglist for this project
> into account.
> A commiter active in the mailinglist is also a valuable part of a
> project and for the community.
1 year shouldn't be a problem.
Mailing lists will be a pain as people don't use their @apache.org
addresses all the time. Easy solution there is to post the list of
people I'll end up removing to the list and anyone can request to be
re-added with no fuss.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Committer cleanup
Posted by Henri Yandell <fl...@gmail.com>.
Two reasons.
1) Oversight. So it's much more obvious when a project is inactive and
low on committers.
2) Tidyness. I hate the thought of the long committer lists just
growing longer and more inaccurate.
I'm looking for a way to represent the active community of a
subproject, and while there might be active individuals who just deal
with answers on the mailing list etc, largely the svn commit lists are
the best way to record this.
Hen
On 12/2/05, Eric Pugh <ep...@upstate.com> wrote:
> I agree with the 1 year mark. I know that there are projects that I
> haven't worked on for six months until the itch came back and I had
> to scratch it! Is there any reason to remove committers?
> Performance? Security? It seems to raise a barrier to reentry for
> dormant committers.
>
> Eric
>
> On Dec 2, 2005, at 1:58 AM, Mario Ivankovits wrote:
>
> > Henri Yandell wrote:
> >> I'd like to go ahead and remove all the committers from subversion
> >> for
> >> commons, and then add back anyone who has committed in the last 6
> >> months.
> >>
> > 1 year - and if possible take the user/dev mailinglist for this
> > project into account.
> > A commiter active in the mailinglist is also a valuable part of a
> > project and for the community.
> >
> > ---
> > Mario
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[ALL] [WAS Re: Committer cleanup]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-12-02 at 10:14 -0500, Eric Pugh wrote:
> I agree with the 1 year mark. I know that there are projects that I
> haven't worked on for six months until the itch came back and I had
> to scratch it! Is there any reason to remove committers?
> Performance? Security? It seems to raise a barrier to reentry for
> dormant committers.
i'm also a little concerned about barriers to (re-) entry: the higher
the barrier to re-entry, the more strain this places on the core commons
committers. in terms of removing commit access, 6 months seems too short
but is probably too long to help to highlight problems with components.
1 year is more acceptable but IMHO this is a jakarta-wide issue.
but i agree with the general strategy. we need to find out when the
number of active committers reaches a minimal threshold.
a more pressing problem is voting: there have been a number of votes
which have failed due to apathy. given the new understanding about the
legal status of pmc's, the commons voting procedures are now seem out
dated.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Committer cleanup
Posted by Eric Pugh <ep...@upstate.com>.
I agree with the 1 year mark. I know that there are projects that I
haven't worked on for six months until the itch came back and I had
to scratch it! Is there any reason to remove committers?
Performance? Security? It seems to raise a barrier to reentry for
dormant committers.
Eric
On Dec 2, 2005, at 1:58 AM, Mario Ivankovits wrote:
> Henri Yandell wrote:
>> I'd like to go ahead and remove all the committers from subversion
>> for
>> commons, and then add back anyone who has committed in the last 6
>> months.
>>
> 1 year - and if possible take the user/dev mailinglist for this
> project into account.
> A commiter active in the mailinglist is also a valuable part of a
> project and for the community.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Using Templates for Mail Message
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The problem I would see with having this in email, even as a utility, is
that it isn't e-mail specific.
While your use case deals with the file system and (presumably?) a
bean-type substitution (e.g., @@LOGIN@@, user.getLogin()), there is a
broader scope of retrieval of information from other sources (database,
property files, etc). The use cases (and dependencies to match) could
get well out of control for a simple project aimed at making e-mail
easier to use.
Perhaps a utility class for your use case could simply deal with
String's replace/replaceAll?
Brian
Herak Sen wrote:
> Hi!
> Thanks for writing back
> I agree that it won't be part of the core Email project,but as helpers or utils.
> Please comment.
> Thanks
> Herak
>
> "Brian K. Wallace" <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Herak Sen wrote:
>> Hi,
>> A very common method which I use for setting messages is by loading from an external file and replace some tokens with desired values.
>> For e.g.
>> ------------------------------------------------------------------
>> AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
>> -------------------------------------------------------------------
>> Hello,
>> You have been successfully registered.
>> Login Detail
>> login :@LOGIN@
>> pwd :@PWD@
>> -----------------------------------------------------------------
>> After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate values and then send the contents.
>> I was wondering whether such feature could be incorporated in API.
>> There could be a class something like the following
>> public class Template{
>> private String template;
>> public Template(InputStream in){
>> template=loadTemplate(in);
>> }
>> public String replaceTokens(Map map){
>> //Replace all string within @@
>> return template;
>> }
>> }
>>
>> May be have a more sophisticated implementation for various data sources.
>> Please share your views.
>>
>> Thanks
>> Herak
>
> This appears to me to be outside the realm of [email] itself. Not
> discounting the number of times this type of templating is performed -
> just seems outside the scope of the email project.
>
>
> My .02
>
> Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkBabaCoPKRow/gARAu9TAKDlpgsI+ifuml0mvXdLTwGo440ckwCdHKK7
0wRZN2bjetPh2whN/8K+eNk=
=/ART
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Using Templates for Mail Message
Posted by Herak Sen <he...@yahoo.com>.
Hi!
Thanks for writing back
I agree that it won't be part of the core Email project,but as helpers or utils.
Please comment.
Thanks
Herak
"Brian K. Wallace" <br...@transmorphix.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Herak Sen wrote:
> Hi,
> A very common method which I use for setting messages is by loading from an external file and replace some tokens with desired values.
> For e.g.
> ------------------------------------------------------------------
> AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
> -------------------------------------------------------------------
> Hello,
> You have been successfully registered.
> Login Detail
> login :@LOGIN@
> pwd :@PWD@
> -----------------------------------------------------------------
> After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate values and then send the contents.
> I was wondering whether such feature could be incorporated in API.
> There could be a class something like the following
> public class Template{
> private String template;
> public Template(InputStream in){
> template=loadTemplate(in);
> }
> public String replaceTokens(Map map){
> //Replace all string within @@
> return template;
> }
> }
>
> May be have a more sophisticated implementation for various data sources.
> Please share your views.
>
> Thanks
> Herak
This appears to me to be outside the realm of [email] itself. Not
discounting the number of times this type of templating is performed -
just seems outside the scope of the email project.
My .02
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkAz1aCoPKRow/gARAq5WAKDQvyPU9FXdAusX9Df82AWYhJNt6ACg6hdD
dKPEW13aHtCdPcuHKGuK6Hw=
=kcL3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------
Yahoo! Personals
Let fate take it's course directly to your email.
See who's waiting for you Yahoo! Personals
Re: [email] Using Templates for Mail Message
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Herak Sen wrote:
> Hi,
> A very common method which I use for setting messages is by loading from an external file and replace some tokens with desired values.
> For e.g.
> ------------------------------------------------------------------
> AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
> -------------------------------------------------------------------
> Hello,
> You have been successfully registered.
> Login Detail
> login :@LOGIN@
> pwd :@PWD@
> -----------------------------------------------------------------
> After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate values and then send the contents.
> I was wondering whether such feature could be incorporated in API.
> There could be a class something like the following
> public class Template{
> private String template;
> public Template(InputStream in){
> template=loadTemplate(in);
> }
> public String replaceTokens(Map map){
> //Replace all string within @@
> return template;
> }
> }
>
> May be have a more sophisticated implementation for various data sources.
> Please share your views.
>
> Thanks
> Herak
This appears to me to be outside the realm of [email] itself. Not
discounting the number of times this type of templating is performed -
just seems outside the scope of the email project.
My .02
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkAz1aCoPKRow/gARAq5WAKDQvyPU9FXdAusX9Df82AWYhJNt6ACg6hdD
dKPEW13aHtCdPcuHKGuK6Hw=
=kcL3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [email] Using Templates for Mail Message
Posted by James Carman <ja...@carmanconsulting.com>.
Herak,
Why wouldn't you use something like Velocity for this? Velocity is very
well equipped to handle these sorts of tasks and that's exactly what I use
for generating "system" emails. Commons email doesn't need any utility for
this. The body of an email is (for the most part) simply a string and you
can easily generate that using Velocity. If you'd like a copy of a class I
wrote (VelocityUtils) which makes it easy to turn a velocity template into a
String, let me know. I'll mail it to you directly. It works quite well.
James
-----Original Message-----
From: Herak Sen [mailto:heraksen@yahoo.com]
Sent: Friday, December 02, 2005 2:25 AM
To: Jakarta Commons Developers List
Subject: [email] Using Templates for Mail Message
Hi,
A very common method which I use for setting messages is by loading from an
external file and replace some tokens with desired values.
For e.g.
------------------------------------------------------------------
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
-------------------------------------------------------------------
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-----------------------------------------------------------------
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate
values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
---------------------------------
Yahoo! Personals
Let fate take it's course directly to your email.
See who's waiting for you Yahoo! Personals
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[email] Using Templates for Mail Message
Posted by Herak Sen <he...@yahoo.com>.
Hi,
A very common method which I use for setting messages is by loading from an external file and replace some tokens with desired values.
For e.g.
------------------------------------------------------------------
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
-------------------------------------------------------------------
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-----------------------------------------------------------------
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
---------------------------------
Yahoo! Personals
Let fate take it's course directly to your email.
See who's waiting for you Yahoo! Personals
Re: Committer cleanup
Posted by Mario Ivankovits <ma...@ops.co.at>.
Henri Yandell wrote:
> I'd like to go ahead and remove all the committers from subversion for
> commons, and then add back anyone who has committed in the last 6
> months.
>
1 year - and if possible take the user/dev mailinglist for this project
into account.
A commiter active in the mailinglist is also a valuable part of a
project and for the community.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org