[SM-DEVEL] Zookeeper status?

[Chris Hilts <chilts@bi...>]

Hiya developers!

How are things coming with the Zookeeper architecture?  I was goofing
around in PHP today, got a great idea, and am all eager to make it happen=
.
 I can do it for the current stable & devel versions of SquirrelMail, but
it'd be..um.. invasive.  Don't keep me hanging! ;)

Chris Hilts
chilts@...

[SM-DEVEL] Reply Citation Text improvements

[Rick Castello <rick@40...>]

     This is an EXCELLENT idea.

     I think it would also be useful to show the email address as
     the citation, instead of just the "name".

     -Rick


Marc Groot Koerkamp said:
> Hello developers,
>
> Just read an interesting enhancement of the reply citation text.
>
> Could it be adopted in Devel?
>
> What do you think?
>
> Marc Groot Koerkamp.
>
>
>
> --------------------------- Oorspronkelijk bericht
> --------------------------- Onderwerp: [SM-USERS] Reply Citation Text:
> Customization help
> Van:       "Tanniel Simonian" <simonian@...>
> Datum:     Vri, september 13, 2002 18:53
> Aan:       squirrelmail-users@...
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------------
> hello again group,
>
> My question is regarding Reply Citation Text, and how I can curstomize
> it to include the oroginal send date of the email.
>
> For example:
>
> On September 13th, 2002, Tanniel Simonian wrote:
>
> I'm not to up on regular expressions, but was unsure if I could use
> regexp for customized citations.
>
> Thanks for any help.
>
>
>
> --
> Tanniel Simonian
> Programmer / Analyst III
> UCR Libraries
> http://libsys.ucr.edu
> 909 787 2832
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> --
> squirrelmail-devel mailing list
> List Address: squirrelmail-devel@...
> List Info:
> https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs

[SM-DEVEL] [Fwd: [SM-USERS] Reply Citation Text: Customization help]

[Marc Groot Koerkamp <marc@it...>]

Hello developers,

Just read an interesting enhancement of the reply citation text.

Could it be adopted in Devel?

What do you think?

Marc Groot Koerkamp.



--------------------------- Oorspronkelijk bericht ---------------------------
Onderwerp: [SM-USERS] Reply Citation Text: Customization help
Van:       "Tanniel Simonian" <simonian@...>
Datum:     Vri, september 13, 2002 18:53
Aan:       squirrelmail-users@...
------------------------------------------------------------------------------
------------------------------------------------------------------------------
hello again group,

My question is regarding Reply Citation Text, and how I can curstomize it to
include the oroginal send date of the email.

For example:

On September 13th, 2002, Tanniel Simonian wrote:

I'm not to up on regular expressions, but was unsure if I could use regexp for
customized citations.

Thanks for any help.



-- 
Tanniel Simonian
Programmer / Analyst III
UCR Libraries
http://libsys.ucr.edu
909 787 2832

[SM-DEVEL] More on SM_PATH disagreements and accusations

[Rick Castello <rick@40...>]

Paul Joseph Thompson said:
>> I think your idea of ruling out all discussion is a very bad one and
>> if it goes through I'm out of here.
>
> Thijs, that is NOT AT ALL what Rick suggested. His, and my, complaint
> was with Marc stating that he was going to start making certain
> changes in CVS AGAINST the wishes of those in charge.

     Thank you Paul.  You are correct.  In no part of my message did
     I suggest ruling out conversation.  Exactly the opposite is what
     I proposed- talking about disagreements instead of "changing things
     no matter what anyone says."

     I'll defend anyone if they feel strongly the need to find a
     better solution to a problem.  But when someone threatens to
     undermine the trust involved in group access to CVS, and to
     purposely undo someone else's hard work, then something else is
     at issue.

     I challenge ANYONE to find any message in the archives from me
     suggesting that we should not discuss major changes to the code.


>> The team leader should be
>> someone who finalises things that the majority agrees on.. not
>> someone who passes down instructions when he likes to. I haven't seen
>> any discussion about this issue on the list - just Paul who is
>> breaking CVS and plugins without even announcing the change.
>
> Read the mail archives better. As I state in my previous email, the
> topic WAS discussed previously on the list. I left an appropriate
> window for discussion, and after having recieved only positive input,
> moved ahead.

     Again, Paul *did* propose his changes on the list, asked for input,
     and waited a very reasonable period of time for complaints or other
     suggestions.  He didn't act unilaterally AT ALL, and did things the
     way you're supposed to in group projects.


>> I can't use the CVS version anymore because I can't even login.
>> Again, any more of this non-discussion-paul-says-so-so-just-do-it
>> stuff and I'm gone.

     Again, you're misreading things, and putting words in my mouth.
     I NEVER EVER *EVER* said that things should not be discussed, or
     that everyone should just do what Paul says.  If you'll search
     the archives, you'll see that I've disagreed with Paul publicly
     on the lists more than once, and always proposed discussion and
     agreement on resolutions.  Your angst here is misplaced.


