Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-24 Thread Shaw Andy
 Before the transition to Qt being developed in the open via open governance,
 the Qt Support team back in Trolltech and later Nokia, would prioritize the
 bugs that were created, or at least handled, by them. Typically these would
 be bugs that were brought to our attention by commercial customers using
 Qt. As we know the bug fairly well at this point, and have an understanding
 of the impact it has on applications, then we were in a position to set a
 reasonable priority setting. Since the move to develop in the open via open
 governance, this has not been kept up, as it was back then not desired  that
 the Qt Support team would continue this practice.
 
 What I would like to suggest that we do now is bring back this practice, so
 that the Qt Support team will set a priority on the bugs that it creates or
 handles, so that it makes things easier for the maintainers to actually see
 what issues are potentially a higher priority than the others. And in the case
 of the high priority issues, it will draw attention to them faster rather than
 them being picked up later on in the process. I have also discussed this with
 the developers inside Digia, and they see a need for getting help when
 triaging the bugs, so having the Qt Support team set a priority here would at
 least go some way to helping with that. Of course any priority set by the Qt
 Support team is intended to be a guideline, the maintainer would still be at
 liberty to change it if they disagree.
 
 Is there any comments, thoughts or concerns about this proposal? If I don't
 hear any objections, then we will move ahead with this starting within the
 next week.

I know that there are still side discussions related to this, but there were no 
objections to the support team in Digia at least prioritizing the issues they 
create so we will start doing this as of today.

Regards,
Andy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-22 Thread Vladimir Minenko
On 19.02.13 18:25, Frederik Gladhorn frederik.gladh...@digia.com wrote:
See also my mail from two weeks ago ([Development] issue tracker rights).

I think we need to make a few more adjustments and really need more
people 
with bug triaging rights.

Actually, there is a good reminder, since there were others concerns with
the way how bugs are currently triaged. Peter was commenting about labels,
for example.

I would like to bring up another aspect. We (Qt in BlackBerry) are
strongly considering to move known Qt issues from an internal tracker into
https://bugreports.qt-project.org/ and later on, redirect Qt related
issues reported by BackBerry developers into BlackBerry
https://bugreports.qt-project.org/ as well.

Our motivation for this is very simple: keep Qt bugs going to one place
and avoid fragmentation.

Handling a few BlackBerry related issues which were already posted on
https://bugreports.qt-project.org/, I started doubting if we can really
use https://bugreports.qt-project.org/ for operations. The major problem
is that the only what a normal user do is commenting on bugs. I know this
topic is not directly related to the actual posting by Andy. I just wanted
to raise my hand and underline that there are more triage related problems
with https://bugreports.qt-project.org/

-- 
Vladimir Minenko

Technical Manager, Qt
http://developer.blackberry.com/qt
+49 160 9898 3242


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-22 Thread Michael Hasselmann
On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote:
 Our motivation for this is very simple: keep Qt bugs going to one place
 and avoid fragmentation.

But is that really feasible? You'd have to make sure it's a general Qt
problem first and not related to some interaction with Blackberry
specifics. Or the Qt bugtracker is fine with having vendor-specific
components.

 Handling a few BlackBerry related issues which were already posted on
 https://bugreports.qt-project.org/, I started doubting if we can really
 use https://bugreports.qt-project.org/ for operations. The major problem
 is that the only what a normal user do is commenting on bugs. I know this
 topic is not directly related to the actual posting by Andy. I just wanted
 to raise my hand and underline that there are more triage related problems
 with https://bugreports.qt-project.org/

It would be an interesting experiment to just open up the bug handling
privileges for most JIRA accounts, if not even all. I would assume
people will use their privileges with care although some might start
playing the close/reopen bugs game.

ciao Michael

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-22 Thread Thiago Macieira
On sexta-feira, 22 de fevereiro de 2013 16.18.13, Michael Hasselmann wrote:
 On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote:
  Our motivation for this is very simple: keep Qt bugs going to one place
  and avoid fragmentation.
 
 But is that really feasible? You'd have to make sure it's a general Qt
 problem first and not related to some interaction with Blackberry
 specifics. Or the Qt bugtracker is fine with having vendor-specific
 components.

