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 to
From: http://www.ubuntu.com/testing/tribe1 (and bolded)
> Note: This is still an alpha release. Do not install it on production
> machines. The final stable version will be released in October 2007.
Pricey
On 19/06/07, (``-_-´´) -- Fernando <[EMAIL PROTECTED]> wrote:
> Today a I got a few updat
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
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 PROTECTED
(``-_-´´) -- 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
> available, I lost all my control of the networks via the applet.
> Also I use a VPN via wifi on my University, and
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 isn
Jan Claeys wrote:
> Except that many user apps use binary multiples for both bits and bytes
> when they show "download speed".
>
> (But of course your usage of "usually" already tells us that there is no
> clear definition.)
Most use 1000 for bits, and 1024 for bytes. Those that do not are
cons
Tomorrow (2007-06-20) the Launchpad team will update the bug tracker
with a new set of bug states to help projects like Ubuntu improve bug
management. The changes will allow for greater fine tuning of our bug
management and the new labels should hopefully also make more sense to
users.
The fol
I'm sorry, but I like the old status name better!!
Cant we keep them or at least have a poll about it?
On 6/19/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> Tomorrow (2007-06-20) the Launchpad team will update the bug tracker
> with a new set of bug states to help projects like Ubuntu improv
(``-_-´´) -- 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
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 ter
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.
Henrik Nilsen Omma wrote:
> I agree that 'evaluating the urgency' should also fit into the Triaged
> state. However, not that this can only be done by ubuntu-qa or
> developers (setting importance). Assigning resources can really only be
> done by the people who intend to fix it, which is an eve
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 re
Phillip Susi wrote:
> Henrik Nilsen Omma wrote:
>> I agree that 'evaluating the urgency' should also fit into the
>> Triaged state. However, not that this can only be done by ubuntu-qa
>> or developers (setting importance). Assigning resources can really
>> only be done by the people who intend
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 u
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 clo
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
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.
>>
>> [..deleted..]
>>
>> A developer can:
>>
>> * Move
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 d
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 s
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
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 ;)
>
> N
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 actu
On Tuesday 19 June 2007 18:24, Henrik Nilsen Omma wrote:
> 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 u
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 6/1
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 t
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 state
On 20/06/07 06:36, Henrik Nilsen Omma wrote:
> OK, so I should have said 'Ubuntu developer' (member of core dev or
> MOTU) instead of 'developer'. Lots of fixes are being worked on by
> upstreams or other non-Ubuntu developers all the time, but we don't mark
> a bug as In Progress unless someone
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 r
On Tuesday 19 June 2007 18:57, Henrik Nilsen Omma wrote:
> 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
On Wed Jun 20, 2007 at 12:41:36AM +0200, Henrik Nilsen Omma wrote:
> Onno Benschop wrote:
> >> 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 deve
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 f
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 grea
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 publ
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 sched
On Wed Jun 20, 2007 at 01:13:41AM +0200, Henrik Nilsen Omma wrote:
> 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 fi
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> Jordan Mantha wrote:
> > This is just not true. In Universe we have a great number of people working
> > on bugs that are not able to upload. These people use status,
> > subscriptions, and assignments to get their work sponsored. Even in
On 6/20/07, Jordan Mantha <[EMAIL PROTECTED]> wrote:
> On Wed Jun 20, 2007 at 01:13:41AM +0200, Henrik Nilsen Omma 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
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 whic
On Tuesday 19 June 2007 20:01, Henrik Nilsen Omma wrote:
> If we need to give wider permissions to more people then I'm sure we can
> do that, both for triaging and fixing, either through ubuntu-qa or other
> teams that we can set up. Even an open team with thousands of members
> might be better t
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
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> >> 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 very useful.
The new bug states are likely helpful
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> ...I can see how that becomes a sensitive change, I also happen to
> think it's useful. I don't agree that someone working by themselves,
> outside of the ubuntu structures, should be able to set the state to In
> Progress (or the new ToDo
Ivan Jager <[EMAIL PROTECTED]> writes:
> Here's a shell for people who don't remember what the output of their
> commands mean:
>
> #!/bin/bash
> while echo -n '$ '; read cmd line; do
> man $cmd | cat;
> eval $cmd "$line" | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/';
> done
I'm choosin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nice change!
However, we've missed a case completely...I'm not sure how I didnt think
of it at UDS.
Henrik Nilsen Omma wrote:
> Phillip Susi wrote:
>> Henrik Nilsen Omma wrote:
>>> If you are not a developer then it is misleading to set it to In
>>>
46 matches
Mail list logo