> I think that you need to consider your attitude about this, Thijs. My
> question is whether you are in this all for your good, or for the good
> of SquirrelMail.

     Ouch.  This is the part where I scold and defend Paul at the same
     time.  Are you ready for it?

     I'm not a very "sensitive" person when it comes to flames on the
     net.  You can't work on OSS projects if you are, really.  But the
     recent posts by Marc and Thijs *were* both accusatory and of an
     angry tone, and I can see how after reading a few of them, Paul
     might have responded a bit too quickly and harshly, especially
     when his point of view was being misunderstood.

     I myself got a bit cranky upon reading Marc and Thijs' responses
     to my message- mostly out of frustration that they simply didn't
     understand what I was trying to say, and were interpreting my
     message as the OPPOSITE of what I meant by it.  The discussion
     got heated... it happens.

     At the same time, I believe Paul's comment was also out of line,
     as Thijs has done a great deal for this project, and is a valuable
     member of the SquirrelMail team.  I, too, would hate to see Thijs
     leave the team, as we need all the talented and motivated help we
     can get, and he would be sorely missed.


     Having said all that, and having read the recent flurry of messages
     on the subject, it would seem like a good next step in resolving
     this issue would be to re-open discussion on good ways to solve the
     problems that the SM_PATH changes create for existing plugins.

     Keep in mind as well, that the best solution *may be* to rewrite the
     way plugins do things.

     -Rick
     rick@...

Re: [SM-DEVEL] Take Address Plugin

[Jason Munro <jason@st...>]

>> Jeff Grossman said:
>>> I am using the 1.3.2 CVS from 9/13/02, what take address plugin
>>> works? I have the abook_take and address_add.  The address_add plugin
>>> does not seem to do anything.
>>> Thanks,
>>> Jeff
>>> --
>>> Jeff Grossman (jeff@...)
>>
>> Address Add does not currently work in DEVEL-CVS, I have the fix for
>> it, just waiting to get a few more things done with it before I upload
>> it.
>>
>> Jimmy
>
> Could you consider a sophisticated fix with nice small buttons next to
> "To", Cc and Bcc?
> Also keep in mind that devel stores the addresses in the address class.
> Make use of it because it split the personal name, the mailbox and the
> domain name.
>
> Just pass the rfc822_header to your plugin and extract the addresses
> overthere.
>
> Maybe devel should consider to adopt it in core.
>
> What does the rest of the developers think?
>
> Marc Groot Koerkamp.

  It would be a good addition to the core in my opinion.


 \___ Jason Munro
  \___ AIM:jmunr0
   \__ jason@...
    \__ http://www.sunflower.com/~jmunro/

Re: [SM-DEVEL] Spamcop Problem

[Marc Groot Koerkamp <marc@it...>]

> Jeff Grossman wrote:
>> I am running the CVS for 1.3.2 from 9/13 and get the following error
> when I
>> try and send an e-mail using the Spamcop plugin:
>>
>>
>> ERROR : Bad or malformed request.
>> Query:
>> Server responded: Bogus sequence in FETCH
>>
>> Any ideas?
>
> I was having the same problem until I disabled UID support. It's option 15
> in the "General Options" section of the SquirrelMail Config tool. This
> also fixed spam filtering, which was apprently having the same problem.
>
> Of course, this was in 1.3.1, so it's possible that the problem in 1.3.2
> could be something else, but give this a shot anyway.
>
Could you checkout cvs?

I just submitted a UID related fix to spamcop.

Thnx for pointing at the bug.

Regards,


Marc Groot Koerkamp


>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> --
> squirrelmail-devel mailing list
> List Address: squirrelmail-devel@...
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs
>

Re: [SM-DEVEL] Take Address Plugin

[Marc Groot Koerkamp <marc@it...>]

> Jeff Grossman said:
>> I am using the 1.3.2 CVS from 9/13/02, what take address plugin works?
>> I have the abook_take and address_add.  The address_add plugin does not
>> seem to do anything.
>> Thanks,
>> Jeff
>> --
>> Jeff Grossman (jeff@...)
>
> Address Add does not currently work in DEVEL-CVS, I have the fix for it,
> just waiting to get a few more things done with it before I upload it.
>
> Jimmy

Could you consider a sophisticated fix with nice small buttons next to "To",
Cc and Bcc?
Also keep in mind that devel stores the addresses in the address class. Make
use of it because it split the personal name, the mailbox and the domain name.

Just pass the rfc822_header to your plugin and extract the addresses overthere.

Maybe devel should consider to adopt it in core.

What does the rest of the developers think?

Marc Groot Koerkamp.

>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> --
> squirrelmail-devel mailing list
> List Address: squirrelmail-devel@...
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs
>

Re: [SM-DEVEL] Take Address Plugin

[Jimmy Conner <jimmy@ad...>]

Jeff Grossman said:
> I am using the 1.3.2 CVS from 9/13/02, what take address plugin works?
> I have the abook_take and address_add.  The address_add plugin does not
> seem to do anything.
> Thanks,
> Jeff
> --
> Jeff Grossman (jeff@...)

