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

[Chris Weiss]

Lets make a list of bugs in .14 email and Angles can backport only those things
that fix the bugs.  Would this be acceptable to the rules?  I think we'll find 
that
only 2 peices get left out though, the filters and maybe the raw email viewing.
Every other feature exsits in .14 but doesn't work right.

I don't want to rework the rules, I understand them and think them a good thing.
What I'm trying to help people understand is that most of what Angles has done 
in
HEAD since the branch is nothing more than bug fixes to .14, and none of it is 
in
the API.

Chris

Miles Lott (address@hidden) wrote*:
>
>This all started with a set of rules with which most of
>seem to agree.  Some of these are in etiquette.txt.  Others
>are implied, understood by osmosis, or stated within the
>flow of this mailing list.
>
>The problem came about when new features were added to
>the .12 stable branch during the testing phase prior to
>release.  This was done before and after requests not to
>do this from at least two of the project admins on this list
>and by yourself to angles in private email.
>
>Now, there is an attempt being made to rework the rules in
>the court of public opinion.  If this works now for the second
>time, it is apparent that this will become standard operating
>procedure.
>
>If such complete disregard for established rules is to be the
>norm here, then let us either rethink the rules or get rid of
>them.  Since most of us do abide by these rules and find them
>acceptable, the alternative of active enforcement of these
>rules seemed a better choice.
>
>Also, it has been stated previously that we should have shorter
>development and release cycles.  In light of this, a feature
>freeze was announced roughly 5 months after the last release.
>The branch was actually made 3-4 days later.  In the feature
>freeze announcement, a call to announce new features was made.
>The idea here was that developers could state that there was
>new feature 'x' that was almost completed and would be introduced
>into the stable branch.  It has now been a month since the
>branch was created.
>
>So much was added to the core of phpGroupWare in this 5 month
>period that deserves more scrutiny than any other single app.
>XML-RPC and the new setup program are a couple of the more
>major ones.  This was also volunteer work, btw.
>
>If it is not the fear that we will take another 6 months for
>the next release driving this rush to include more features
>into the stable branch, then what is it?  Lets just get this
>puppy out the door and create a pl1 soon after if we must.
>
>As for continuing discussion on who said what when, let's not
>and say we did.
>
>
>"Dan Kuykendall (Seek3r)" wrote:
>>
>> 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
>>
>> _______________________________________________
>> Phpgroupware-developers mailing list
>> address@hidden
>> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>
>--
>
>Miles Lott - phpGroupWare
>http://www.phpgroupware.org
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>