Hi all,
The evidence of Intel driver bugs causing frame skipping is slowly
mounting. If you experience this, please join in:
Modern systems: https://bugs.freedesktop.org/show_bug.cgi?id=86366
Atom or similar: https://bugs.launchpad.net/mir/+bug/1388490
- Daniel
--
Mir-devel mailing list
r does (!?). So it does have users :)
On 12/12/13 17:18, Timo Aaltonen wrote:
On 12.12.2013 08:45, Daniel van Vugt wrote:
:)
Correction; XMir is in:
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs
yes, looks better :)
also, during saucy we
On 12.12.2013 08:45, Daniel van Vugt wrote:
> :)
>
> Correction; XMir is in:
> https://bugs.launchpad.net/xmir/+bugs
> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs
yes, looks better :)
also, during saucy we got a bunch of crashers against
xserver-xorg-video-intel
:)
Correction; XMir is in:
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs
On 11/12/13 22:43, Timo Aaltonen wrote:
On 11.12.2013 06:18, Daniel van Vugt wrote:
Yeah, we had a rude shock when people started using XMir last cycle.
Bugs were
I think Daniel meant this
https://bugs.launchpad.net/ubuntu/+source/mir/+bugs
As you can imagine, I also triage. And I try to be hygienic about both the
upstream bugs & ubuntu project-mir bugs. And agree with Olli, its not just
for managers...we all benefit. If nothing else carve out some tim
On 11.12.2013 06:18, Daniel van Vugt wrote:
> Yeah, we had a rude shock when people started using XMir last cycle.
> Bugs were piling up against the package tasks for some time, invisible
> to the upstream projects and invisible to mir-team. Now we're aware of
> it I think i
niel.van.v...@canonical.com>>
wrote:
Yeah, we had a rude shock when people started using XMir last cycle.
Bugs were piling up against the package tasks for some time,
invisible to the upstream projects and invisible to mir-team. Now
we're aware of it I think it's under control
On Tue, Dec 10, 2013 at 9:18 PM, Daniel van Vugt <
daniel.van.v...@canonical.com> wrote:
> Yeah, we had a rude shock when people started using XMir last cycle. Bugs
> were piling up against the package tasks for some time, invisible to the
> upstream projects and invisible to mir-
Yeah, we had a rude shock when people started using XMir last cycle.
Bugs were piling up against the package tasks for some time, invisible
to the upstream projects and invisible to mir-team. Now we're aware of
it I think it's under control.
Anyone who wants to see all Mir bug repo
On Wed, Dec 11, 2013 at 2:05 AM, Daniel van Vugt
wrote:
> I try to do so every day. Was something missed?
Nothing specifically, just checking as we had some bad experience with
a few canonical-upstream projects in the past (people not checking the
packaging bugs at all).
Thanks for taking c
-team should be subscribed to all Mir bug sources.
On 11/12/13 12:02, Ricardo Salveti wrote:
On Wed, Dec 4, 2013 at 12:30 PM, Daniel van Vugt
wrote:
All,
Several times recently, people have been talking about issues that already
have bugs for them, but people are not familiar with the bugs.
On Wed, Dec 4, 2013 at 12:30 PM, Daniel van Vugt
wrote:
> All,
>
> Several times recently, people have been talking about issues that already
> have bugs for them, but people are not familiar with the bugs.
>
> It's probably a good idea to familiarize yourself with at least
All,
Several times recently, people have been talking about issues that
already have bugs for them, but people are not familiar with the bugs.
It's probably a good idea to familiarize yourself with at least the most
severe bugs:
https://bugs.launchpad.net/mir/+bugs
Well I tagged a bunch of bugs as [feature] yesterday and already ran
into ambiguity in some (feature vs enhancement vs bug). I think
[enhancement] is a better classification because not all enhancement
requests represent distinct "features". Might switch them to
[enhancement] today
er-friendly. No one outside the team
would understand it.
How about "[feature]" or "[enhancement]"?
On 16/10/13 21:02, Kevin Gunn wrote:
thanks for the feedback.
it likely won't be something to be fixed in a short term - but i agree,
bugs (over blueprints) seem clos
t]"?
>
>
>
> On 16/10/13 21:02, Kevin Gunn wrote:
>
>> thanks for the feedback.
>> it likely won't be something to be fixed in a short term - but i agree,
>> bugs (over blueprints) seem closer to being 'everything' you'd want when
>> looking at
I don't think "[ER]" is very user-friendly. No one outside the team
would understand it.
How about "[feature]" or "[enhancement]"?
On 16/10/13 21:02, Kevin Gunn wrote:
thanks for the feedback.
it likely won't be something to be fixed in a short term -
thanks for the feedback.
it likely won't be something to be fixed in a short term - but i agree,
bugs (over blueprints) seem closer to being 'everything' you'd want when
looking at the vices & virtues of bugs vs blueprints.
i think what bugs are missing is a bit of aggre
just found the bug (which itself is actually a feature request)
and it looks unlikely to be resolved:
https://bugs.launchpad.net/launchpad/+bug/176431
On 15/10/13 22:09, Michał Sawicz wrote:
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level,
nchpad.net/launchpad/+bug/176431
On 15/10/13 22:09, Michał Sawicz wrote:
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone,
On 15/10/13 14:01, Kevin Gunn wrote:
> Something that I have not pushed very hard but is something I prefer
> is to place features in relevant blueprints and keep bugs as bugs.
In managing the backlog bugs vs features isn't the most useful
distinction and is given far too much pr
On 15.10.2013 16:13, Daniel d'Andrada wrote:
That's because you're mapping a feature to a priority level, which is
wrong. A bug could have a "Wishlist" priority-level just as well as a
feature could be at a "High" priority level.
Not me - launchpad does...
--
Michał (Saviq) Sawicz
Canonical S
On 15/10/13 11:09, Michał Sawicz wrote:
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priori
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priority, a state
(in progress, new, commited, rel
On 15/10/13 10:01, Kevin Gunn wrote:
What do you think of using blueprints for bugs-which-are-really-features ?
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an
On 15.10.2013 15:01, Kevin Gunn wrote:
What do you think of using blueprints for bugs-which-are-really-features ?
I believe the biggest issue here for us is ubuntu-ux's process of
design-related bugs.
On top of that, bugs allow you to link multiple related projects
together,
Something that I have not pushed very hard but is something I prefer is to
place features in relevant blueprints and keep bugs as bugs.
I haven't pushed the blueprint vs bug mainly because the team has been both
responsive to correctly followup and responsible in understanding the
difference
We always seem to have lots of enhancements logged as bugs in the Mir
project. And we seem to have a requirement that many of them be more
important than "Wishlist" which is what LP historically uses to
represent enhancements.
So assuming we can't convince everyone that a
28 matches
Mail list logo