Address Add does not currently work in DEVEL-CVS, I have the fix for it,
just waiting to get a few more things done with it before I upload it.

Jimmy

Re: [SM-DEVEL] Spamcop Problem

[Ryan Grove <ryan@wo...>]

Jeff Grossman wrote:
> I am running the CVS for 1.3.2 from 9/13 and get the following error
when I
> try and send an e-mail using the Spamcop plugin:
>
>
> ERROR : Bad or malformed request.
> Query:
> Server responded: Bogus sequence in FETCH
>
> Any ideas?

I was having the same problem until I disabled UID support. It's option 15
in the "General Options" section of the SquirrelMail Config tool. This
also fixed spam filtering, which was apprently having the same problem.

Of course, this was in 1.3.1, so it's possible that the problem in 1.3.2
could be something else, but give this a shot anyway.

-- 
Ryan Grove
ryan@...
http://wonko.com/

[SM-DEVEL] Spamcop Problem

[Jeff Grossman <jeff@st...>]

I am running the CVS for 1.3.2 from 9/13 and get the following error when I
try and send an e-mail using the Spamcop plugin:


ERROR : Bad or malformed request.
Query:
Server responded: Bogus sequence in FETCH

Any ideas?

Thanks,
Jeff

-- 
Jeff Grossman (jeff@...)

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Jason Munro <jason@st...>]

> I think that if you checked with people who have been on this team for a
> significant period of time, you would discover that this is NOT my
> approach.

Ummm... Thijs has been here since before me I think and that was a year
ago anyway. Is that not a significant period?

>> I can't use the CVS version anymore because I can't even login.
>> Again, any more of this non-discussion-paul-says-so-so-just-do-it
>> stuff and I'm gone.
>
> I think that you need to consider your attitude about this, Thijs. My
> question is whether you are in this all for your good, or for the good
> of SquirrelMail.

 OUCH. I don't think that is a fair accusation. The issue is not that dev
CVS is unusable, it's that Thijs felt is was unusable because you wanted
code in place without discussion (I am not saying that is true, just that
was the perception of truth)

> And, just for the record, CVS isn't there for YOUR personal
> convenience. It is there for the greater benefit and future of
> SquirrelMail.

 And many improvements in the code are there because of Thijs. Not because
he wanted them, but because he actually helps out on the sf bugtracker.

> I am sorry for your frustration. I hope that you can come to
> understand the dynamics going on here a little better and remain an
> active member of the team.
>

Agreed. Thijs is a valuable member of this team. I review all CVS changes
and all bugtracker updates at sourceforge and would be very sad to see him
go, and really upset to see him go under circumstances born out of
mis-communication.


 \___ Jason Munro
  \___ AIM:jmunr0
   \__ jason@...
    \__ http://www.sunflower.com/~jmunro/

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Thijs Kinkhorst <lists@ki...>]

>I think that you need to consider your attitude about this, Thijs. My
>question is whether you are in this all for your good, or for the good
>of SquirrelMail.

Thank you Paul for pointing that out. I'm sorry, this was all a big 
misconception by me, I thought I could abuse this project for my own good. 
But as it seems not, I have nothing to do here. My mistake, sorry to have 
bothered you.


Thijs

[SM-DEVEL] Recent problem with folder list

[Forrest Aldrich <forrie@fo...>]

Since a week or so ago, the current CVS version is generating this error in 
the folder list:

ERROR : Could not complete request.
Query:STATUS "Mail/Read Mail 0602" (UNSEEN)
Reason Given: STATUS failed: Can't get status of mailbox Mail/Read Mail 
0602: no such mailbox

The mailbox does exist and the permissions are exactly the same as 
everything else; I tried refreshing, but get the same problem.  CVS is 
updated with -d.



Forrest

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Paul Joseph Thompson <captbunzo@sq...>]

Thijs. I very much regret having this conflict with you as, unlike
most of the other developers (I believe), I have never had the chance
to get to know you much (via ICQ, IRC, phone, personal email, etc).
And I hate to get started off on the wrong foot.

Oh well, hopefully we can get this worked out and take it from there.

> I agree with Marc and disagree with you. Paul is the team
> leader, true. That does not mean that things should go like
> this:
>
>   - Paul thinks something should be changed
>   - Paul demands that things go that way
>   - Things go that way

I think that if you checked with people who have been on this team for
a significant period of time, you would discover that this is NOT my
approach.

> My opinion is that this is how it should go:
>
>   + Someone (perhaps Paul) thinks something should be changed
>   + It is proposed to the list (<-- important for changes with
>     large implications)
>   + Paul decides _after discussion_ what the right way to go is

This is exactly the way I think things should go as well. In fact, the
only modification is the last bit, in that a lot of people around here
know that for various aspects of the project, my stamp of approval is
not required.

Marc has been working on Mail stuff. He is free to work on that, tweak
it, experiment with things, etc, without asking me about every little
thing.

