Re: [Phpgroupware-developers] Re: darn near email done, merge notification

[Dan Kuykendall (Seek3r)]

I have stayed out of this discussion for awhile to see ho it would play
out, and because I have been extremely busy and hadnt had time to read
thru everything. Now that I have I want to say that I am disgusted with
how Angles has been treated on this issue.
Angles has made a mistake in doing this again... trying to squeeze new
features in after the freeze. But some of that is justified, and I will
explain that.
However, I hold my fellow leaders of this project to a higher standard,
and I dont think they have done Angles justice and have disappointed me
in this.

Angles: I apologize that i didnt help jump in on your defense sooner.

First off, I want to remind my fellow leaders that this is a volunteer
effort. Each person works on this app for their own reasons... but
certainly one of them is "appreciation". When that appreciation is not
only not shown, but instead the person gets crapped on, that will
potentially limit their future contributions as well as the future
contributions of others who see that they may get treated the same way
after they work hard to help out. I dont think this is right at all, and
its not how I have lead this project up till now.
Yes we have rearranged the leadership to a "Leadership Team" which is
going to be better for the project, because there will be more diverse
input into the decisions as well as more people to make on the spot
calls. But I will certainly do everything I can to keep this a friendly
and fun project to work on. Hostility will kill this project... I wont
accept that.

Now on the reasons that the new email code is not simply new features,
but can be considered bug fixes, is that when the branch was made their
were tons of non-working hooks in place that will terribly confuse
users. These screens and fields are now working as they should be. These
non/partially-working screens will be considered big huge bugs to users
and will be a cause for confusion. So there are two choices... 1) fix
the screens to make them work, which is what Angles did in the HEAD,  2)
Remove these screens and all links to them, which no one has done.
I would think option 1 has the most benefit, since the code is done, and
I have been using it for awhile now and it works. It gives is a very
nice set of features to brag about and offer to our users. Option 2
would still need to be done, and would remove the chance to offer those
features in this release.

Additionally what Jason wrote (see below) is a very valid point. We
screwed up with the way we announced and created this freeze. It was
basicly announced at the same time the CVS branch was created. We should
have given a little more time for the last minute stuff to be discussed
and decided on before the branch was created so that we would have a
hard list of what was in and what was out.

Now as far as Angles screwing up. He did. He keep waiting too long to
get this code done. Of course we all have things that keep us from
getting everything done, since this is a volunteer effort, but this did
drag out longer than it should have. He knew what happened last time,
and repeated the mistake. I dont think it was worth the hanging he
recieved, but it does screw up release plans and stuff when developers
do this. And, if he did screw up preferences by messing with the api
files instead of doing it all with hooks, then that causes problems that
the core team has ever right to yell and scream about. But the energy
should be directed at "teaching" how to do it right, not lamblasting him
for doing it wrong.

Well, Im sure I have started enough mess for now.

Seek3r

Jason Wies wrote:
> 
> I must misunderstand the nature of a feature freeze.  I thought the process 
> was:
> 
> Announce that there will be a feature freeze
> Code features
> Enact feature freeze and create new branch
> Fix bugs, no new features in the new branch
> 
> In this case, the enacting came three days after the announcement, and the 
> only reason the branch wasn't created as soon was because of the SF->Savannah 
> move.  Are you saying that the process is actually:
> 
> Announce that there will be a feature freeze, enact feature freeze and create 
> new branch
> Add new features
> Create RC, no new features in new branch
> 
> If that's the case, then sorry for bringing it up, but I really thought that 
> when Milosch announced the feature freeze that meant it was time to 
> concentrate on fixing bugs, and save new features for HEAD.
> 
> Jason Wies aka Zone
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers