Re: [vchkpw] lets stop the fight!
I ment branches :) ok :) sorry... Evren On Wed, 10 Sep 2003, Adam Hooper wrote: > Two CVS sources is a nightmare -- as a user, I'd much rather two > branches on the same source, so I could just do, for example, 'cvs up -r > UNSTABLE' > > -- > Adam Hooper > [EMAIL PROTECTED] > > Evren Yurtesen wrote: > > I dont see why you fight over this. There should be two cvs sources anyhow > > one for current development branch and one for stable releases branch. > > > >
Re: [vchkpw] lets stop the fight!
Two CVS sources is a nightmare -- as a user, I'd much rather two branches on the same source, so I could just do, for example, 'cvs up -r UNSTABLE' -- Adam Hooper [EMAIL PROTECTED] Evren Yurtesen wrote: I dont see why you fight over this. There should be two cvs sources anyhow one for current development branch and one for stable releases branch.
Re: [vchkpw] lets stop the fight!
100% right.
it will be really a pain to have two separate sources.
and if they don't agree between, i think that ken should keep the name
"vpopmail" for this product. the manner and style for the comments does
not apply there. futuremore, the public can not what happened between
tom and ken, making ken so angry.
and to be more specific, i think it is really "enemy inside" tactic to
use sourceforge's popularity to forcibly change the head of the project
- and i can somehow understand ken.
but your solution, evren, is really the best - for an commerical
support/soluton provider it will be good to have/manage the stable versions.
if they can not make agreement, it will be fair if tom steps back or at
least _rename_ the project - yes, change the name, tpopmail for example,
and start his _own_ clone.
i think that this is becoming quite quickly a fight for the vpopmail's
name. if tom cares so much for the source and the users, it is up to him
to start a new product tree based on current vpopmail - and maybe inter7
can put a link to his clone on their web site even...
..but to be a god-like judge who decides who can and who can not manage
the project ("own" it) ... placing himsef on a first place... nah, i can
not agree with such a way to "make good" and "care" for something. anything.
wwell edi
Evren Yurtesen wrote:
I dont see why you fight over this. There should be two cvs sources anyhow
one for current development branch and one for stable releases branch.
The new features shouldnt be added to stable branch until they are
relatively bug free.
Since Tom seems to handle cutting edge stuff in the code, we need an admin
for stable releases. Ken can be stable releases admin. (I dont know how
this can be arranged in sourceforge though) Everybody can be happy this
way.
Listen to the users, they want stable releases. Stop fighting over
vpopmail and share the responsibility. The need for stable releases is
obvious. Yet Tom seems to do excellent job in refining the code and
adding new features he seems to come short on creating stable releases.
I see a job vacancy there for Ken :) and inter7.
I think it is REALLY bad idea to have two vpopmail development going on
with different names. That would cause the development force to divide in
two also. Why not use all our force to create one properly working
vpopmail distribution instead of doing two which doesnt satisfy anyone
because of bugs or lack of features?
Evren
[vchkpw] Re: [ ABU1063185538696 ] Re: [vchkpw] lets stop the fight!
Okay wtf is this!
i put a reply to this thread and i get a mail from [EMAIL PROTECTED] cause
of their office is moving
and one from this
Would you guys shut down anti-spam and auto-reply stuff when ya listeninng
to a mailinglist!
or could the mailinglist admin remove them from the list??
/Raboo
- Original Message -
From: "Prodigy Abuse Department" <[EMAIL PROTECTED]>
To: "Raboo Treed" <[EMAIL PROTECTED]>
Sent: Wednesday, September 10, 2003 11:18 AM
Subject: [ ABU1063185538696 ] Re: [vchkpw] lets stop the fight!
>
> Thank you for writing to SBC Internet Services Policy Group.
> We apologize for the inconvenience you have experienced. This is an
auto-generated response designed to let you know that we have received your
report, which will be investigated personally by one of our Support
Representatives within 48 hours. Your report is important to us and we will
treat it accordingly. Please note that we can only take action with SBC
Internet user's accounts (which have SBC Internet IP addresses), and not
those with any other IP address.
>
> You will not receive another message from us unless we need to request
more information from you to further our investigation. Please do not
respond to this e-mail, as any messages sent to this particular address by
using the "Reply" button will not be read. We appreciate your understanding
that due to our privacy policy, we will not report back to you about any
action taken against SBC Internet users. However, we want to assure you that
we will take appropriate action against SBC Internet users who have violated
the SBC/Yahoo Terms of Service or the Acceptable Use Policy
>
> In order for us to process your complaint, please check that you have
submitted all of the following information for each type of incident:
>
> Unsolicited Commercial/Bulk Email ("Spam"):
> - FULL message headers
> - Subject line exactly as it appears in the original message (i.e. 'Re:
Make $$$!')
> - Trimmed body. Send only as much of the text as needed to show the
e-mail's intent.
> - Limited commentary. We understand your frustration with Spam, but the
less time we spend reading your email, the more time we have to fight Spam.
>
> If we determine that the Spam originated from another ISP, we may refer
the matter to the respective ISP.
>
>
> Intrusion/Disruption Attempts (Trojans, "Hacks", Port Scans, etc.)/
Denials of Service (ICMP "floods", brute-force connections, etc.):
> - Full log files containing all of the information below:
> - IP Address of intruder (or the DNS name pointing to said address)
> - Date/Time Stamp with ZONE (either numerical [-0600] or alpha
[CST])
> - Protocol/Port used (either numerical [25] or alpha [SMTP])
> - Number of instances of each packet type received
>
> Newsgroup violations:
> - FULL message headers (including NNTP and Xtrace information)
> - Subject line exactly as it appears in the original message (i.e. 'Re:
Make $$$!')
> - Trimmed body. Send only as much of the text as needed to show the
e-mail's intent.
> - Limited commentary. As with Spam, the less time we spend reading your
email, the more time we will have to take care of the problem.
>
>
> - PLEASE NOTE THE FOLLOWING -
> GENERAL:
> Please keep in mind complaints could take up to 48 hrs to process.
>
> BOGUS REPORTS:
> Many software packages will log and report what they construe to be
suspicious behavior. These reports are only as good as the software
configurations and tend to err on the paranoid side. Submissions generated
by such software in which relatively minor errors are reported (i.e. a
single ICMP packet, UDP frames from ICQ, DNS packets) will be discarded
without response from SBCIS due to the volume of such requests received.
>
> LEGAL:
> SBCIS does not tolerate abusive Internet behavior, and will take all steps
reasonably necessary to enforce the Terms of Service (ToS) and Acceptable
Use Policy (AUP). We will not supply you with any details relative to our
other customers or users unless compelled by law to do so. If you wish to
obtain such information, you must first obtain a valid subpoena, court
order, or other valid and enforceable legal instrument allowing you to do
so.
>
> SECURITY AND VIRUS PROTECTION:
> You are responsible for securing and protecting your own computer system
and network. SBCIS does not provide anti-virus or virus recovery services.
You should contact the manufacturer of your computer, or a qualified
provider of virus recovery services, in order to obtain assistance with this
matter.
>
> Copyright/DMCA:
> For copyright issues, please send all correspondence to
[EMAIL PROTECTED]
>
> For our DMCA Agent contact information, please see our designated DMCA
Age
Re: [vchkpw] lets stop the fight!
I think they should write a contract to make both admin on the SF page and in the contract it should say that noone should be able to remove one anothers admin status. or let someone neutral handle the admin part, and make both regular members? Peace /Raboo - Original Message - From: "Evren Yurtesen" <[EMAIL PROTECTED]> To: "vpopmail list" <[EMAIL PROTECTED]> Cc: "Ken Jones" <[EMAIL PROTECTED]>; "Tom Collins" <[EMAIL PROTECTED]> Sent: Wednesday, September 10, 2003 10:11 AM Subject: [vchkpw] lets stop the fight! > I dont see why you fight over this. There should be two cvs sources anyhow > one for current development branch and one for stable releases branch. > > The new features shouldnt be added to stable branch until they are > relatively bug free. > > Since Tom seems to handle cutting edge stuff in the code, we need an admin > for stable releases. Ken can be stable releases admin. (I dont know how > this can be arranged in sourceforge though) Everybody can be happy this > way. > > Listen to the users, they want stable releases. Stop fighting over > vpopmail and share the responsibility. The need for stable releases is > obvious. Yet Tom seems to do excellent job in refining the code and > adding new features he seems to come short on creating stable releases. > I see a job vacancy there for Ken :) and inter7. > > I think it is REALLY bad idea to have two vpopmail development going on > with different names. That would cause the development force to divide in > two also. Why not use all our force to create one properly working > vpopmail distribution instead of doing two which doesnt satisfy anyone > because of bugs or lack of features? > > Evren > > >
[vchkpw] lets stop the fight!
I dont see why you fight over this. There should be two cvs sources anyhow one for current development branch and one for stable releases branch. The new features shouldnt be added to stable branch until they are relatively bug free. Since Tom seems to handle cutting edge stuff in the code, we need an admin for stable releases. Ken can be stable releases admin. (I dont know how this can be arranged in sourceforge though) Everybody can be happy this way. Listen to the users, they want stable releases. Stop fighting over vpopmail and share the responsibility. The need for stable releases is obvious. Yet Tom seems to do excellent job in refining the code and adding new features he seems to come short on creating stable releases. I see a job vacancy there for Ken :) and inter7. I think it is REALLY bad idea to have two vpopmail development going on with different names. That would cause the development force to divide in two also. Why not use all our force to create one properly working vpopmail distribution instead of doing two which doesnt satisfy anyone because of bugs or lack of features? Evren