Philippe has done a lot of work on i18n issues that I have had NOTHINg
to do with because he is a LOT more of an expert in that area.

Etc

> I think your idea of ruling out all discussion is a very bad one
> and if it goes through I'm out of here.

Thijs, that is NOT AT ALL what Rick suggested. His, and my, complaint
was with Marc stating that he was going to start making certain
changes in CVS AGAINST the wishes of those in charge.

That action is not working as a team and would definately require some
sort of action. Obviously, we HAVE to progress as a development team
TOGETHER. Anyone taking such actions would be diverting from the good
of the team as a whole.

> The team leader should be
> someone who finalises things that the majority agrees on.. not
> someone who passes down instructions when he likes to. I haven't
> seen any discussion about this issue on the list - just Paul who
> is breaking CVS and plugins without even announcing the change.

Read the mail archives better. As I state in my previous email, the
topic WAS discussed previously on the list. I left an appropriate
window for discussion, and after having recieved only positive input,
moved ahead.

> I can't use the CVS version anymore because I can't even login.
> Again, any more of this non-discussion-paul-says-so-so-just-do-it
> stuff and I'm gone.

I think that you need to consider your attitude about this, Thijs. My
question is whether you are in this all for your good, or for the good
of SquirrelMail.

I know where my loyalties lie and, no matter what, reasonably
speaking, I plan to stick by what we are doing with SquirrelMail.

And, just for the record, CVS isn't there for YOUR personal
convenience. It is there for the greater benefit and future of
SquirrelMail.

I remember when (maybe Marc) was working on the UID stuff initially.
There were MANY times that I did my standard cvs update and discovered
that someone had broken it.

However, I was ok with that because I understood that PROGRESS WAS
BEING MADE. Same story goes here.

I am sorry for your frustration. I hope that you can come to
understand the dynamics going on here a little better and remain an
active member of the team.

-- 
Paul Joseph Thompson
captbunzo@...
AIM/Yahoo/MSN IM: Captain Bunzo
ICQ Number: 38801719

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Marc Groot Koerkamp <marc@it...>]

> Marc Groot Koerkamp said:
>>
>> You completely missed the point. I only want to fix things at plugin
>> level! (in the plugin I submitted)
>
>> I don't fight the sollution. I only fight the sollution at plugin-level.
>> Plugins are not SM but pieces of code that can cooperate with SM.
>> SM leads plugins follows.
>>
>> If SM changes then developers adapt those changes in the plugins in such
>> a way that those plugins work again.
>
>
> Problem is, Marc, your submitted plugin is now part of the Squirrelmail
> base (since it's shipped as part of squirrelmail, even though its use is
> optional) - so yes, if you have major problems with the way things are,
> then you *could* consider yanking it from CVS and releasing your own
> version that works..EXCEPT that by submitting it, you made it part of the
> Squirrelmail base, which means the rest of us (who would now help to
> maintain that plugin,  since it's part of the standard distribution),
> would have to agree that it was not something that we thought should be
> included.

It's not part of SM 1.3.1 and only part of SM 1.3.2 CVS
But nevermind somebody will fix the data_dir thing.
(I'm off for the weekend so let see what monday cvs will bring us :-) )

>
> In my opinion, the message_details plugin is one I think we SHOULD always
> ship. So I disagree with your removing it (since I like it so much).

:-)

>
> And, if we work towards fixing the data_dir, the plugins will work again..
>
> :-P
Probably it will. The discussion was only to illustrate the way I see plugins
and SM-core. (and to explain myself)


Marc.

>
>
> Erin
> (sizzle)
>
> --
> Waste of a good apple. - Samwise Gamgee
> ICQ: 36870353
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> --
> squirrelmail-devel mailing list
> List Address: squirrelmail-devel@...
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs
>

[SM-DEVEL] Take Address Plugin

[Jeff Grossman <jeff@st...>]

I am using the 1.3.2 CVS from 9/13/02, what take address plugin works?  I
have the abook_take and address_add.  The address_add plugin does not seem
to do anything.  The abook_take has a link at the bottom of each e-mail, but
it never puts the e-mail address in the drop down list for e-mails.

Thanks,
Jeff
-- 
Jeff Grossman (jeff@...)

Re: [SM-DEVEL] SM_PATH and Developer Communication

[Marc Groot Koerkamp <marc@it...>]

>> If my plugin is still broken after the weekend I put chdir
>> back in and I don't care if it isn't allowed by you.
>
> Marc - if you put chdir and undo AGAIN my SM_PATH stuff, I WILL remove
> your CVS access. Not because I am a dictator and have to get my way,
> but because of the way you are going about things.
>
> And a note to ALL developers, I don't want ANYONE to decide to just go
> and change something substantial in CVS without discussing it on the
> list in general first. That includes SM_PATH and chdir.
>
> Now, before you (Marc) OR anyone else goes off at me, let me explain
> some things and talk for a bit.
>
> I have a REAL PROBLEM with the way some interaction has recently been
> occuring in the development team. Obviously I am frustrated with some
> of Marc's actions. There might be some other people involved in this
> as well, but I am not sure - I would have to check CVS commit history,
> etc, to pin this down more. But that probably isn't important. I think
> we all know what parts we have played in this all.

I remember a discussion we had before about breaking code and fixing it.
That is what happened. You broke something I fixed it at plugin-level to get
the thing working again.
Just like you want (except in this case :-) )
I realy thought that I did something good because I fixed your bugs.
Apperrently you weren't happy with the fix. That's ok but come with a better
fix instead of brake it again.

