On Thu, Oct 22, 2015 at 12:34:01AM +0100, Guillaume Munch wrote:
> Le 20/10/2015 20:47, Liviu Andronic a écrit :
> >
> >I think #1 is more or less what we have now, slightly simplifying the
> >way we roll milestones (into the .x stack) or drop milestones
> >altogether ("very" old .x reports can be
Le 20/10/2015 20:47, Liviu Andronic a écrit :
I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important
On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak wrote:
> On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
>> Scott asked not long ago what could be done to make it easier for
>> newcomers. It is now clear to me that having a clearer bug tracker
>> is an aspect that can be improved
On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
> Scott asked not long ago what could be done to make it easier for
> newcomers. It is now clear to me that having a clearer bug tracker
> is an aspect that can be improved. In addition, the initial question
> was to know what to do w
Le 14/10/2015 09:38, Liviu Andronic a écrit :
On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch wrote:
the hard truth is that our manpower is limited and our devels barely
have the bandwidth to address crashes, regressions and the like (in
between monitoring tickets, triaging, helping on the
Le 15/10/15 00:13, Scott Kostyshak a écrit :
The version of trac we use is almost 5 years old now. There have been a
lot of changes since then. I don't think we should update before a major
release, and I don't even know if we have someone who would have the
time and knowledge to do the update. I
On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
> Scott asked not long ago what could be done to make it easier for
> newcomers.
Yes I am interested in this.
> It is now clear to me that having a clearer bug tracker
> is an aspect that can be improved.
Agreed.
> Taking into acc
On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch wrote:
>> the hard truth is that our manpower is limited and our devels barely
>> have the bandwidth to address crashes, regressions and the like (in
>> between monitoring tickets, triaging, helping on the MLs, and
>> implementing things sorely ne
Le 14/10/2015 07:53, Pavel Sanda a écrit :
Guillaume Munch wrote:
I remember putting the remark about low priority in FAQ.
Here's all I could find about "enhancement" or "priority" on Trac, the
website, the wiki and the repository (with git grep):
?Enhancements have low priority and minor sev
Guillaume Munch wrote:
>> I remember putting the remark about low priority in FAQ.
>
> Here's all I could find about "enhancement" or "priority" on Trac, the
> website, the wiki and the repository (with git grep):
>
> ?Enhancements have low priority and minor severity by default. We use
> 'Severity
Scott asked not long ago what could be done to make it easier for
newcomers. It is now clear to me that having a clearer bug tracker
is an aspect that can be improved. In addition, the initial question
was to know what to do with tickets with an unmet milestone.
Taking into account what has been
TL;DR: thank you for your suggestions and criticisms; new propositions
in a separate message.
Le 13/10/2015 02:20, Scott Kostyshak a écrit :
If we do decide to get rid of the 2.2.x milestone, it is easy to do,
rather than if we change our mind from getting rid of it to keeping
it.
Yes, than
On Tue, Oct 13, 2015 at 2:46 AM, Guillaume Munch wrote:
> Le 13/10/2015 00:53, Scott Kostyshak a écrit :
>>
>> On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
>>>
>>> On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote:
>>> The problem with letting community members define what
Guillaume Munch wrote:
> as well. Let us think about this now. First, please, explain to me what the
> milestones ".x" are supposed to mean exactly and I can suggest an
> appropriate change to the tracker page (which may or may not be just "add
> .x milestones to the front page").
z.y.x milesto
On Tue, Oct 13, 2015 at 01:46:26AM +0100, Guillaume Munch wrote:
> Le 13/10/2015 00:53, Scott Kostyshak a écrit :
> >On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
> >>On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote:
> >>The problem with letting community members define wha
Le 13/10/2015 00:53, Scott Kostyshak a écrit :
On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote:
The problem with letting community members define what is important
and what is not, is that for each and every one of us our pe
On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
> On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote:
> The problem with letting community members define what is important
> and what is not, is that for each and every one of us our pet bug is
> the most importantest of 'em all.
Guillaume Munch wrote:
> IMO we shouldn't be shy marking enhancements as high or highest. We should
> stop marking them low just because they are enhancements. The "enhancement"
> tag is already there to indicate that.
To clarify - the coloring scheme currently used dates back to time when I had
On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote:
> Le 11/10/2015 12:19, Liviu Andronic a écrit :
>>
>> This way .x targets are indicative of the relative recent nature of
>> the bug, which is still useful info.
>
>
> It is useful to know if a bug is recent, but we already have the bug # and
Liviu Andronic wrote:
> ALL other bugs fall into two categories: somewhat important if a devel
> is interested in the bug, not important if no one will be bothered to
> address it. This is why I find Guillaume's proposal unworkable, if I
> understood it correctly, in the sense that: How do we defi
Le 11/10/2015 15:27, Guillaume Munch a écrit :
I can apply my proposal to the Trac page right now for you to judge, and
we can revert it if you are not convinced.
...essentially adding at the end of the page:
[[BR]]
== High priority defects ==
[[TicketQuery(order=id,desc=1,format=table,status
Le 11/10/2015 12:19, Liviu Andronic a écrit :
This way .x targets are indicative of the relative recent nature of
the bug, which is still useful info.
It is useful to know if a bug is recent, but we already have the bug #
and often the version, no?
I think that Guillaumes proposal to use
On Sun, Oct 11, 2015 at 11:50 AM, Georg Baum
wrote:
> Liviu Andronic wrote:
>
>> While I understand when people want to remove milestones since "if no
>> one is working on them they're meaningless", I also agree with
>> Guillaume's arguments here: a milestone usually contains some
>> information a
Liviu Andronic wrote:
> While I understand when people want to remove milestones since "if no
> one is working on them they're meaningless", I also agree with
> Guillaume's arguments here: a milestone usually contains some
> information about the bug, its intended scope and its importance. The
> m
.
If we decide to go this way, I could volunteer to keep this
bookkeeping on our Tracker.
Opinions?
Liviu
> The current situation may have something to do with the fact that it is very
> easy to see targeted bugs, but harder to see ones without a milestone,
> regardless of their priority
n may have something to do with the fact that it is
very easy to see targeted bugs, but harder to see ones without a
milestone, regardless of their priority. (“Form is function”)
Refocusing the purpose of milestones can only work if in exchange we
give more importance to the priority field. To
26 matches
Mail list logo