That's no different from any other bug report where we must determine whether 
the problem lies in Qt code or in the underlying platform (e.g., bionic 
shortcomings), or whether it lies in the application itself or third-party Qt-
based libraries (e.g., kdelibs).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-19 Thread Frederik Gladhorn
Fredag 15. februar 2013 12.47.49 skrev Shaw Andy:
 Hi,
 
 Before the transition to Qt being developed in the open via open governance,
 the Qt Support team back in Trolltech and later Nokia, would prioritize the
 bugs that were created, or at least handled, by them. Typically these would
 be bugs that were brought to our attention by commercial customers using
 Qt. As we know the bug fairly well at this point, and have an understanding
 of the impact it has on applications, then we were in a position to set a
 reasonable priority setting. Since the move to develop in the open via open
 governance, this has not been kept up, as it was back then not desired 
 that the Qt Support team would continue this practice.
 
 What I would like to suggest that we do now is bring back this practice, so
 that the Qt Support team will set a priority on the bugs that it creates or
 handles, so that it makes things easier for the maintainers to actually see
 what issues are potentially a higher priority than the others. And in the
 case of the high priority issues, it will draw attention to them faster
 rather than them being picked up later on in the process. I have also
 discussed this with the developers inside Digia, and they see a need for
 getting help when triaging the bugs, so having the Qt Support team set a
 priority here would at least go some way to helping with that. Of course
 any priority set by the Qt Support team is intended to be a guideline, the
 maintainer would still be at liberty to change it if they disagree.
 
 Is there any comments, thoughts or concerns about this proposal? If I don't
 hear any objections, then we will move ahead with this starting within the
 next week.

See also my mail from two weeks ago ([Development] issue tracker rights).

I think we need to make a few more adjustments and really need more people 
with bug triaging rights.

Greetings
Frederik


 
 Regards,
 Andy
 --
 Andy Shaw,
 Head of Qt Support,
 Digia, Qt
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


[Development] Setting the priority of bug reports created the Qt Support team

2013-02-15 Thread Shaw Andy
Hi,

Before the transition to Qt being developed in the open via open governance, 
the Qt Support team back in Trolltech and later Nokia, would prioritize the 
bugs that were created, or at least handled, by them. Typically these would be 
bugs that were brought to our attention by commercial customers using Qt. As we 
know the bug fairly well at this point, and have an understanding of the impact 
it has on applications, then we were in a position to set a reasonable priority 
setting. Since the move to develop in the open via open governance, this has 
not been kept up, as it was back then not desired  that the Qt Support team 
would continue this practice.

What I would like to suggest that we do now is bring back this practice, so 
that the Qt Support team will set a priority on the bugs that it creates or 
handles, so that it makes things easier for the maintainers to actually see 
what issues are potentially a higher priority than the others. And in the case 
of the high priority issues, it will draw attention to them faster rather than 
them being picked up later on in the process. I have also discussed this with 
the developers inside Digia, and they see a need for getting help when triaging 
the bugs, so having the Qt Support team set a priority here would at least go 
some way to helping with that. Of course any priority set by the Qt Support 
team is intended to be a guideline, the maintainer would still be at liberty to 
change it if they disagree.

Is there any comments, thoughts or concerns about this proposal? If I don't 
hear any objections, then we will move ahead with this starting within the next 
week.

Regards,
Andy
--
Andy Shaw,
Head of Qt Support,
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-15 Thread Alan Alpert
On Fri, Feb 15, 2013 at 4:47 AM, Shaw Andy andy.s...@digia.com wrote:
 Hi,

 Before the transition to Qt being developed in the open via open governance, 
 the Qt Support team back in Trolltech and later Nokia, would prioritize the 
 bugs that were created, or at least handled, by them. Typically these would 
 be bugs that were brought to our attention by commercial customers using Qt. 
 As we know the bug fairly well at this point, and have an understanding of 
 the impact it has on applications, then we were in a position to set a 
 reasonable priority setting. Since the move to develop in the open via open 
 governance, this has not been kept up, as it was back then not desired  that 
 the Qt Support team would continue this practice.

 What I would like to suggest that we do now is bring back this practice, so 
 that the Qt Support team will set a priority on the bugs that it creates or 
 handles, so that it makes things easier for the maintainers to actually see 
 what issues are potentially a higher priority than the others. And in the 
 case of the high priority issues, it will draw attention to them faster 
 rather than them being picked up later on in the process. I have also 
 discussed this with the developers inside Digia, and they see a need for 
 getting help when triaging the bugs, so having the Qt Support team set a 
 priority here would at least go some way to helping with that. Of course any 
 priority set by the Qt Support team is intended to be a guideline, the 
 maintainer would still be at liberty to change it if they disagree.