You also said you didn't thought about the data_dir stuff. Thnx to this
discussion you know and finally came with a sollution (on ICQ)

You mention my name everytime but if you check out the cvs-logs you would see
that i didn't do much cvs changes, I stopped after you did the rollback.


>
> However, let's try REAL HARD to work some things out here. The last
> thing I want is a pile of angry and/or annoyed developers. The last
> thing the team needs is for valuable members to start turning on each
> other.
>
I'm not angry, i just saying what i think. Let's play development again :-)


> NOTE that I am SPECIFICALLY going to NOT discuss any technical issues
> in this email because I believe getting team issues resolved is a much
> higher priority.
>
> Ok. Back to the topic at hand.
>
> A very important aspect of this team is good, open communication. As
> long as I have been a part of the project (user, developer, and lead),
> we have had a very open hand about allowing people write access to
> CVS.
>
> There are obviously a lot of pros and cons to this, all of which are
> another topic.
>
> However, what IS relevant at the moment is that this open hand toward
> CVS write access REQUIRES good communication to developers about what
> we are working on, etc.
>
> There is NOBODY on the team that is an island. Nobody should act as if
> they are developing on their own and that they can do what they please
> with SquirrelMail.
>
> That is exactly what I feel that you, Marc, have accidentally been
> doing about this whole thing. IMHO, you handled this whole situation
> entirely wrong.
>
I'm certainly NOT on an Island. I discuss most things with you and you know that.
Maybe something went wrong because I don't see it as a big development change
but as a minor thing for the devel branche. (SM_PATH). Big changes are always
discussed with you and previously with Wouter.

> Just for the record, before accusations start flying at ME for not
> communicating, note that I brought up the SM_PATH/chdir stuff on the
> list at about a week or two or so ago. A group of us discussed it on
> the list. I SPECIFICALLY asked for input, objections, etc.
>
> Then I PURPOSEFULLY gave a reasonable timeframe for the topic to sit
> before I went after implementing it.
>
> When after a week or so, all comments had been positive, I put it in
> place in CVS. Yes, it required a lot of changes. Yes, it broke plugins
> - however, I knew that it would.
>
> As for the data_dir problem, that was an unexpected side effect.
> However, that does NOT mean that the change is bad. We'll work that
> out in another thread.
>
> The next thing I know, I turn around a couple of days later and find
> out that some of the things that I had implemented that had been
> SPECIFICALLY discussed on the list had been undone by a variety of
> developers.
>
> Was this discussed first?
>
> No.
>
> Whas the issue brought up and sufficient time given for the team to
> decide what the RIGHT way to fix it was?
>
> No.
>
> None of the above. So, yes, I went BACK in and put it back to the way
> I had originally coded things.
>
First you forgot the plugin directory. We adapted the changes you made to the
location of validate and put in SM_PATH. You can check the cvs for that.
Second after you run over the plugins (after we did) you broke some of them.
What did we do ... Yesss we fixed the plugins again. (no problem yet) and
commented why certain changes are made (read the comments by the cvs updates)

Do you realy think that the changes that were made to the plugins should be
discussed on devel first?

Where is the line? what fixes should be discussed first.


> My problem here is that when things come up, they MUST be discussed by
> the development team as a whole when fixes are needing to be made.

> Sure, simple things that don't effect big changes we have been talking
> about on the list may not require this level of effort.

That's exacly what happened here!


>
> However, when we have SPECIFICALLY been talking about something, don't
> just go BORK things over in main CVS because you are impatient with
> the REAL fix.
>
> Let me set things straight here, just for the record:
>
>   1. Development CVS does NOT have to work at all times. In fact,
>      by the nature of the beast, there are times that it is OK for
>      it to be broken. Sometimes cleaning code up requires a little
>      breaking in the mean time.
>
>   2. A continuation of that, sometimes it is good to make some
>      changes (cleanup) that PURPOSEFULLY breaks things. Sometimes
>      "making the break" is the ONLY way to reveal the problems.
>
> And some last comments.
>
> Marc: I value you as a part of the team. I appreciate and recognize
> all the hard work and many GREAT improvements you have made to
> SquirrelMail since you have been a part of things here. However, you
> have to learn how to play nice with an Open Source team. That means
> communicating about these things BEFORE you go and do them.
I like open source and I like open discussion.
Believe me I do play nice. My reaction maybe became less nice because you
weren't playing nice. I realy tried to explain to you why some changes were
made to SM-plugins. (So did others) After you ignored those explanations I got
a bit frustrated and I think in this case it's very human.

