Today a I got a few updates, and in them, there was an update for the
NetworkManager.
But since Network-manager-gnome depends on it, and still isnt
available, I lost all my control of the networks via the applet.
Also I use a VPN via wifi on my University, and without the NM its
pretty difficult
I know this is still alpha.
none the less this upgrade brakes machines.
So I've asked before opening a Launchpad ticket.
Is that what you want me to do?
Ok. done.
On 6/19/07, Joseph Price [EMAIL PROTECTED] wrote:
From: http://www.ubuntu.com/testing/tribe1 (and bolded)
Note: This is still an
Hya.
Sarah I know all that.
And I've lucky enough for the rest to keep working so fine.
I did already been testing feisty since herd 2.
I did the upgrade for gutsy because of the support for the new Xorg
1.3 to see if finally I could use my SVideo output.
On 6/19/07, Sarah Hobbs [EMAIL
Thanks so much.
I'll close the bug, when fixed
On 6/19/07, Emilio Pozuelo Monfort [EMAIL PROTECTED] wrote:
(``-_-´´) -- Fernando wrote:
Today a I got a few updates, and in them, there was an update for the
NetworkManager.
But since Network-manager-gnome depends on it, and still isnt
(``-_-´´) -- Fernando wrote the following on 19.06.2007 18:50
I'm sorry, but I like the old status name better!!
Cant we keep them or at least have a poll about it?
* Unconfirmed - New
* Needs Info - Incomplete
* Rejected - Invalid
Just because you get used to it doesn´t make them
Henrik Nilsen Omma wrote:
* Triaged will mean that a bug has all the information attached to it
that a developer needs to fix it. The 'confirmed' state was previously
used for this purpose, but many users were 'confirming' bugs when
observed by a second person.
I disagree with this term.
Phillip Susi wrote:
Henrik Nilsen Omma wrote:
* Triaged will mean that a bug has all the information attached to
it that a developer needs to fix it. The 'confirmed' state was
previously used for this purpose, but many users were 'confirming'
bugs when observed by a second person.
I
On Tue, 19 Jun 2007 18:43:33 +0200 Henrik Nilsen Omma [EMAIL PROTECTED]
wrote:
* Rejected has been split into Invalid and Won't Fix, where the latter
may be a valid bug or wish-list change that we don't have the wish or
resources to fix.
Will 'Won't Fix' bugs show up in default search
Scott Kitterman wrote:
Will 'Won't Fix' bugs show up in default search results? I think it would
be good for them to show up to minimize duplicate submissions of things
that aren't going to get done.
It's a closed state so I expect they won't (we'll find out tomorrow). It
would be more
On Tue Jun 19, 2007 at 11:00:50PM +0200, Henrik Nilsen Omma wrote:
Scott Kitterman wrote:
Will 'Won't Fix' bugs show up in default search results? I think it would
be good for them to show up to minimize duplicate submissions of things
that aren't going to get done.
It's a closed
On 20/06/07 04:56, Henrik Nilsen Omma wrote:
What I did not mention in my first mail (just confirmed this with the LP
developer), is that the groups who can set the different states will now
also change.
[..deleted..]
A developer can:
* Move the bug from Triaged to ToDo or push it back
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually working on the fix and it may never
be fixed.
Um, non-developers work on fixes all the time. I did a bunch of them before I
was a
Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually working on the fix and it may never
be fixed.
There are those of us who are not developers but do still work on fixing
bugs ;)
Non developers should be able to set
On 20/06/07 05:59, Henrik Nilsen Omma wrote:
Onno Benschop wrote:
On 20/06/07 04:56, Henrik Nilsen Omma wrote:
What I did not mention in my first mail (just confirmed this with the LP
developer), is that the groups who can set the different states will now
also change.
Phillip Susi wrote:
Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually working on the fix and it may
never be fixed.
There are those of us who are not developers but do still work on
fixing bugs ;)
Non
On Tuesday 19 June 2007 18:09, Cody Somerville wrote:
Top posting fixed.
On 6/19/07, Scott Kitterman [EMAIL PROTECTED] wrote:
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually
Being a member of that group is a certification of your work as a developer
in Ubuntu. There are many Ubuntu developers who are not in that group OR
are in other groups on launchpad. I think the definition of developer
should be strongly examined before being implement in this context.
On
Scott Kitterman wrote:
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually working on the fix and it may never
be fixed.
Um, non-developers work on fixes all the time. I did
Onno Benschop wrote:
When you say 'a member of the general community' do you mean not in
ubuntu-qa and not a developer (I ask because people from the volunteer
community are also in those groups)? If you are not then it it's
correct that you cannot set those states. This
Scott Kitterman wrote:
I don't think you should assign a bug to yourself if you are not working
on fixing it. IMO you should try to move it along to the Triaged state
as efficiently as possible and bugs should be assigned to the developer
or dev team who is going to fix it.
I realise that
On Wed Jun 20, 2007 at 12:41:36AM +0200, Henrik Nilsen Omma wrote:
Onno Benschop wrote:
snip
If you are trying to reproduce it or asking for more information from
the submitter then this will be clear from the comments and you can set
it to Incomplete.
If you are not a developer then
On Tuesday 19 June 2007 18:36, Henrik Nilsen Omma wrote:
Scott Kitterman wrote:
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote:
If you are not a developer then it is misleading to set it to In
Progress because nobody is actually working on the fix and it may never
be fixed.
Jordan Mantha wrote:
Please don't interpret it that way :) As I replied to Scott, if the bug
is not handled by someone who can upload to Ubuntu then it's fair to say
that nobody is working on a fix in Ubuntu.
This is just not true. In Universe we have a great number of
Scott Kitterman wrote:
OK. I guess I missed the meeting. Where is this change documented? Was
there a spec? Anything those of us who were unable to participate in UDS
could have seen this coming?
The discussion was scheduled on a public webpage, but the Launchpad spec
was not public
On Tuesday 19 June 2007 19:28, Henrik Nilsen Omma wrote:
Scott Kitterman wrote:
OK. I guess I missed the meeting. Where is this change documented? Was
there a spec? Anything those of us who were unable to participate in UDS
could have seen this coming?
The discussion was scheduled on
Scott Kitterman wrote:
I have no idea. I think here you are taking them away for no good reason
that I have seen.
What has beene taken away? The ability for anyone with an email address
to set bugs to In progress and similar. We have also added 3 new bug
states which I think will be
Jordan Mantha wrote:
If we want a certain group of people who write code but are not MOTU or
core-dev to be able to set the whole range of status settings then we
can set up a team that gives that access. I agree that people can write
valuable code without doing .deb packaging for example.
27 matches
Mail list logo