I assume you mean that any approver would still be at liberty to edit
the priority if they disagree, basically that there's nothing special
about the priority just because it was set by Qt Support.

Then there's just the theoretical problem of non-approvers setting bug
priorities, which is that most people think their bugs are top
priority. I'm pretty sure the Qt Support team is sensible enough that
they don't do that, so I think it would be helpful for them to be
setting (initial) priorities.

It would be nice to expand the concept to something more general, like
a 'trusted triagers' status, but that can come as a later step.

--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-15 Thread Shaw Andy
[snip]

  What I would like to suggest that we do now is bring back this practice, so
 that the Qt Support team will set a priority on the bugs that it creates or
 handles, so that it makes things easier for the maintainers to actually see
 what issues are potentially a higher priority than the others. And in the case
 of the high priority issues, it will draw attention to them faster rather than
 them being picked up later on in the process. I have also discussed this with
 the developers inside Digia, and they see a need for getting help when
 triaging the bugs, so having the Qt Support team set a priority here would at
 least go some way to helping with that. Of course any priority set by the Qt
 Support team is intended to be a guideline, the maintainer would still be at
 liberty to change it if they disagree.
 
 I assume you mean that any approver would still be at liberty to edit
 the priority if they disagree, basically that there's nothing special
 about the priority just because it was set by Qt Support.

Yes, that is my intention, it should only be seen as a guide based on the 
person who triaged the issue since the person creating it would have verified 
the bug before having created it in this case. But if an approver disagrees 
then that is up to them and therefore it can be changed as appropriate.

 Then there's just the theoretical problem of non-approvers setting bug
 priorities, which is that most people think their bugs are top
 priority. I'm pretty sure the Qt Support team is sensible enough that
 they don't do that, so I think it would be helpful for them to be
 setting (initial) priorities.
 
 It would be nice to expand the concept to something more general, like
 a 'trusted triagers' status, but that can come as a later step.

I agree, long term having such a group would be good because there will always 
be untriaged bugs that come in from other sources currently.

Andy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Setting the priority of bug reports created the Qt Support team

2013-02-15 Thread Jason McDonald
On Fri, Feb 15, 2013 at 10:47 PM, Shaw Andy andy.s...@digia.com wrote:
 Before the transition to Qt being developed in the open via open governance, 
 the Qt Support team back in Trolltech and later Nokia, would prioritize the 
 bugs that were created, or at least handled, by them. Typically these would 
 be bugs that were brought to our attention by commercial customers using Qt. 
 As we know the bug fairly well at this point, and have an understanding of 
 the impact it has on applications, then we were in a position to set a 
 reasonable priority setting. Since the move to develop in the open via open 
 governance, this has not been kept up, as it was back then not desired  that 
 the Qt Support team would continue this practice.

 What I would like to suggest that we do now is bring back this practice, so 
 that the Qt Support team will set a priority on the bugs that it creates or 
 handles, so that it makes things easier for the maintainers to actually see 
 what issues are potentially a higher priority than the others. And in the 
 case of the high priority issues, it will draw attention to them faster 
 rather than them being picked up later on in the process. I have also 
 discussed this with the developers inside Digia, and they see a need for 
 getting help when triaging the bugs, so having the Qt Support team set a 
 priority here would at least go some way to helping with that. Of course any 
 priority set by the Qt Support team is intended to be a guideline, the 
 maintainer would still be at liberty to change it if they disagree.

Sounds like a good idea to me.

--
Jason
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development