So I do not know if it's my way of communicating with the Open Source Theme
which is not appreciated or that you also have some responsability on that
point.


>
> As for everyone else, feel free, as ALWAYS, to lend your comments,
> advice, criticism, input, whatever, etc, etc, etc. I am, as ALWAYS,
> open to input, etc.

Very good !!!


Regards,

Marc Groot Koerkamp

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Erin Schnabel <sizzle@ha...>]

Marc Groot Koerkamp said:
>
> You completely missed the point. I only want to fix things at plugin
> level! (in the plugin I submitted)

> I don't fight the sollution. I only fight the sollution at plugin-level.
> Plugins are not SM but pieces of code that can cooperate with SM.
> SM leads plugins follows.
>
> If SM changes then developers adapt those changes in the plugins in such
> a way that those plugins work again.


Problem is, Marc, your submitted plugin is now part of the Squirrelmail
base (since it's shipped as part of squirrelmail, even though its use is
optional) - so yes, if you have major problems with the way things are,
then you *could* consider yanking it from CVS and releasing your own
version that works..EXCEPT that by submitting it, you made it part of the
Squirrelmail base, which means the rest of us (who would now help to
maintain that plugin,  since it's part of the standard distribution),
would have to agree that it was not something that we thought should be
included.

In my opinion, the message_details plugin is one I think we SHOULD always
ship. So I disagree with your removing it (since I like it so much).

And, if we work towards fixing the data_dir, the plugins will work again..

:-P


Erin
(sizzle)

--
Waste of a good apple. - Samwise Gamgee
ICQ: 36870353

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Marc Groot Koerkamp <marc@it...>]

> Marc Groot Koerkamp wrote:
>>
>> > Ok folks. Some of you guys haven't got the point yet about SM_PATH -
>
> snip...captbunzo does not want pople reversing SM_PATH changes in CVS...
>
>> > Any questions? Ask.
>>
>> Yes, did you read my reply to the other mail you sent?
>>
>> If you did, you must have seen the explanation why SM_PATH breaks plugins.
>>
>
> snip...Marc wants to undo SM_PATH changes in CVS because some
> plugins broke...

You completely missed the point. I only want to fix things at plugin level!
(in the plugin I submitted)


> There was long discussion on this list around august 28; any
> complains should probably have been made then (and a solution
>  agreed upon), instead of backing out changes in CVS
>
>
I don't fight the sollution. I only fight the sollution at plugin-level.
Plugins are not SM but pieces of code that can cooperate with SM.
SM leads plugins follows.

If SM changes then developers adapt those changes in the plugins in such a way
that those plugins work again.

Marc.
>
> /magnus
>
>>
>> Regards,
>>
>> Marc Groot Koerkamp
>>
>> >
>> > --
>> > Paul Joseph Thompson
>> > captbunzo@...
>> > AIM/Yahoo/MSN IM: Captain Bunzo
>> > ICQ Number: 38801719
>> >
>> >
>> > -------------------------------------------------------
>> > This sf.net email is sponsored by:ThinkGeek
>> > Welcome to geek heaven.
>> > http://thinkgeek.com/sf
>> > --
>> > squirrelmail-devel mailing list
>> > List Address: squirrelmail-devel@...
>> > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>> > http://squirrelmail.org/cvs
>> >
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> --
>> squirrelmail-devel mailing list
>> List Address: squirrelmail-devel@...
>> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>> http://squirrelmail.org/cvs
>

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Marc Groot Koerkamp <marc@it...>]

>>> No one wants you to become disillusioned and leave or stop
>>> work on the project... but if you directly ignore the team
>>> leader's direction *not* to add chdir back into the code, I
>>> wouldn't be surprised if your CVS permissions were revoked
>>> until the issue is resolved.
>>
>> That's a very bad way to deal with discussions about non
>> working code. I'm glad you're not the teamleader.
>>
>> If you were, I wouldn't be here.
>
> To simple comments - I don't want this to turn into a flame war.
> (Though it is true we haven't had a good flame war around here in a
> while.... :)
>
> First, I don't think you have any right, Marc, to critisize revoking
> CVS access as a way of dealing with something when you are telling us
> that you are going to start making changes in CVS REGARDLESS of what
> the leader of the team you are on says.
>
I was talking about changes in a plugin I submitted to CVS. Should I just
delete it and release it on my own?

I do make a difference between SM and the plugin directory.
If a plugin is part of SM then don't call it a plugin and put it in the source
of SM.
I did critisize him because I don't like non-democratic methods.
SM with developers as puppets isn't what we want.

About new leadership and Rick, I don't know him what else can I say.
I also didn't knew that the old leader chooses the new leader.
(also not very democratic)

Marc Groot Koerkamp

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Magnus Stenman <stone@hk...>]

Marc Groot Koerkamp wrote:
> 
> > Ok folks. Some of you guys haven't got the point yet about SM_PATH -

