Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of marcus.mail@wtnet.de
 designates 213.209.103.3 as permitted sender)
Message-ID: <4E634D54.3010909@wtnet.de>
Date: Sun, 04 Sep 2011 12:05:08 +0200
From: "Marcus (OOo)" <marcus.mail@wtnet.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
 rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: OpenOffice most annoying bugs
References: <1315070632.66676.YahooMailClassic@web113512.mail.gq1.yahoo.com>
In-Reply-To: <1315070632.66676.YahooMailClassic@web113512.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 09/03/2011 07:23 PM, schrieb Pedro F. Giffuni:
>
> --- On Sat, 9/3/11, Rob Weir<robweir@apache.org>  wrote:
> ...
>> On Sat, Sep 3, 2011 at 8:42 AM, Pedro F. Giffuni wrote:
>>> Hi Marcus;
>>>
>>> The exact flag in bugzilla is 3.4_release_blocker.
>>>
>>> Not including *ALL* these 24 bugs for the next
>> release
>>> would be like saying to our contributors that we
>> don't
>>> care about them. We are talking about people that
>>> spent *their* time coding and gave the preference
>>> to contribute to OpenOffice that would now see that
>>> their are efforts better appreciated elsewhere.
>>>
>>
>> I think we should classify the bugs based on their impact
>> on the product, not on the identity of the person who
>> submitted the patch.
>
> I never did detail identities of contributors. I do think
> it's important that they contain code: either by the
> submitter or by someone else that found the issue
> important enough to take the time to fix it.
>
> The "impact on the product" is something subjective that
> ultimately depends on the impact to the end-user, and
> here we have users solving their own problems.
>
> This is about meritocracy and community building too:
> one unsatisfied developer can cause huge damage to a
> project. I'll give you two real immediate examples:
>
> Example 1:
> - A posting in LO mailinglist from Sept 2010 says:
> "Creating a 'bug' saw no action in 3 years....
> Here is hoping that posting the patch to this
> new project will :-)"
> (There goes one developer that will probably
> think it twice before submitting new patches here)

Sorry, clearly not a stopper for me. It doesn't fix a bug but introduce 
a new feature. This shouldn't be a stopper candidate.

> Example 2:
> Bug 7065 (Which Marcus considers not to be a
> showstopper) says in 2003:
> "I think it is a mistake to future this bug. Page
> numbering is a very important function of all
> worprocessing software and its discoverability must
> at least be increased."

When an issue is open und unsolved since 2003 then it is sad. No doubt. 
However, it's still not an issue that should suddenly stop a release.

> And after that there are 13 issues closed as
> duplicates to this same bug.
>
> Yes, someone has to review the patches, and the applied
> fixes won't necessarily match the submitted diffs or what
> LibreOffice committed but we do have a good starting
> point to fix these issues and the wider community has
> seen a value in fixing them so I do think they have a
> higher priority.

Yes and no. It doesn't depend from where the issue or patch comes or how 
old it is. It's about the issue itself, what part of the application it 
covers and its severity.

When it fixes a highly annoying problem that many users complain about 
and the fix is easy and with no risk to damage other things and it comes 
in time and not 2 days before release, then OK maybe it's a stopper 
candidate.

But if not please lets sort it in for the next release.

> This is all just IMHO of course, and I am biased as it
> took some hours to dig through the archives and look at
> all the Bug reports.

Of course, the same for my statements. ;-)

Marcus