snip...captbunzo does not want pople reversing SM_PATH changes in CVS...

> > Any questions? Ask.
> 
> Yes, did you read my reply to the other mail you sent?
> 
> If you did, you must have seen the explanation why SM_PATH breaks plugins.
> 

snip...Marc wants to undo SM_PATH changes in CVS because some
plugins broke...

> Another thing, you are talking about "We are trying to clean up things" but I
> still don't agree with you that SM_PATH is an improvement and cleans up
> things.

There was long discussion on this list around august 28; any
complains should probably have been made then (and a solution
 agreed upon), instead of backing out changes in CVS


> If it works, okay but since it breaks plugins it doesn't clean up anything.
> You think it cleans up SM but probably the rest which copes with broken
> plugins don't.
> In my opinion cleaning up SM is finding a better dynamic architecture and
> recode not well coded parts of code. Just some syntaxing changes doesn't help
> us.
> 
> Strickly spoken plugins are not part of SM and just are located in the plugins
> directory so developers can fix them if there are bugs.
> My plugin message_details is also there because it saves me a lot of trouble
> making new releases everytime when SM changed.
> I wasn't aware that putting my plugin in there also mean that I have to follow
> YOUR coding standard.

If plugins do not follow any form of coding standard or API it
will be very messy to maintain them.


Look at the Linux kernel; modules accepted into the kernel gets
fixed by maintainers if the API changes, those outside might
break, and the authors will have to fix them.


Abandoned plug-ins needs to be dropped or included into core sooner
or later or else SM can never move forward. APIs change.

> 
> If my plugin is still broken after the weekend I put chdir back in and I don't
> care if it isn't allowed by you.

Stuff like this must be resolved without CVS commit wars...


/magnus

> 
> Regards,
> 
> Marc Groot Koerkamp
> 
> >
> > --
> > Paul Joseph Thompson
> > captbunzo@...
> > AIM/Yahoo/MSN IM: Captain Bunzo
> > ICQ Number: 38801719
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > --
> > squirrelmail-devel mailing list
> > List Address: squirrelmail-devel@...
> > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> > http://squirrelmail.org/cvs
> >
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> --
> squirrelmail-devel mailing list
> List Address: squirrelmail-devel@...
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs

Re: [SM-DEVEL] SM_PATH and Developer Communication

[Peter R. Wood <lists@pr...>]

Hi Guys,

All arguments aside, as someone who is following the CVS tree and
contributing bug reports here and there, I have to say SquirrelMail is
still the most pleasant email experience I have ever had. I love reading
and sending emails with SquirrelMail. :-)

Keep up the good work, and let's all work together to build a better webmail.

Peter
SquirrelMail User and Tester

-- 
Peter R. Wood - prw@... - http://prwdot.org/

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Paul Joseph Thompson <captbunzo@sq...>]

>> No one wants you to become disillusioned and leave or stop
>> work on the project... but if you directly ignore the team
>> leader's direction *not* to add chdir back into the code, I
>> wouldn't be surprised if your CVS permissions were revoked
>> until the issue is resolved.
>
> That's a very bad way to deal with discussions about non
> working code. I'm glad you're not the teamleader.
>
> If you were, I wouldn't be here.

To simple comments - I don't want this to turn into a flame war.
(Though it is true we haven't had a good flame war around here in a
while.... :)

First, I don't think you have any right, Marc, to critisize revoking
CVS access as a way of dealing with something when you are telling us
that you are going to start making changes in CVS REGARDLESS of what
the leader of the team you are on says.

I don't ever want to come across as strutting the fact that I am "in
charge" (hahaha*) around here, but the fact is you just can't do that
in the Open Source world (or anywhere).

Second, Rick is a great guy. He is EXACTLY the kind of person I think
would make an excellent leader of an Open Source project. He is one of
the few people that I go to for advice, accountablity, and input for
the way that I lead/manage/etc this team.

If I was in a position some day to turn over the project to someone
else, Rick would be on my list of people to consider. (Watch it, punk,
Rick. :)

* I laugh about me being "in charge" because I realize so SEVERELY how
many people make this project what it is. There is such a pile of
developers, translators, and fellow leaders who make up this team,
that I couldn't possibly think of myself too highly about this all.

-- 
Paul Joseph Thompson
captbunzo@...
AIM/Yahoo/MSN IM: Captain Bunzo
ICQ Number: 38801719

Re: [SM-DEVEL] Another Visit to SM_PATH and chdir

[Erin Schnabel <sizzle@ha...>]

The real problem here is the handling of the data_dir.

So, I propose:

That we change the way the data_dir value is stored after it is entered
via conf.pl so that we always write/store the full path.

The point of the SM_PATH changes is to make it easier to reference other
files without the included file having to worry so much about where the
"caller" resides.  When we had those discussions, I voiced an opinion
against a variable containing the root path because I wanted to be able to
move squirrelmail around (if I felt like it), without having to remember
to go and fix that full path variable. And in the end, we decided the
SM_PATH variable worked out better anyway.

NOW, if we store only the full path to the data/attachments directories,
we'll break that very requirement of mine. However, I place my
data/attachments directories outside of my SM tree, in /var/spool. I
always specify a full path, and it is independent of where squirrelmail,
itself, lives.

There is an argument to be made here for also changing the default,
recommended, path to be somewhere else (like /var/spool/sm_attach or
something) - there are good security reasons to not have variable data
(like preferences or the dynamic uploaded attachments) to be contained
within your squirrelmail installation... but I don't know how many others
agree.

So anyway, the first suggestion is made. Debate away.

Erin
(sizzle)

--
Waste of a good apple. - Samwise Gamgee
ICQ: 36870353

[SM-DEVEL] SM_PATH and Developer Communication

[Paul Joseph Thompson <captbunzo@sq...>]

> If my plugin is still broken after the weekend I put chdir
> back in and I don't care if it isn't allowed by you.

Marc - if you put chdir and undo AGAIN my SM_PATH stuff, I WILL remove
your CVS access. Not because I am a dictator and have to get my way,
but because of the way you are going about things.

And a note to ALL developers, I don't want ANYONE to decide to just go
and change something substantial in CVS without discussing it on the
list in general first. That includes SM_PATH and chdir.

Now, before you (Marc) OR anyone else goes off at me, let me explain
some things and talk for a bit.

I have a REAL PROBLEM with the way some interaction has recently been
occuring in the development team. Obviously I am frustrated with some
of Marc's actions. There might be some other people involved in this
as well, but I am not sure - I would have to check CVS commit history,
etc, to pin this down more. But that probably isn't important. I think
we all know what parts we have played in this all.

However, let's try REAL HARD to work some things out here. The last
thing I want is a pile of angry and/or annoyed developers. The last
thing the team needs is for valuable members to start turning on each
other.

NOTE that I am SPECIFICALLY going to NOT discuss any technical issues
in this email because I believe getting team issues resolved is a much
higher priority.

Ok. Back to the topic at hand.

A very important aspect of this team is good, open communication. As
long as I have been a part of the project (user, developer, and lead),
we have had a very open hand about allowing people write access to
CVS.

There are obviously a lot of pros and cons to this, all of which are
another topic.

However, what IS relevant at the moment is that this open hand toward
CVS write access REQUIRES good communication to developers about what
we are working on, etc.

There is NOBODY on the team that is an island. Nobody should act as if
they are developing on their own and that they can do what they please
with SquirrelMail.

That is exactly what I feel that you, Marc, have accidentally been
doing about this whole thing. IMHO, you handled this whole situation
entirely wrong.

Just for the record, before accusations start flying at ME for not
communicating, note that I brought up the SM_PATH/chdir stuff on the
list at about a week or two or so ago. A group of us discussed it on
the list. I SPECIFICALLY asked for input, objections, etc.

Then I PURPOSEFULLY gave a reasonable timeframe for the topic to sit
before I went after implementing it.

When after a week or so, all comments had been positive, I put it in
place in CVS. Yes, it required a lot of changes. Yes, it broke plugins
- however, I knew that it would.

As for the data_dir problem, that was an unexpected side effect.
However, that does NOT mean that the change is bad. We'll work that
out in another thread.

The next thing I know, I turn around a couple of days later and find
out that some of the things that I had implemented that had been
SPECIFICALLY discussed on the list had been undone by a variety of
developers.

Was this discussed first?

No.

Whas the issue brought up and sufficient time given for the team to
decide what the RIGHT way to fix it was?

No.

None of the above. So, yes, I went BACK in and put it back to the way
I had originally coded things.

My problem here is that when things come up, they MUST be discussed by
the development team as a whole when fixes are needing to be made.
Sure, simple things that don't effect big changes we have been talking
about on the list may not require this level of effort.

However, when we have SPECIFICALLY been talking about something, don't
just go BORK things over in main CVS because you are impatient with
the REAL fix.

Let me set things straight here, just for the record:

  1. Development CVS does NOT have to work at all times. In fact,
     by the nature of the beast, there are times that it is OK for
     it to be broken. Sometimes cleaning code up requires a little
     breaking in the mean time.

  2. A continuation of that, sometimes it is good to make some
     changes (cleanup) that PURPOSEFULLY breaks things. Sometimes
     "making the break" is the ONLY way to reveal the problems.

And some last comments.

Marc: I value you as a part of the team. I appreciate and recognize
all the hard work and many GREAT improvements you have made to
SquirrelMail since you have been a part of things here. However, you
have to learn how to play nice with an Open Source team. That means
communicating about these things BEFORE you go and do them.

As for everyone else, feel free, as ALWAYS, to lend your comments,
advice, criticism, input, whatever, etc, etc, etc. I am, as ALWAYS,
open to input, etc.

-- 
Paul Joseph Thompson
captbunzo@...
AIM/Yahoo/MSN IM: Captain Bunzo
ICQ Number: 38801719