From sense at qense.nl Fri Jan 1 12:58:38 2010 From: sense at qense.nl (Sense Hofstede) Date: Fri, 1 Jan 2010 13:58:38 +0100 Subject: AdoptPackage In-Reply-To: <4cfc0be70912221439q3579340cx608a70e16950c6dd@mail.gmail.com> References: <4cfc0be70912221439q3579340cx608a70e16950c6dd@mail.gmail.com> Message-ID: 2009/12/22 Marcos Vanetta : > Hi! > I've found about this [1] after an email from qense. Then I've found this > [2] > As you probably know, I'm new at the bugsquad, and I think this could be > more educational in the road of learning triagging bugs. > So I wonder? > How can I do to singn me up in this? should I edit the wiki? or there is a > list. I don't know. > Nothing more for now. > regards > malev > > > [1] https://wiki.ubuntu.com/BugSquad/AdoptPackage > [2] https://wiki.ubuntu.com/QATeam/MainPackagesWithoutBugSubscribers > -- > Eng. Marcos Vanetta > http://blog.malev.com.ar > twitter: @malev > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > Hello, At the moment we're just starting with Adopt-a-Package, so there isn't a process in place yet for signing-up. However, if you are committed to a certain application already, and are actively triaging it, you could add it and yourself to the list. Keep an eye on the maillist for announcements! Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From sense at qense.nl Fri Jan 1 13:24:25 2010 From: sense at qense.nl (Sense Hofstede) Date: Fri, 1 Jan 2010 14:24:25 +0100 Subject: Adopting Nautilus, wiki page created Message-ID: Hello, I've created a wiki page at . I've added some information to the page and came up with three tasks: 'New Bugs', 'Confirmed Bugs' and 'Forwarding upstream'. What do you think of the page? Is the information correct and sufficient? Yazen, Marcos and Bruno, I'm glad you're interested. I've only added myself to the table because I don't know what you would like to do. If you'd tell me that and give me your name on the wiki I'll add you, but if you add yourself to the table that's fine too. Erick and David, you said you hadn't started with triaging yet. I would recommend you to gain a bit more experience before adopting a package. At you'll find more information about the mentoring process, I suggest to read that and apply for a mentor. Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From david.planella at ubuntu.com Mon Jan 4 14:35:40 2010 From: david.planella at ubuntu.com (David Planella) Date: Mon, 04 Jan 2010 15:35:40 +0100 Subject: Ubuntu Translation bug handling process In-Reply-To: <1260612977.7276.54.camel@adi-laptop> References: <1260181297.3621.103.camel@lenovo> <1260612977.7276.54.camel@adi-laptop> Message-ID: <1262615740.2870.111.camel@lenovo> El ds 12 de 12 de 2009 a les 12:16 +0200, en/na Adi Roiban va escriure: > Just my 2 cents and I try to be brief and concise.... but I failed > > I think that all Ubuntu Translators will be happy to make > ubuntu-translators less useful by not having to do bug triaging. > The bughandling wikipage was just a brainstorming page. I would be happy > to delete it and have all info on bugsquad wiki. > > Ubuntu Translations bugs are something special from the following points > of view: > > * They can be fixed without having someone patching and uploading a new > package > > * Most of them can be fixed in less than 2 minutes, just from the web > UI. You only need to read the bug, to to Launchpad translation, fix the > translation and then come back and mark that bug as fixed. > > * Many translators are not technical persons. > > We can channel all bug to Ubuntu and make them use apport, but I think > that this will stop them from reporting bugs. > > ------------- > > I like to keep things simple and this is why I went for a divide and > conquer approach for handling Ubuntu translations bugs. > > I think that reporting a bug in Ubuntu is ok when you don't know exactly > what component is affected and who can fix it. > > For translations bug we know they affect ubuntu-translation and they can > be fixed by the ubuntu-l10n-CC (replace CC with your language) team. > The triaging process can be done by the bug reporter at the time they > report the bug. > No need to add extra work to other persons. > > ------------ > > My goal is to have ubuntu-translation bugs fixed. Fast. Without stepping > on others feet. > > What are the drawbacks of the current process? > > Right now, in Ubuntu we have 39668 new bugs. What do we gain if we put > Ubuntu Translation bugs together? > > --------- > > I think we should add this topic on the next team meeting agenda. > Next for translations is 7 Jan, bugsquad 12. I am available for both. > > Kindest regards, > Let's try to move this forward. I like Adi's suggestion to discuss it on a meeting, and I see that micahg has already added it to the next Bugsquad's meeting on the 12th of January, so we can talk about it there. I've summarised the main points at https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming I think so far we agree that we can move that page to the bugsquad's wiki and let the bugsquad channel translation bugs to the ubuntu-translations project as appropriate. The main point for me is that I'm open to any suggestions for optimization. While I'd be prepared to sacrifice the pool of translations bugs the ubuntu-translations project offers by submitting them only to the source packages, though, I wouln't want to compromise the additional benefits it has provided so far: bugmail and the ubuntu-translations-coordinators team acting as a driver. I think these last points have made all the difference in comparison to the situation we already had, that is, having translation bugs reported only against the source packages. Thanks. Regards, David. -- David Planella Ubuntu Translations Coordinator david(dot)planella(at)ubuntu(dot)com www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: Això és una part d'un missatge signada digitalment URL: From sense at qense.nl Mon Jan 4 17:06:30 2010 From: sense at qense.nl (Sense Hofstede) Date: Mon, 4 Jan 2010 18:06:30 +0100 Subject: Ubuntu Translation bug handling process In-Reply-To: <1262615740.2870.111.camel@lenovo> References: <1260181297.3621.103.camel@lenovo> <1260612977.7276.54.camel@adi-laptop> <1262615740.2870.111.camel@lenovo> Message-ID: 2010/1/4 David Planella : > El ds 12 de 12 de 2009 a les 12:16 +0200, en/na Adi Roiban va escriure: >> Just my 2 cents and I try to be brief and concise.... but I failed >> >> I think that all Ubuntu Translators will be happy to make >> ubuntu-translators less useful by not having to do bug triaging. >> The bughandling wikipage was just a brainstorming page. I would be happy >> to delete it and have all info on bugsquad wiki. >> >> Ubuntu Translations bugs are something special from the following points >> of view: >> >> * They can be fixed without having someone patching and uploading a new >> package >> >> * Most of them can be fixed in less than 2 minutes, just from the web >> UI. You only need to read the bug, to to Launchpad translation, fix the >> translation and then come back and mark that bug as fixed. >> >> * Many translators are not technical persons. >> >> We can channel all bug to Ubuntu and make them use apport, but I think >> that this will stop them from reporting bugs. >> >> ------------- >> >> I like to keep things simple and this is why I went for a divide and >> conquer approach for handling Ubuntu translations bugs. >> >> I think that reporting a bug in Ubuntu is ok when you don't know exactly >> what component is affected and who can fix it. >> >> For translations bug we know they affect ubuntu-translation and they can >> be fixed by the ubuntu-l10n-CC (replace CC with your language) team. >> The triaging process can be done by the bug reporter at the time they >> report the bug. >> No need to add extra work to other persons. >> >> ------------ >> >> My goal is to have ubuntu-translation bugs fixed. Fast. Without stepping >> on others feet. >> >> What are the drawbacks of the current process? >> >> Right now, in Ubuntu we have 39668 new bugs. What do we gain if we put >> Ubuntu Translation bugs together? >> >> --------- >> >> I think we should add this topic on the next team meeting agenda. >> Next for translations is 7 Jan, bugsquad 12. I am available for both. >> >> Kindest regards, >> > > Let's try to move this forward. I like Adi's suggestion to discuss it on > a meeting, and I see that micahg has already added it to the next > Bugsquad's meeting on the 12th of January, so we can talk about it > there. > > I've summarised the main points at > > https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background > https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming > > I think so far we agree that we can move that page to the bugsquad's > wiki and let the bugsquad channel translation bugs to the > ubuntu-translations project as appropriate. > > The main point for me is that I'm open to any suggestions for > optimization. While I'd be prepared to sacrifice the pool of > translations bugs the ubuntu-translations project offers by submitting > them only to the source packages, though, I wouln't want to compromise > the additional benefits it has provided so far: bugmail and the > ubuntu-translations-coordinators team acting as a driver. I think these > last points have made all the difference in comparison to the situation > we already had, that is, having translation bugs reported only against > the source packages. > > Thanks. > > Regards, > David. > > -- > David Planella > Ubuntu Translations Coordinator > david(dot)planella(at)ubuntu(dot)com > www.ubuntu.com > > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > Hello, If the separate 'ubuntu-translation' project helps the translations team then of course it should stay. Reading your mails and the project documentation made it clear to me that this project has been a great help for the translators. I'll try to attend the meeting at January the 12th. Because I do think that it would be good to define the roles of the Bug Squad and the Translations team here. The meeting would be a good way to do so since IRC allows direct communication and ensures the presence and attention of the team leaders. You already have a workflow in place and of course we shouldn't force our policies upon you, but there are overlapping areas where both teams have to deal with the bug reports. What we should do is to come up with a way to let the bugs show up in such a way that they are useful to both teams and don't mess up the statistics of either one of them. Thank you for adding the explanation to the wiki page! Now I know where to direct people to if they want to know more about the policy of Translations. Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From brunogirin at gmail.com Tue Jan 5 13:13:03 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 05 Jan 2010 14:13:03 +0100 Subject: Adopting Nautilus, wiki page created In-Reply-To: References: Message-ID: <1262697183.2384.68.camel@nuuk> On Fri, 2010-01-01 at 14:24 +0100, Sense Hofstede wrote: > Hello, > > I've created a wiki page at > . I've added > some information to the page and came up with three tasks: 'New Bugs', > 'Confirmed Bugs' and 'Forwarding upstream'. > > What do you think of the page? Is the information correct and sufficient? It's a great start. I think we could extend the information by being more specific in what is expected of people when dealing with bugs in the "New", "Confirmed" or "Triaged" states. Some of it is explained in the HowToTriage page [1] but we could be more specific here. Here are a few ideas to start with: When a bug is New, the aim is to move it to Confirmed or Invalid, depending on whether we can re-create it or not, or mark it as duplicate of another bug. In some cases, we may need more information, in which case, it should be changed to Incomplete first and we should start a dialogue with the original reporter to be able to re-create. In all cases, this first pass should be an opportunity to improve the bug report (even if we can re-create it easily) and rewrite it in the form: * Steps to recreate * Expected behaviour * Actual behaviour That's the theory. In practice, how do we deal with the more complex or arcane bugs that require certain configuration or hardware that the triager doesn't necessarily have? For instance, if there is a bug report about iPod integration and the triager doesn't have an iPod, how do we move it forward? Once a bug is in the Confirmed state, it should be moved to Triaged, which only Bug Control members can do. I think that if the previous phase is done properly, moving bugs to triaged should be straightforward. So for this to work, it would be useful to know what Bug Control members look for in a confirmed bug to consider it triaged. Sense, what would you want to see in a bug report to move it to Triaged? Once bugs have been triaged, the aim is to get them resolved. Some of them will be resolved by the Ubuntu developers, others need forwarding upstream. How is that identified, who is responsible for making that decision and how is this communicated in the bug report? At the moment there are 559 bugs against Nautilus in the Triaged state. That's a lot so I suspect that a number are old and have actually been resolved but never closed, while others have not been addressed and may have given the original reporter the impression that nobody cared about his problem. How do we move them forward? Sorry about all the questions, I'm sure some of them are answered on the wiki but I've struggled to find that info and it might be useful to answer them in the Nautilus context. Also if any of my assumptions above are incorrect in terms of the triaging process, please point it out. > > Yazen, Marcos and Bruno, I'm glad you're interested. I've only added > myself to the table because I don't know what you would like to do. If > you'd tell me that and give me your name on the wiki I'll add you, but > if you add yourself to the table that's fine too. Thanks, I added myself to the wiki. > > Erick and David, you said you hadn't started with triaging yet. I > would recommend you to gain a bit more experience before adopting a > package. At you'll find > more information about the mentoring process, I suggest to read that > and apply for a mentor. Thanks, that will be useful to me too :-) [1] https://wiki.ubuntu.com/Bugs/HowToTriage Bruno From sense at qense.nl Tue Jan 5 17:39:47 2010 From: sense at qense.nl (Sense Hofstede) Date: Tue, 5 Jan 2010 18:39:47 +0100 Subject: Adopting Nautilus, wiki page created In-Reply-To: <1262697183.2384.68.camel@nuuk> References: <1262697183.2384.68.camel@nuuk> Message-ID: 2010/1/5 Bruno Girin : > On Fri, 2010-01-01 at 14:24 +0100, Sense Hofstede wrote: >> Hello, >> >> I've created a wiki page at >> . I've added >> some information to the page and came up with three tasks: 'New Bugs', >> 'Confirmed Bugs' and 'Forwarding upstream'. >> >> What do you think of the page? Is the information correct and sufficient? > > It's a great start. I think we could extend the information by being > more specific in what is expected of people when dealing with bugs in > the "New", "Confirmed" or "Triaged" states. Some of it is explained in > the HowToTriage page [1] but we could be more specific here. Here are a > few ideas to start with: > > When a bug is New, the aim is to move it to Confirmed or Invalid, > depending on whether we can re-create it or not, or mark it as duplicate > of another bug. In some cases, we may need more information, in which > case, it should be changed to Incomplete first and we should start a > dialogue with the original reporter to be able to re-create. In all > cases, this first pass should be an opportunity to improve the bug > report (even if we can re-create it easily) and rewrite it in the form: >      * Steps to recreate >      * Expected behaviour >      * Actual behaviour > > That's the theory. In practice, how do we deal with the more complex or > arcane bugs that require certain configuration or hardware that the > triager doesn't necessarily have? For instance, if there is a bug report > about iPod integration and the triager doesn't have an iPod, how do we > move it forward? > > Once a bug is in the Confirmed state, it should be moved to Triaged, > which only Bug Control members can do. I think that if the previous > phase is done properly, moving bugs to triaged should be > straightforward. So for this to work, it would be useful to know what > Bug Control members look for in a confirmed bug to consider it triaged. > Sense, what would you want to see in a bug report to move it to Triaged? > > Once bugs have been triaged, the aim is to get them resolved. Some of > them will be resolved by the Ubuntu developers, others need forwarding > upstream. How is that identified, who is responsible for making that > decision and how is this communicated in the bug report? At the moment > there are 559 bugs against Nautilus in the Triaged state. That's a lot > so I suspect that a number are old and have actually been resolved but > never closed, while others have not been addressed and may have given > the original reporter the impression that nobody cared about his > problem. How do we move them forward? > > Sorry about all the questions, I'm sure some of them are answered on the > wiki but I've struggled to find that info and it might be useful to > answer them in the Nautilus context. Also if any of my assumptions above > are incorrect in terms of the triaging process, please point it out. > >> >> Yazen, Marcos and Bruno, I'm glad you're interested. I've only added >> myself to the table because I don't know what you would like to do. If >> you'd tell me that and give me your name on the wiki I'll add you, but >> if you add yourself to the table that's fine too. > > Thanks, I added myself to the wiki. > >> >> Erick and David, you said you hadn't started with triaging yet. I >> would recommend you to gain a bit more experience before adopting a >> package. At you'll find >> more information about the mentoring process, I suggest to read that >> and apply for a mentor. > > Thanks, that will be useful to me too :-) > > [1] https://wiki.ubuntu.com/Bugs/HowToTriage > > Bruno > Hello, First of all, don't apologise for asking questions! Your mail contained some good suggestions and you ask some valid questions. Furthermore, like someone whose name I forgot once said, there are no bad questions, only bad answers. The explanations of the different tasks and the actions you're expected to execute when doing them could and should be more extensive indeed. However, I'm not sure if it would be a wise decision to write everything again and again on each adoption page. Not only would it be a lot of work to update this, it would also make the page longer and divert attention from the content that actually matters for the adoption group. What I would suggest is to write a separate page that briefly explains all tasks and then provides a link to a more extensive description. This page could be included on all adoption pages. Bug descriptions are often incomplete and don't reflect the bug report properly. I also often don't extend the bug descriptions, even though it would be desirable. However, it is a lot of work to do this for all bug reports. We could mention it in the explanation of the first task, but I think that it is more something the Bug Squad as a whole should pay attention to. Furthermore I think that it would be better to spend our energy on triaging bug reports and making sure they are either marked as Invalid or are of use to the developers and packagers. We can't afford to do much else with so many bug reports. It is the task of the triager to determine whether the bug has to be forwarded upstream. The description, title and replies of/to the bug report should make this clear. Packaging errors are mostly Ubuntu bugs, unless the package was synced from Debian. In that case it should be forwarded to Debian. There is a separate task/subgroup for forwarding upstream because it is a disruption of your work when you have to leave Launchpad and not everyone is familiar with GNOME Bugzilla. I though it would be better to let people that focus on triaging bugs in Launchpad focus on triaging bugs in Launchpad. When a bug should be forwarded upstream they can open an empty task against the upstream project with the "Also affects project" button. Maybe it would indeed be wise to create a temporary focus group that goes to all bugs that were or weren't triaged and that are forgotten. It would be a lot of work to clean those bug reports, but it would be worth it. When it is done it is the task of the adoption group to make sure the adopted package stays in shape. Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From brunogirin at gmail.com Tue Jan 5 20:08:04 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 05 Jan 2010 20:08:04 +0000 Subject: Adopting Nautilus, wiki page created In-Reply-To: References: <1262697183.2384.68.camel@nuuk> Message-ID: <1262722084.2473.52.camel@nuuk> On Tue, 2010-01-05 at 18:39 +0100, Sense Hofstede wrote: > 2010/1/5 Bruno Girin : > > On Fri, 2010-01-01 at 14:24 +0100, Sense Hofstede wrote: > >> Hello, > >> > >> I've created a wiki page at > >> . I've added > >> some information to the page and came up with three tasks: 'New Bugs', > >> 'Confirmed Bugs' and 'Forwarding upstream'. > >> > >> What do you think of the page? Is the information correct and sufficient? > > > > It's a great start. I think we could extend the information by being > > more specific in what is expected of people when dealing with bugs in > > the "New", "Confirmed" or "Triaged" states. Some of it is explained in > > the HowToTriage page [1] but we could be more specific here. Here are a > > few ideas to start with: > > > > When a bug is New, the aim is to move it to Confirmed or Invalid, > > depending on whether we can re-create it or not, or mark it as duplicate > > of another bug. In some cases, we may need more information, in which > > case, it should be changed to Incomplete first and we should start a > > dialogue with the original reporter to be able to re-create. In all > > cases, this first pass should be an opportunity to improve the bug > > report (even if we can re-create it easily) and rewrite it in the form: > > * Steps to recreate > > * Expected behaviour > > * Actual behaviour > > > > That's the theory. In practice, how do we deal with the more complex or > > arcane bugs that require certain configuration or hardware that the > > triager doesn't necessarily have? For instance, if there is a bug report > > about iPod integration and the triager doesn't have an iPod, how do we > > move it forward? > > > > Once a bug is in the Confirmed state, it should be moved to Triaged, > > which only Bug Control members can do. I think that if the previous > > phase is done properly, moving bugs to triaged should be > > straightforward. So for this to work, it would be useful to know what > > Bug Control members look for in a confirmed bug to consider it triaged. > > Sense, what would you want to see in a bug report to move it to Triaged? > > > > Once bugs have been triaged, the aim is to get them resolved. Some of > > them will be resolved by the Ubuntu developers, others need forwarding > > upstream. How is that identified, who is responsible for making that > > decision and how is this communicated in the bug report? At the moment > > there are 559 bugs against Nautilus in the Triaged state. That's a lot > > so I suspect that a number are old and have actually been resolved but > > never closed, while others have not been addressed and may have given > > the original reporter the impression that nobody cared about his > > problem. How do we move them forward? > > > > Sorry about all the questions, I'm sure some of them are answered on the > > wiki but I've struggled to find that info and it might be useful to > > answer them in the Nautilus context. Also if any of my assumptions above > > are incorrect in terms of the triaging process, please point it out. > > > >> > >> Yazen, Marcos and Bruno, I'm glad you're interested. I've only added > >> myself to the table because I don't know what you would like to do. If > >> you'd tell me that and give me your name on the wiki I'll add you, but > >> if you add yourself to the table that's fine too. > > > > Thanks, I added myself to the wiki. > > > >> > >> Erick and David, you said you hadn't started with triaging yet. I > >> would recommend you to gain a bit more experience before adopting a > >> package. At you'll find > >> more information about the mentoring process, I suggest to read that > >> and apply for a mentor. > > > > Thanks, that will be useful to me too :-) > > > > [1] https://wiki.ubuntu.com/Bugs/HowToTriage > > > > Bruno > > > Hello, > > First of all, don't apologise for asking questions! Your mail > contained some good suggestions and you ask some valid questions. > Furthermore, like someone whose name I forgot once said, there are no > bad questions, only bad answers. > > The explanations of the different tasks and the actions you're > expected to execute when doing them could and should be more extensive > indeed. However, I'm not sure if it would be a wise decision to write > everything again and again on each adoption page. Not only would it be > a lot of work to update this, it would also make the page longer and > divert attention from the content that actually matters for the > adoption group. > What I would suggest is to write a separate page that briefly explains > all tasks and then provides a link to a more extensive description. > This page could be included on all adoption pages. Completely agree, it makes no sense to repeat them in each adoption page. On the other hand, we can start by having a draft in the Nautilus adoption page and move them to generic pages (either new or existing) once we've applied them enough to be confident that they work. > > Bug descriptions are often incomplete and don't reflect the bug report > properly. I also often don't extend the bug descriptions, even though > it would be desirable. However, it is a lot of work to do this for all > bug reports. We could mention it in the explanation of the first task, > but I think that it is more something the Bug Squad as a whole should > pay attention to. Furthermore I think that it would be better to spend > our energy on triaging bug reports and making sure they are either > marked as Invalid or are of use to the developers and packagers. We > can't afford to do much else with so many bug reports. I'd say we can't afford not to improve the description. Once a bug is triaged, it will end up with the developers. They then see the bug for the first time and the first details they read will be the title and description. As a (ex-)developer myself, I can guess what happens next: if the description is vague or requires the developer to read through dozens of additional comments, he will just ignore it and go to the next bug report because he can't afford to lose time trying to understand the bug. If the description is clear, he will just try out, have an "oh yes!" moment and fix the bug before lunchtime. At the end of the day, the triaging process is the first phase of getting a bug resolved. If bugs that come out of triaging are such that the developers don't pick them up, we've failed. I agree with you that we have a resource problem based on the number of bugs but I'd rather triage 5 bugs and have all of them resolved than triage 25 and have 2 resolved. I think this is even more important for bugs that need forwarding upstream because the person doing the forwarding may not be the same as the person who did the original triage. Considering that the forwarder will have to summarise the bug in the upstream system, the risk is that the upstream summary is incorrect. > > It is the task of the triager to determine whether the bug has to be > forwarded upstream. The description, title and replies of/to the bug > report should make this clear. Packaging errors are mostly Ubuntu > bugs, unless the package was synced from Debian. In that case it > should be forwarded to Debian. > There is a separate task/subgroup for forwarding upstream because it > is a disruption of your work when you have to leave Launchpad and not > everyone is familiar with GNOME Bugzilla. I though it would be better > to let people that focus on triaging bugs in Launchpad focus on > triaging bugs in Launchpad. When a bug should be forwarded upstream > they can open an empty task against the upstream project with the > "Also affects project" button. That makes sense. I am comfortable with Bugzilla so am happy to do some upstream forwarding for Nautilus. Having said that, is there a way to see what bugs have been marked as needing forwarding but have not actually been forwarded yet? > > Maybe it would indeed be wise to create a temporary focus group that > goes to all bugs that were or weren't triaged and that are forgotten. > It would be a lot of work to clean those bug reports, but it would be > worth it. When it is done it is the task of the adoption group to make > sure the adopted package stays in shape. One first step would be to identify all bugs that are in the Triaged state but that haven't been forwarded upstream. That will give us an idea of how big the problem is. Alternatively, we can just go through the bugs one by one with the caveat that if the bug was reported against a previous version of Ubuntu, we need to validate whether it still is an issue or if it has been solved since then. Bruno From sense at qense.nl Wed Jan 6 19:25:36 2010 From: sense at qense.nl (Sense Hofstede) Date: Wed, 6 Jan 2010 20:25:36 +0100 Subject: Adopting Nautilus, wiki page created In-Reply-To: <1262722084.2473.52.camel@nuuk> References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> Message-ID: 2010/1/5 Bruno Girin : > On Tue, 2010-01-05 at 18:39 +0100, Sense Hofstede wrote: >> 2010/1/5 Bruno Girin : >> > On Fri, 2010-01-01 at 14:24 +0100, Sense Hofstede wrote: >> >> Hello, >> >> >> >> I've created a wiki page at >> >> . I've added >> >> some information to the page and came up with three tasks: 'New Bugs', >> >> 'Confirmed Bugs' and 'Forwarding upstream'. >> >> >> >> What do you think of the page? Is the information correct and sufficient? >> > >> > It's a great start. I think we could extend the information by being >> > more specific in what is expected of people when dealing with bugs in >> > the "New", "Confirmed" or "Triaged" states. Some of it is explained in >> > the HowToTriage page [1] but we could be more specific here. Here are a >> > few ideas to start with: >> > >> > When a bug is New, the aim is to move it to Confirmed or Invalid, >> > depending on whether we can re-create it or not, or mark it as duplicate >> > of another bug. In some cases, we may need more information, in which >> > case, it should be changed to Incomplete first and we should start a >> > dialogue with the original reporter to be able to re-create. In all >> > cases, this first pass should be an opportunity to improve the bug >> > report (even if we can re-create it easily) and rewrite it in the form: >> >      * Steps to recreate >> >      * Expected behaviour >> >      * Actual behaviour >> > >> > That's the theory. In practice, how do we deal with the more complex or >> > arcane bugs that require certain configuration or hardware that the >> > triager doesn't necessarily have? For instance, if there is a bug report >> > about iPod integration and the triager doesn't have an iPod, how do we >> > move it forward? >> > >> > Once a bug is in the Confirmed state, it should be moved to Triaged, >> > which only Bug Control members can do. I think that if the previous >> > phase is done properly, moving bugs to triaged should be >> > straightforward. So for this to work, it would be useful to know what >> > Bug Control members look for in a confirmed bug to consider it triaged. >> > Sense, what would you want to see in a bug report to move it to Triaged? >> > >> > Once bugs have been triaged, the aim is to get them resolved. Some of >> > them will be resolved by the Ubuntu developers, others need forwarding >> > upstream. How is that identified, who is responsible for making that >> > decision and how is this communicated in the bug report? At the moment >> > there are 559 bugs against Nautilus in the Triaged state. That's a lot >> > so I suspect that a number are old and have actually been resolved but >> > never closed, while others have not been addressed and may have given >> > the original reporter the impression that nobody cared about his >> > problem. How do we move them forward? >> > >> > Sorry about all the questions, I'm sure some of them are answered on the >> > wiki but I've struggled to find that info and it might be useful to >> > answer them in the Nautilus context. Also if any of my assumptions above >> > are incorrect in terms of the triaging process, please point it out. >> > >> >> >> >> Yazen, Marcos and Bruno, I'm glad you're interested. I've only added >> >> myself to the table because I don't know what you would like to do. If >> >> you'd tell me that and give me your name on the wiki I'll add you, but >> >> if you add yourself to the table that's fine too. >> > >> > Thanks, I added myself to the wiki. >> > >> >> >> >> Erick and David, you said you hadn't started with triaging yet. I >> >> would recommend you to gain a bit more experience before adopting a >> >> package. At you'll find >> >> more information about the mentoring process, I suggest to read that >> >> and apply for a mentor. >> > >> > Thanks, that will be useful to me too :-) >> > >> > [1] https://wiki.ubuntu.com/Bugs/HowToTriage >> > >> > Bruno >> > >> Hello, >> >> First of all, don't apologise for asking questions! Your mail >> contained some good suggestions and you ask some valid questions. >> Furthermore, like someone whose name I forgot once said, there are no >> bad questions, only bad answers. >> >> The explanations of the different tasks and the actions you're >> expected to execute when doing them could and should be more extensive >> indeed. However, I'm not sure if it would be a wise decision to write >> everything again and again on each adoption page. Not only would it be >> a lot of work to update this, it would also make the page longer and >> divert attention from the content that actually matters for the >> adoption group. >> What I would suggest is to write a separate page that briefly explains >> all tasks and then provides a link to a more extensive description. >> This page could be included on all adoption pages. > > Completely agree, it makes no sense to repeat them in each adoption > page. On the other hand, we can start by having a draft in the Nautilus > adoption page and move them to generic pages (either new or existing) > once we've applied them enough to be confident that they work. > >> >> Bug descriptions are often incomplete and don't reflect the bug report >> properly. I also often don't extend the bug descriptions, even though >> it would be desirable. However, it is a lot of work to do this for all >> bug reports. We could mention it in the explanation of the first task, >> but I think that it is more something the Bug Squad as a whole should >> pay attention to. Furthermore I think that it would be better to spend >> our energy on triaging bug reports and making sure they are either >> marked as Invalid or are of use to the developers and packagers. We >> can't afford to do much else with so many bug reports. > > I'd say we can't afford not to improve the description. Once a bug is > triaged, it will end up with the developers. They then see the bug for > the first time and the first details they read will be the title and > description. As a (ex-)developer myself, I can guess what happens next: > if the description is vague or requires the developer to read through > dozens of additional comments, he will just ignore it and go to the next > bug report because he can't afford to lose time trying to understand the > bug. If the description is clear, he will just try out, have an "oh > yes!" moment and fix the bug before lunchtime. > > At the end of the day, the triaging process is the first phase of > getting a bug resolved. If bugs that come out of triaging are such that > the developers don't pick them up, we've failed. I agree with you that > we have a resource problem based on the number of bugs but I'd rather > triage 5 bugs and have all of them resolved than triage 25 and have 2 > resolved. > > I think this is even more important for bugs that need forwarding > upstream because the person doing the forwarding may not be the same as > the person who did the original triage. Considering that the forwarder > will have to summarise the bug in the upstream system, the risk is that > the upstream summary is incorrect. > I agree that the description is important. Really bad descriptions should indeed be improved and, if you've got the change, any description. However, I wouldn't improve bad/insufficient descriptions when the rest of the bug report makes the problem clear enough and the description isn't really hindering the developers. >> >> It is the task of the triager to determine whether the bug has to be >> forwarded upstream. The description, title and replies of/to the bug >> report should make this clear. Packaging errors are mostly Ubuntu >> bugs, unless the package was synced from Debian. In that case it >> should be forwarded to Debian. >> There is a separate task/subgroup for forwarding upstream because it >> is a disruption of your work when you have to leave Launchpad and not >> everyone is familiar with GNOME Bugzilla. I though it would be better >> to let people that focus on triaging bugs in Launchpad focus on >> triaging bugs in Launchpad. When a bug should be forwarded upstream >> they can open an empty task against the upstream project with the >> "Also affects project" button. > > That makes sense. I am comfortable with Bugzilla so am happy to do some > upstream forwarding for Nautilus. Having said that, is there a way to > see what bugs have been marked as needing forwarding but have not > actually been forwarded yet? > When you open an empty task with the "Also affects project" button and not filling anything in the fields. You can search those with the Advanced Search functionality, or by copying parts of the URL of the wiki link to all bugs in Ubuntu with an empty upstream task[1]. > >> >> Maybe it would indeed be wise to create a temporary focus group that >> goes to all bugs that were or weren't triaged and that are forgotten. >> It would be a lot of work to clean those bug reports, but it would be >> worth it. When it is done it is the task of the adoption group to make >> sure the adopted package stays in shape. > > One first step would be to identify all bugs that are in the Triaged > state but that haven't been forwarded upstream. That will give us an > idea of how big the problem is. > > Alternatively, we can just go through the bugs one by one with the > caveat that if the bug was reported against a previous version of > Ubuntu, we need to validate whether it still is an issue or if it has > been solved since then. > Going through old bug reports will require to check whether they still apply to the current version of Nautilus. This (all combined) is indeed a lot of work, but it is something we'll have to do when we want to get Nautilus clean. [1] https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=pending_bugwatch&field.status_upstream-empty-marker=1 Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From marcosvanetta at gmail.com Wed Jan 6 21:03:45 2010 From: marcosvanetta at gmail.com (Marcos Vanetta) Date: Wed, 6 Jan 2010 18:03:45 -0300 Subject: Fwd: Adopting Nautilus, wiki page created In-Reply-To: References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> Message-ID: <4cfc0be71001061303n5c8fe860l53ba2db34e338ec0@mail.gmail.com> I've added my self to the wiki :D I'm gonna start checking the new bugs! regards malev -- Ing. Marcos Vanetta http://blog.malev.com.ar twitter: @malev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sense at qense.nl Wed Jan 6 21:13:15 2010 From: sense at qense.nl (Sense Hofstede) Date: Wed, 6 Jan 2010 22:13:15 +0100 Subject: Adopting Nautilus, wiki page created In-Reply-To: References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> Message-ID: Hello, A small update from what I've done and what I plan on doing. I did move the task descriptions to and added a new 'Old Bugs' task for checking the old bug reports. The TaskDetails[1] page is included on the Nautilus adoption page[2] and uses variables to make sure the links are right for all packages. I've created a variable dictionary for Launchpad[3] with the 'long' name (Nautilus), the short name (nautilus) and the name of and the link to the upstream bug tracker (GNOME Bugzilla). I also created a page that can be used for listening the tasks and structure of AdoptionTeams[4], the name I came up with. Of course those teams are only necessary for larger packages, smaller applications will just need one or two people. The page is still pretty empty at the moment, but I plan on extending it. Other things I want to do soon: * Blog about Adopt-a-Package * Write an entry point wiki page explaining to new community members, community members new to bug triaging and bug triagers what Adopt-a-Package is and how to join (* Create banners and stuff?) * Triage Nautilus bug reports [1] https://wiki.ubuntu.com/BugSquad/AdoptPackage/TaskDetails [2] https://wiki.ubuntu.com/BugSquad/AdoptPackage/Nautilus [3] https://wiki.ubuntu.com/BugSquad/AdoptPackage/Nautilus/VarDic [4] https://wiki.ubuntu.com/BugSquad/AdoptionTeam Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From brunogirin at gmail.com Wed Jan 6 21:31:20 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Wed, 06 Jan 2010 21:31:20 +0000 Subject: Adopting Nautilus, wiki page created In-Reply-To: References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> Message-ID: <1262813480.3355.17.camel@nuuk> On Wed, 2010-01-06 at 20:25 +0100, Sense Hofstede wrote: > >> Bug descriptions are often incomplete and don't reflect the bug report > >> properly. I also often don't extend the bug descriptions, even though > >> it would be desirable. However, it is a lot of work to do this for all > >> bug reports. We could mention it in the explanation of the first task, > >> but I think that it is more something the Bug Squad as a whole should > >> pay attention to. Furthermore I think that it would be better to spend > >> our energy on triaging bug reports and making sure they are either > >> marked as Invalid or are of use to the developers and packagers. We > >> can't afford to do much else with so many bug reports. > > > > I'd say we can't afford not to improve the description. Once a bug is > > triaged, it will end up with the developers. They then see the bug for > > the first time and the first details they read will be the title and > > description. As a (ex-)developer myself, I can guess what happens next: > > if the description is vague or requires the developer to read through > > dozens of additional comments, he will just ignore it and go to the next > > bug report because he can't afford to lose time trying to understand the > > bug. If the description is clear, he will just try out, have an "oh > > yes!" moment and fix the bug before lunchtime. > > > > At the end of the day, the triaging process is the first phase of > > getting a bug resolved. If bugs that come out of triaging are such that > > the developers don't pick them up, we've failed. I agree with you that > > we have a resource problem based on the number of bugs but I'd rather > > triage 5 bugs and have all of them resolved than triage 25 and have 2 > > resolved. > > > > I think this is even more important for bugs that need forwarding > > upstream because the person doing the forwarding may not be the same as > > the person who did the original triage. Considering that the forwarder > > will have to summarise the bug in the upstream system, the risk is that > > the upstream summary is incorrect. > > > > I agree that the description is important. Really bad descriptions > should indeed be > improved and, if you've got the change, any description. However, I wouldn't > improve bad/insufficient descriptions when the rest of the bug report makes the > problem clear enough and the description isn't really hindering the developers. To be done at the discretion of the triager then. > > >> > >> It is the task of the triager to determine whether the bug has to be > >> forwarded upstream. The description, title and replies of/to the bug > >> report should make this clear. Packaging errors are mostly Ubuntu > >> bugs, unless the package was synced from Debian. In that case it > >> should be forwarded to Debian. > >> There is a separate task/subgroup for forwarding upstream because it > >> is a disruption of your work when you have to leave Launchpad and not > >> everyone is familiar with GNOME Bugzilla. I though it would be better > >> to let people that focus on triaging bugs in Launchpad focus on > >> triaging bugs in Launchpad. When a bug should be forwarded upstream > >> they can open an empty task against the upstream project with the > >> "Also affects project" button. > > > > That makes sense. I am comfortable with Bugzilla so am happy to do some > > upstream forwarding for Nautilus. Having said that, is there a way to > > see what bugs have been marked as needing forwarding but have not > > actually been forwarded yet? > > > > When you open an empty task with the "Also affects project" button and > not filling > anything in the fields. You can search those with the Advanced Search > functionality, > or by copying parts of the URL of the wiki link to all bugs in Ubuntu > with an empty > upstream task[1]. I tried that but it returned only 7 bugs, which doesn't feel right. Then again, going through a number of bugs today, it looks like most of them have been forwarded upstream but they are still new in the upstream bug tracker. I don't know if it means that upstream are not interested, don't have the time or resources or if they actually resolve them but don't update their bug tracker. > >> > >> Maybe it would indeed be wise to create a temporary focus group that > >> goes to all bugs that were or weren't triaged and that are forgotten. > >> It would be a lot of work to clean those bug reports, but it would be > >> worth it. When it is done it is the task of the adoption group to make > >> sure the adopted package stays in shape. > > > > One first step would be to identify all bugs that are in the Triaged > > state but that haven't been forwarded upstream. That will give us an > > idea of how big the problem is. > > > > Alternatively, we can just go through the bugs one by one with the > > caveat that if the bug was reported against a previous version of > > Ubuntu, we need to validate whether it still is an issue or if it has > > been solved since then. > > > > Going through old bug reports will require to check whether they still > apply to the current version of Nautilus. This (all combined) is indeed a lot > of work, but it is something we'll have to do when we want to get Nautilus > clean. The earlier we start the earlier we finish then. However, how do we coordinate that? For every bug that is now resolved, we can move it to the "Invalid" state and take it off the list but what about bugs that are still outstanding? How do each of us highlight what bugs he's re-confirmed so that we don't duplicate effort? Use a specific tag? And what should we do with bugs that we can't test for whatever reason? Send a message to this list to ask for someone to have a look at it? Regards, Bruno From brunogirin at gmail.com Wed Jan 6 21:49:07 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Wed, 06 Jan 2010 21:49:07 +0000 Subject: Adopting Nautilus, wiki page created In-Reply-To: References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> Message-ID: <1262814547.3355.21.camel@nuuk> On Wed, 2010-01-06 at 22:13 +0100, Sense Hofstede wrote: > Hello, > > A small update from what I've done and what I plan on doing. > I did move the task descriptions to > and > added a new 'Old Bugs' task for checking the old bug reports. > > The TaskDetails[1] page is included on the Nautilus adoption page[2] and > uses variables to make sure the links are right for all packages. I've created > a variable dictionary for Launchpad[3] with the 'long' name > (Nautilus), the short > name (nautilus) and the name of and the link to the upstream bug tracker > (GNOME Bugzilla). It looks like the variable dictionary page doesn't work and therefore pages [1] and [2] don't show the correct information either. Another question I forgot to ask: for bugs that I confirm and that need forwarding upstream, do you want me to wait until you've moved the bug to the "Triaged" status before forwarding upstream or would you rather I forwarded it straight away? Bruno From martinmai-ubuntu at web.de Thu Jan 7 18:52:58 2010 From: martinmai-ubuntu at web.de (Martin Mai) Date: Thu, 07 Jan 2010 19:52:58 +0100 Subject: Some changes to https://wiki.ubuntu.com/Bugs/Responses Message-ID: <1262890378.7241.4.camel@martin-laptop> Hi there, I have added some frequently used responses to the section [1]. I often wanted to respond in that way (others use them regularly), but figured out that they haven't been added to the responses page in the wiki. [1] https://wiki.ubuntu.com/Bugs/Responses#A bug that should be handled upstream Regards Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jorge at ubuntu.com Thu Jan 7 19:41:28 2010 From: jorge at ubuntu.com (Jorge O. Castro) Date: Thu, 7 Jan 2010 14:41:28 -0500 Subject: Making it easier for people to work with upstreams Message-ID: Hi everyone, At UDS we had a discussion on how people can be better "upstream contacts". This is that person that picks their favorite little app and does their best to work with an upstream to get the bugs to the right place. I've started to put together a little "best practices" guide for people who want to do this kind of thing: https://wiki.ubuntu.com/Upstream/Contacts This person could be a person who is just doing general bug work, or someone who wants to work on a specific application. Since many of you tend to do this kind of work already I was hoping for some feedback on this page and see if it matches up with the kinds of things you might be talking to upstreams about. The idea for this page is if someone who wants to make Foobar better then they have a general idea of what kinds of things they can do to help move bugs along. Thoughts? -- Jorge Castro jorge (at) ubuntu.com External Project Developer Relations Canonical Ltd. From sense at qense.nl Mon Jan 11 16:25:07 2010 From: sense at qense.nl (Sense Hofstede) Date: Mon, 11 Jan 2010 17:25:07 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: 2010/1/7 Jorge O. Castro : > Hi everyone, > > At UDS we had a discussion on how people can be better "upstream > contacts". This is that person that picks their favorite little app > and does their best to work with an upstream to get the bugs to the > right place. I've started to put together a little "best practices" > guide for people who want to do this kind of thing: > https://wiki.ubuntu.com/Upstream/Contacts > > This person could be a person who is just doing general bug work, or > someone who wants to work on a specific application. Since many of you > tend to do this kind of work already I was hoping for some feedback on > this page and see if it matches up with the kinds of things you might > be talking to upstreams about. The idea for this page is if someone > who wants to make Foobar better then they have a general idea of what > kinds of things they can do to help move bugs along. Thoughts? > > -- > Jorge Castro > jorge (at) ubuntu.com > External Project Developer Relations > Canonical Ltd. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > Hello, Reading the task description it does seem something that could become a very valuable addition to the Ubuntu community. However, it does have overlap with the Adopt-a-Package project that was discussed at the UDS -- for which I've started already with setting up a team adopting Nautilus[1]. The functioning of an 'AdoptionTeam' is further explained on the wiki[2]. Keeping an eye on the bugs and forwarding them upstream is both a task of the Upstream Contact and the AdoptionTeam. However, the Upstream Contact also should watch the patches and actively contribute to the development and position of the package with regard to Ubuntu. It makes no sense to do almost the same thing twice. Maybe we should add some ideas of Adopt-a-Pacakge to the Upstream Contact principle and make it a team. Something like a PackageFocusGroup or ApplicationAdopters. That team could have people watching the patches, people working on integrating its development in the Ubuntu release cycle, possibly the person or persons packaging the application, a group of people triaging bug reports, someone upstream can call if they want to call Ubuntu and who noitifies upstream of Ubuntu plans affecting upstream, and someone who keeps everything organised on the wiki and between people. People could do multiple tasks or one task or parts of multiple tasks, just what they'd like to do. It would be impossible to have large teams for all packages, something like Guake doesn't need a squad full of specialists to keep it healthy, but packages like X.org and the Linux kernel could benefit greatly from it. GNOME could be sliced into different pieces, but maybe it would also be good to keep things like the core libraries in one team. I hope I'm not disturbing someone's precious plans right now, or am repeating things that are already planned. However, I would find it a waste if something like Adopt-a-Package would disappear because of this, and I would find it bad when there would exist two different structures with the same purpose next to each other. [1] https://wiki.ubuntu.com/BugSquad/AdoptPackage/Nautilus [2] https://wiki.ubuntu.com/BugSquad/AdoptionTeam Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From sense at qense.nl Mon Jan 11 16:28:09 2010 From: sense at qense.nl (Sense Hofstede) Date: Mon, 11 Jan 2010 17:28:09 +0100 Subject: Adopting Nautilus, wiki page created In-Reply-To: <1262814547.3355.21.camel@nuuk> References: <1262697183.2384.68.camel@nuuk> <1262722084.2473.52.camel@nuuk> <1262814547.3355.21.camel@nuuk> Message-ID: 2010/1/6 Bruno Girin : > On Wed, 2010-01-06 at 22:13 +0100, Sense Hofstede wrote: >> Hello, >> >> A small update from what I've done and what I plan on doing. >> I did move the task descriptions to >> and >> added a new 'Old Bugs' task for checking the old bug reports. >> >> The TaskDetails[1] page is included on the Nautilus adoption page[2] and >> uses variables to make sure the links are right for all packages. I've created >> a variable dictionary for Launchpad[3] with the 'long' name >> (Nautilus), the short >> name (nautilus) and the name of and the link to the upstream bug tracker >> (GNOME Bugzilla). > > It looks like the variable dictionary page doesn't work and therefore > pages [1] and [2] don't show the correct information either. > > Another question I forgot to ask: for bugs that I confirm and that need > forwarding upstream, do you want me to wait until you've moved the bug > to the "Triaged" status before forwarding upstream or would you rather I > forwarded it straight away? > > Bruno > > > Hello, I would wait with forwarding upstream until you've got something useful for them. Mostly that means the bug has been fully Triaged, although the status 'Triaged' is also often used when all work to the bug is done, including forwarding upstream. Just ask yourself everything you want to forward a bug upstream if it is confirmed and if the report contains enough details to be solvable upstream. If that's true then you can forward it upstream; the bug also deserves the status 'Triaged' by then. I'll look into the variable problems later, when I have more time. Currently I've got a busy period at school with a lot of tests coming up soon. Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From jorge at ubuntu.com Mon Jan 11 17:52:22 2010 From: jorge at ubuntu.com (Jorge O. Castro) Date: Mon, 11 Jan 2010 12:52:22 -0500 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: On Mon, Jan 11, 2010 at 11:25 AM, Sense Hofstede wrote: > I hope I'm not disturbing someone's precious plans right now, or am > repeating things that are already planned. However, I would find it a > waste if something like Adopt-a-Package would disappear because of > this, and I would find it bad when there would exist two different > structures with the same purpose next to each other. As far as I understand it the UpstreamContacts bit is a subset of Adopt-an-Upstream. Daniel? -- Jorge Castro jorge (at) ubuntu.com External Project Developer Relations Canonical Ltd. From komputes at gmail.com Mon Jan 11 21:04:03 2010 From: komputes at gmail.com (komputes) Date: Mon, 11 Jan 2010 19:04:03 -0200 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: <4B4B9243.9050600@gmail.com> Jorge O. Castro wrote: > At UDS we had a discussion on how people can be better "upstream > contacts". This is that person that picks their favorite little app > and does their best to work with an upstream to get the bugs to the > right place. I've started to put together a little "best practices" > guide for people who want to do this kind of thing: > https://wiki.ubuntu.com/Upstream/Contacts > > This person could be a person who is just doing general bug work, or > someone who wants to work on a specific application. Since many of you > tend to do this kind of work already I was hoping for some feedback on > this page and see if it matches up with the kinds of things you might > be talking to upstreams about. The idea for this page is if someone > who wants to make Foobar better then they have a general idea of what > kinds of things they can do to help move bugs along. Thoughts? > > On Mon, Jan 11, 2010 at 11:25 AM, Sense Hofstede wrote: > >> I hope I'm not disturbing someone's precious plans right now, or am >> repeating things that are already planned. However, I would find it a >> waste if something like Adopt-a-Package would disappear because of >> this, and I would find it bad when there would exist two different >> structures with the same purpose next to each other. >> > > As far as I understand it the UpstreamContacts bit is a subset of > Adopt-an-Upstream. Daniel? > > Jorge, My feedback... = Adopt-a-Package = Adopting an entire upstream (as mentioned in the above 'Adopt-an-upstream') in *most* cases is a very large job (unless the upstream only has a few projects, or one project). I would suggest that we continue via the "Adopt-a-Package" initiative where every bugsquad member who wants to better an application/package can focus attention on said package, its bugs/answers and its upstream BugTracker/IRC/Mailinglist. Personal idea: I would not restrict this to "1 package per user" either since more eyes will find a solution quicker and letting bugsquad members decide what they can handle shows that we care and appreciate that they can put their interest in any (and as many) project they feel is worth their time. In time, and in certain projects this will grow to be a group of people (AdoptionTeam) adopting a package. = Upstream Contacts = There is nothing wrong with keeping one foot in an Upstream and one in Ubuntu, and becoming a reliable Liaison Officer between an upstream and a distribution. Call it what you will: Liason, Bridge, Upstream Contact - Keep in mind this is not a position *anyone* should be able to take on, and definitely is not a task that can be picked up in a few days by a novice willing to help. If plans go forward, and this does in fact happen, it should be assigned by council and not self-assigned. The person selected should be an Ubuntu member and be involved in development upstream. I will quote a statement on the wiki at this point, as I completely agree: "It would be nice if upstream projects had an 'Ubuntu person' who cared about that project and its standing in Ubuntu" This statement is true (yes, it would be nice,) but is not always possible. For the cases where it is not possible to find an upstream developer who wants to be the contact for Ubuntu, then I think an Ubuntu Member (already in BugSquad and BugControl) who has proved themselves through the adoption of most packages in said upstream, should become *the* Liaison Officer for that upstream. This position *would* be a 1-to-1 relation. The person should voluntarily want to be the Liaison Officer (knowing fully what responsibilities they are taking on) and be voted in by council after having been carefully reviewed. = Some extra notes = 1) Where I disagree with the wiki: "This kind of role doesn't necessarily need to be technical." -For a 'Package Adopter' this is true -For a 'Liaison Officer' this is false (lots of patchwork and development involved) 2) Worspaces can be used for Liaison Officers to delegate required tasks to Package Adopters and BugSquad Members 3) Most of what you mentioned on the wiki should be done by 'Package Adopters'. This includes: bug ownership, stale bug checking, testing, version tracking, patch notifying, sync requesting, upstream updating, schedule notifying, IRC presence, mailing list presence. 4) 'Liaison Officer' should be involved in more high level actions and decisions. This includes: patch review, going to upstream sprints, going through top bugs and working/coordinating to release fixes. = Final notes = I hope that Jorge and BugSquad members will agree. I would love to get feedback on this concept. I also think this will give some much needed structure to the https://wiki.ubuntu.com/Upstream/ page and sub-pages. I sincerely thank you for your time. -komputes (]( -. .- )[) From mathieu.tl at gmail.com Tue Jan 12 00:43:24 2010 From: mathieu.tl at gmail.com (Mathieu Trudel) Date: Mon, 11 Jan 2010 19:43:24 -0500 Subject: Making it easier for people to work with upstreams In-Reply-To: <4B4B9243.9050600@gmail.com> References: <4B4B9243.9050600@gmail.com> Message-ID: <1263257004.22851.126.camel@selene> Le lundi 11 janvier 2010 à 19:04 -0200, komputes a écrit : > = Adopt-a-Package = > > Adopting an entire upstream (as mentioned in the above > 'Adopt-an-upstream') in *most* cases is a very large job (unless the > upstream only has a few projects, or one project). I would suggest that > we continue via the "Adopt-a-Package" initiative where every bugsquad > member who wants to better an application/package can focus attention on > said package, its bugs/answers and its upstream BugTracker/IRC/Mailinglist. > It's funny, I had seen things differently and in a way that was (I think) more in line with what Sense was saying: that there was duplication of work and purpose between upstream adoption and package adoption. Or perhaps I'm just misunderstanding the whole idea? To be precise, I see "upstream project" as a rather less all-encompassing concept. For example, I think NetworkManager rocks, and I view things more like adopting that specific software project, for which I know the ecosystem, rather than adopting GNOME as a whole. While GNOME in general is awesome, there are some packages for which I know nothing of the technical details. > Personal idea: I would not restrict this to "1 package per user" either > since more eyes will find a solution quicker and letting bugsquad > members decide what they can handle shows that we care and appreciate > that they can put their interest in any (and as many) project they feel > is worth their time. In time, and in certain projects this will grow to > be a group of people (AdoptionTeam) adopting a package. > Agreed. I've already started setting myself as the bug contact on a couple of packages I use regularly, of which I know the technical aspects fairly well, or at least well enough to be able to upstream a bug or even write a draft patch. [...] > > If plans go forward, and this does in fact happen, it should be assigned > by council and not self-assigned. The person selected should be an > Ubuntu member and be involved in development upstream. I will quote a > statement on the wiki at this point, as I completely agree: > I don't think this would work well for some smaller projects (say, concordance or congruity), or for which the upstream is a Sourceforge project. While it's true that Debian is the more "direct" upstream for Ubuntu, it may be worthwhile to send some stuff directly up there, to the true software author, and let everybody benefit... just like again, it would be a daunting task to take on being the contact for the whole Debian project. [...] > = Some extra notes = > > 1) Where I disagree with the wiki: "This kind of role doesn't > necessarily need to be technical." > -For a 'Package Adopter' this is true > -For a 'Liaison Officer' this is false (lots of patchwork and > development involved) > I guess the following two paragraphs go more into what you mention later: Why would being an upstream contact necessarily mean that you would have to do patchwork? While I agree it is possible, one could also just know the Ubuntu and upstream development cycle really well, who usually takes care of the package and who the main upstream contact is (the project leader or some main developer), and simply coordinate the work. Especially if the "Liaison Officer" doesn't have commit rights upstream, why approve patches twice? > 2) Worspaces can be used for Liaison Officers to delegate required tasks > to Package Adopters and BugSquad Members At the same time, we have LP to delegate stuff. We could discuss this further, but my opinion is that would be better left to each "adopters' team" to decide how to do the day-to-day work. / Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Ceci est une partie de message numériquement signée URL: From hggdh2 at ubuntu.com Tue Jan 12 02:03:28 2010 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Mon, 11 Jan 2010 20:03:28 -0600 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: <4B4BD870.2030204@ubuntu.com> On 01/11/10 11:52, Jorge O. Castro wrote: > On Mon, Jan 11, 2010 at 11:25 AM, Sense Hofstede wrote: > >> I hope I'm not disturbing someone's precious plans right now, or am >> repeating things that are already planned. However, I would find it a >> waste if something like Adopt-a-Package would disappear because of >> this, and I would find it bad when there would exist two different >> structures with the same purpose next to each other. >> > As far as I understand it the UpstreamContacts bit is a subset of > Adopt-an-Upstream. Daniel? > This is also my understanding. Hopefully answering Sense's point more directly: (again, to my understanding) adopt-a-package is a bug-(squad|control) activity, where we are trying to achieve a faster and, ah, effectiver response to Ubuntu bugs. There is no real requirement in it to be a formal contact upstream. Nothing prohibits, or inhibits, an adopter to eventually being an upstream contact, though. On adopt-an-upstream, we are looking for a formal (as much as possible) contact with an upstream. I would, anyway, never expect these positions to be filled by *one* *single* person, but by a group of persons. Two (of the many) reasons for this are: * if you have one person, you have noone -- all that is needed is for this person to get sick, or be overwhelmed by real work, and we lose the contact with upstream; * one person has to sleep, eat, work, have a personal life -- this means no 24x7 coverage. This might not sound critical, but I remember one upstream project that had weekly meetings at 04:00 my TZ every week. In one year, I participated in two of them (because of insomnia!). I would have been much more productive for us if there were more of us that would be able to attend the meetings. FWIW, all the times I discussed this I never thought of, or expected, one single person to deal with one entire upstream (like, say, Debian, or GNOME, or KDE, or GNU, etc). There are, of course, situations that deal with the generic upstream (e.g., Debian directions and policies, and Ubuntu directions and policies); in those cases, this would be a discussion between the councils (or equivalents) and their proxies on both sides, since this would probably require folks with some commit power. Which is to say: adopt-an-upstream is (to my understanding) much more geared towards *packages* in any upstream, than to the *whole* upstream. We have to keep in mind that there are whole upstreams (that deal with policies) and there are the projects under them (that deal with actual packages, or directions). Each of these projects will most probably have its own way of working. This is where adopt-an-upstream would really shine. ..C.. p.s. Just for the record, I have no commit power in Ubuntu, but I would still adopt-an-upstream, and adopt-some-packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From komputes at gmail.com Tue Jan 12 16:11:31 2010 From: komputes at gmail.com (komputes) Date: Tue, 12 Jan 2010 14:11:31 -0200 Subject: Requesting review of a proposed merge of 3 large nspluginwrapper bugs Message-ID: <4B4C9F33.1090800@gmail.com> There are 3 very large nspluginwrapper bugs that have many affected users. I would like to know if these should be merged. They all seem to have similar symptoms and indications: -amd64 -flash (32-bit) -firefox with flash content -npviewer.bin segfaults on reading/writing VMA when firewfox and flash content are present. The bug numbers are: https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613 https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/178038 https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/192270 As well I believe (from reading comments) that the release of 64-bit Adobe Flash resolves/fixes this issue. This is something I would request testing for once these bugs are merged. Any insight on these bugs and the proposed merge would be helpful. Cheers, -komputes (]( -. .- )[) From shingomizuno1984 at yahoo.co.jp Sun Jan 10 02:41:01 2010 From: shingomizuno1984 at yahoo.co.jp (shingomizuno1984 at yahoo.co.jp) Date: Sun, 10 Jan 2010 02:41:01 -0000 Subject: ubuntu 10.04 alpha1's sound Message-ID: <20100110024101.771.51241.launchpad@wampee.canonical.com> hello im using latest 10.04 alpha1 on virtualbox (latest version too) but i found little bit problem of sounds. i saw youtube video but i could musics is so slow seem like who guy using voice changer. i meant low ton but video motion was good work at youtube. different only sounds and rhythembox. my setting is 365MB memory, 8GB HDD on virtualbox and im using them on macbook pro 13inch intel core 2 duo 2.26GHz. -- This message was sent from Launchpad by the user shingomizuno1984 at yahoo.co.jp (https://launchpad.net/~shingomizuno1984) using the "Contact this team" link on the Ubuntu BugSquad team page. For more information see https://help.launchpad.net/YourAccount/ContactingPeople From daniel.holbach at ubuntu.com Wed Jan 13 11:29:17 2010 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 13 Jan 2010 12:29:17 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: <1263382157.4675.10.camel@miyazaki> Hello everybody, Am Montag, den 11.01.2010, 17:25 +0100 schrieb Sense Hofstede: > It makes no sense to do almost the same thing twice. Maybe we should > add some ideas of Adopt-a-Pacakge to the Upstream Contact principle > and make it a team. Something like a PackageFocusGroup or > ApplicationAdopters. That team could have people watching the patches, > people working on integrating its development in the Ubuntu release > cycle, possibly the person or persons packaging the application, a > group of people triaging bug reports, someone upstream can call if > they want to call Ubuntu and who noitifies upstream of Ubuntu plans > affecting upstream, and someone who keeps everything organised on the > wiki and between people. > People could do multiple tasks or one task or parts of multiple tasks, > just what they'd like to do. When we started thinking of "Adopt an Upstream" it was the name of an initiative. It's not meant to replace anything. The discussion: - what is confusing in our processes today - what we need to clarify in terms of documentation - how interested people find out about the possibilities - how we learn from each other and form best practices to me is much more important than the name of the group people who are part of the initiative or the name of the initiative itself. We want to revisit how people who are passionate about a certain piece of software can be most useful, both to Ubuntu and upstream. This was never meant to replace anything or shut-down any other initiative. > It would be impossible to have large teams for all packages, something > like Guake doesn't need a squad full of specialists to keep it > healthy, but packages like X.org and the Linux kernel could benefit > greatly from it. GNOME could be sliced into different pieces, but > maybe it would also be good to keep things like the core libraries in > one team. I'm sure this will happen naturally. Interested new people will flock to either pieces of software they are interested in or a list of things that are advertised as TODO. There are folks who are interested in getting the masses of bugs under control, others like to fix bugs with small patches, others want to track work that's going on upstream and integrate it in Ubuntu and some might want to do all of this. It'd be nice if those people find each other easily, but I'm not sure it's a good idea to plan those teams first thing now. What I do think we should make clear though is that there is no "big maintainer lock" and there's nobody who handles one project exclusively and that we want to collaborate as good as we can. Have a great day, Daniel From kamusin at gmail.com Wed Jan 13 12:42:51 2010 From: kamusin at gmail.com (Kamus) Date: Wed, 13 Jan 2010 09:42:51 -0300 Subject: Announcing the Next Ubuntu Hug Day! - Thursday 14 January 2010 Message-ID: Fellow Ubuntu Triagers! This week's Bug Day target is *drum roll please* gnome-power-manager! * 100 New bugs need a hug * 100 Incompletes bugs * 65 Confirmed bugs need a review * 12 Bugs needs to be forwarded Bookmark it, add it to your calendars, turn over those egg-timers!  * Thursday 14 January 2010  * https://wiki.ubuntu.com/UbuntuBugDay/20100114 Are you looking for a way to start giving some love back to your adorable Ubuntu Project? Did you ever wonder what Triage is? Want to learn about that? This is a perfect time!, Everybody can help in a Bug Day! Open your IRC Client and go to #ubuntu-bugs (FreeNode) the BugSquad will be happy to help you to start contributing! Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! We are always looking for new tasks or ideas for the Bug Days, if you have one add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning If you're new to all this (like me!) and you want to know more about ubuntu?, head to http://wiki.ubuntu.com/Bugs Have a nice day,   Kamus [From the BugSquad] -- Victor Vargas B. Latitud: -33.439177,-70.625267 Santiago, Chile. From komputes at gmail.com Wed Jan 13 12:56:41 2010 From: komputes at gmail.com (komputes) Date: Wed, 13 Jan 2010 10:56:41 -0200 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263382157.4675.10.camel@miyazaki> References: <1263382157.4675.10.camel@miyazaki> Message-ID: <4B4DC309.3060705@gmail.com> Daniel Holbach wrote: > - what is confusing in our processes today > I don't find that the current process is very confusing. Some of the 'Upstream' documentation for this initiative is scattered, lacks content, and duplicates efforts that were already made by the BugSquad. The process to help is basically: 1) Person interested in helping with bugs joins BugSquad 2) Person interested in a particular application/package they sign up to adopt the package on https://wiki.ubuntu.com/BugSquad/AdoptPackage 3) Person takes on certain tasks they feel comfortable with to help out > - what we need to clarify in terms of documentation > Generalized documentation is best. Duplicate documentation is not helpful. I don't feel that *every* package should have it's own restrictive 'special process' for working with the upstream, as this will be a lot of work and create unnecessary pollution. For some packages/projects that need personalized documentation on how to work with an upstream, "Workspaces" can be used (although something like that already exists, see below). I think setting general guidelines should do the job for most cases. Let the adopters develop relationships with upstream developers and understand how things are done upstream through experience. As long as upstream contact is done respectfully, I don't foresee issues. That said, I have a few recommendations for the wiki category you guys are building. 1) I do feel that https://wiki.ubuntu.com/Upstream/Contacts need to be easier to read. 2) https://wiki.ubuntu.com/DanielHolbach/Upstream should be merged with https://wiki.ubuntu.com/Upstream 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt Should be merged with (and a link should take its place) https://wiki.ubuntu.com/BugSquad/AdoptPackage 4) I don't find this page useful at all: https://wiki.ubuntu.com/Upstream/Contributions 5) I would put this in a workspace for Debian: https://wiki.ubuntu.com/Upstream/Contributions/Debian 6) Translations should be one thing in a list of what people can do to help listed here: https://wiki.ubuntu.com/Upstream/Contacts 7) The 'Contribution' section at the top of the page can then be removed. 8) I think duplicate work is being done here: https://wiki.ubuntu.com/Bugs/Upstream 9) As well the bottom of /Bugs/Upstream can be merged with /Upstream/Workspaces I think this covers the whole over-documentation/duplication issue I see with this initiative. The initiative becomes more of a central page then for people who are all like 'How can I help with Ubuntu?' > - how interested people find out about the possibilities > This would be the page built by this initiative. This will present possibilities to assist with a package, I would say we create a general checklist of things you can do to help. This was mentioned in my previous email and was based on /Upstream/Contacts > - how we learn from each other and form best practices > Communication: IRC, Mailing Lists. Users should not feel shy to ask for help if they want to learn. One improvement I would request is for users themselves to be able to modify the 'Most active in' section of their Launchpad profile. That way they become contacts for that application/package. For example, I have adopted and been working a lot on usb-creator bugs, but I don't see it in the 'Most active in' section of https://launchpad.net/~komputes Afterwards, being able to find who is active in a project through LP, could be a big step forward. > We want to revisit how people who are passionate about a certain piece > of software can be most useful, both to Ubuntu and upstream. > I think that setting guidelines for the following tasks on the wiki (in an easy, concise and easy to read way) could help passionate people be helpful to a specific project and its upstream: -bug ownership -stale bug checking -testing -version tracking (Compare our version to upstream) -patch notifying (Upstream) -synchronization requesting (From Upstream) -upstream updating (This is what we do which is related to your project) -schedule notifying (This is when we release, will a new version be out by then? What bugs will it fix) -IRC presence (Hang out in the freenode channel for that project, connect to another server if that is where upstream discussion takes place) -mailing list presence -patch review -going to upstream sprints -fixing (going through top confirmed/triaged bugs and working/coordinating to release fixes) -translations I would review https://wiki.ubuntu.com/Upstream/Contacts, order them in simple/medium/hard (depending on user proficiency), shorten the sentences/explanations and link to existing pages which explain the process more thoroughly. Cheers, -komputes (]( -. .- )[) From komputes at gmail.com Wed Jan 13 13:06:33 2010 From: komputes at gmail.com (komputes) Date: Wed, 13 Jan 2010 11:06:33 -0200 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263382157.4675.10.camel@miyazaki> References: <1263382157.4675.10.camel@miyazaki> Message-ID: <4B4DC559.20504@gmail.com> I almost forgot to add to that list... -creating documentation -reviewing stale documentation/wiki -creating a PPA with the latest stable upstream version -creating a PPA with the latest experimental upstream version Cheers, -komputes (]( -. .- )[) From daniel.holbach at ubuntu.com Wed Jan 13 13:44:28 2010 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 13 Jan 2010 14:44:28 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: <4B4DC309.3060705@gmail.com> References: <1263382157.4675.10.camel@miyazaki> <4B4DC309.3060705@gmail.com> Message-ID: <4B4DCE3C.9020508@ubuntu.com> On 13.01.2010 13:56, komputes wrote: > 2) https://wiki.ubuntu.com/DanielHolbach/Upstream > should be merged with > https://wiki.ubuntu.com/Upstream This is a _proposal_ I'm working on right now. > 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt > Should be merged with (and a link should take its place) > https://wiki.ubuntu.com/BugSquad/AdoptPackage I'm not sure about that. The page I started writing there was supposed to give people an overview over ALL the different parts of the community that are an interface between Ubuntu and an Upstream project. It's not meant to replace and BugSquad documentation and it's not supposed to replace a PPA guide or anything that's in UbuntuDevelopment. The idea is to give people who are passionate about some kind of software the necessary overview to afterwards know - where to start in terms of bugs - how to be a bridge between Ubuntu and upstream - how to set up a PPA if they need one - how to get changes uploaded - how to get upload rights later on - where debugging pages live on the wiki - best-practices of user testing - etc. Please note how this spans across multiple parts of the community. This is not intending to overwrite any other initiative of any other part of community. As far as I'm concerned a good overview over what people can do, some cheat-sheets, some clarification, a nice outreach campaign and a way for people share their best-practices would get us a lot more contributors that are 1) passionate and effective about the collaboration with the upstream they care about and 2) a great contributors to the BugSquad, the MOTU team, the testing team, etc. Have a great day, Daniel From brunogirin at gmail.com Wed Jan 13 14:43:56 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Wed, 13 Jan 2010 14:43:56 +0000 Subject: Making it easier for people to work with upstreams In-Reply-To: <4B4DCE3C.9020508@ubuntu.com> References: <1263382157.4675.10.camel@miyazaki> <4B4DC309.3060705@gmail.com> <4B4DCE3C.9020508@ubuntu.com> Message-ID: <1263393836.3082.50.camel@nuuk> On Wed, 2010-01-13 at 14:44 +0100, Daniel Holbach wrote: > On 13.01.2010 13:56, komputes wrote: > > 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt > > Should be merged with (and a link should take its place) > > https://wiki.ubuntu.com/BugSquad/AdoptPackage > > I'm not sure about that. The page I started writing there was supposed > to give people an overview over ALL the different parts of the community > that are an interface between Ubuntu and an Upstream project. It's not > meant to replace and BugSquad documentation and it's not supposed to > replace a PPA guide or anything that's in UbuntuDevelopment. I agree. The scope of adopt-an-upstream is not the same as adopt-a-package. However, both intersect and should work together. For example, Sense started the Adopt Nautilus group. One thing we've identified is that Nautilus has a lot of bugs in the Triaged state that have been reported upstream but that don't seem to have been handled. An upstream adopter could help us with: * moving forward bugs in the upstream tracker * feeding back to us the quality of the bug reports (e.g. is there a piece of information that we should provide on all bug reports to facilitate handling upstream but that we never provide?); this could also lead to developing an apport-plugin for that package to ensure that the missing info becomes included by default * advising us about upcoming functionality that is likely to close bugs so that we don't spend too much time on issues that have already been identified and are in the process of being closed > > The idea is to give people who are passionate about some kind of > software the necessary overview to afterwards know > > - where to start in terms of bugs > - how to be a bridge between Ubuntu and upstream > - how to set up a PPA if they need one > - how to get changes uploaded > - how to get upload rights later on > - where debugging pages live on the wiki > - best-practices of user testing > - etc. I would add to this: * give us advance warning when some functionality is going to be deprecated, change dramatically, or will require a newer version to keep working; e.g. the anki package in Karmic is an older version that cannot connect to the Anki servers anymore because they changed the way client-server interaction worked: knowing this in advance would enable us to upgrade the relevant package before it becomes an issue for users * help us test and validate their packages on the upcoming version of Ubuntu; e.g. the OpenERP version in the Ubuntu repositories only works well with Python 2.5, not 2.6. However, since Karmic (or Jaunty can't remember) the default version of Python is 2.6 => OpenERP doesn't work out of the box; this is now solved in the OpenERP trunk but it means that for it to work on Lucid out of the box we will need to ensure the latest version is used * advise us whether they think we should add other related packages to offer Ubuntu users the best functionality that the upstream can offer; e.g. Karmic has packages for OpenERP server and desktop client but not the web client => adding the web client would make OpenERP more versatile for Ubuntu users > > Please note how this spans across multiple parts of the community. This > is not intending to overwrite any other initiative of any other part of > community. > > As far as I'm concerned a good overview over what people can do, some > cheat-sheets, some clarification, a nice outreach campaign and a way for > people share their best-practices would get us a lot more contributors > that are 1) passionate and effective about the collaboration with the > upstream they care about and 2) a great contributors to the BugSquad, > the MOTU team, the testing team, etc. Agreed. The scope for upstream contacts is orthogonal to the scope of the different teams in the Ubuntu community and people who adopt an upstream may have different interests: ensuring bugs are resolved, talking to devs and MOTU about upcoming features, talking to the art team on visual integration, or to the LoCo teams to do stuff in their community, etc. > > Have a great day, Unlikely at the moment as I've got to write a spec for a customer but it will definitely get a lot better once I reach the pub (snow permitting). Have a great day too! Bruno From sense at qense.nl Wed Jan 13 16:49:29 2010 From: sense at qense.nl (Sense Hofstede) Date: Wed, 13 Jan 2010 17:49:29 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263382157.4675.10.camel@miyazaki> References: <1263382157.4675.10.camel@miyazaki> Message-ID: Hello, Op maandag 13-1-2010 schreef Daniel Holbach : > When we started thinking of "Adopt an Upstream" it was the name of an > initiative. It's not meant to replace anything. > > The discussion: > > - what is confusing in our processes today > - what we need to clarify in terms of documentation > - how interested people find out about the possibilities > - how we learn from each other and form best practices > > to me is much more important than the name of the group people who are > part of the initiative or the name of the initiative itself. > > We want to revisit how people who are passionate about a certain piece > of software can be most useful, both to Ubuntu and upstream. This was > never meant to replace anything or shut-down any other initiative. Good. It's not that I got the impression that the goal of the project was to crush all other related projects and I'm also not interested in a discussion about the names right now. I just wanted to make sure that no efforts would be duplicated and that there wouldn't be worked on two different projects with overlapping goals -- which Bruno already outlined very well. I would suggest to add information to your useful Upstream/Adopt page[1] about the adoption project of the Bug Squad[2]. > What I do think we should make clear though is that there is no "big > maintainer lock" and there's nobody who handles one project exclusively > and that we want to collaborate as good as we can. > This is something I wasn't afraid of, and something I also try to emphasize when writing wiki pages for Adopt-a-Package. I think it would indeed be wise to make this clear for Adopt-an-Upstream as well, like you said, in order to not scare casual contributors and novices away. Komputes has some good points and I agree with them. Lets see if I understand the project well enough already. There is Adopt-an-Upstream, which is a group of people focussed on a particular part of an upstream project, mostly centred around a certain application. The tasks of this group vary and involve almost all parts of the community. Then there is the Upstream Contact. An Upstream Contact is the formalised link between upstream and Ubuntu. However, is this for a whole upstream, or like Adopt-an-Upstream mostly centred around one application? What is the relation between the tasks of the Upstream Contact and the Adopt-an-Upstream group, who should do what? The list of tasks on the wiki[3] seems a bit too much for one person to me. I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of the Adopt-an-Upstream group, or a subteam, depending on the size of the group. This because the description of the Upstream Contact[3] does suggest the Contact to take ownership of all bugs and work on them with a group of volunteers. This group of volunteers could be what's now the Adopt-a-Package group[4] and this subteam would also report to the Bug Squad in order to allow us to keep an eye on the bug status of Ubuntu. A separate adoption team could be created for moving bugs without package to the right one. [1] https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt [2] https://wiki.ubuntu.com/BugSquad/AdoptPackage [3] https://wiki.ubuntu.com/Upstream/Contacts [4] https://wiki.ubuntu.com/BugSquad/AdoptionTeam Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From jorge at ubuntu.com Wed Jan 13 17:48:35 2010 From: jorge at ubuntu.com (Jorge O. Castro) Date: Wed, 13 Jan 2010 12:48:35 -0500 Subject: Making it easier for people to work with upstreams In-Reply-To: References: <1263382157.4675.10.camel@miyazaki> Message-ID: On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: > Then there is the Upstream Contact. An Upstream Contact is the formalised > link between upstream and Ubuntu. However, is this for a whole upstream, or > like Adopt-an-Upstream mostly centred around one application? What is the > relation between the tasks of the Upstream Contact and the Adopt-an-Upstream > group, who should do what? The list of tasks on the wiki[3] seems a bit too much > for one person to me. Daniel and I discussed this today during our call. I think this is getting too complicated, so I think we should just grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. Me personally, I don't care too much about what the person's title is or whether the relationship is formal or informal. As long as $potential_volunteer has a place where they can see what kinds of things they can do to work better with upstreams then I'm ok with that. Does anyone have any objection to Daniel and I just merging Upstream/Contacts into Adopt-an-upstream? > I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of > the Adopt-an-Upstream group, or a subteam, depending on the size of the group. > This because the description of the Upstream Contact[3] does suggest the Contact > to take ownership of all bugs and work on them with a group of volunteers. This > group of volunteers could be what's now the Adopt-a-Package group[4] and this > subteam would also report to the Bug Squad in order to allow us to keep an eye > on the bug status of Ubuntu. A separate adoption team could be created for > moving bugs without package to the right one. This is starting to get complicated with teams and subteams, etc. At the end of the day it breaks down to "My name is Jorge and I care about making Banshee better in Ubuntu; I read/write X wiki pages, handle Y bugs, on occasions I try to run a Bug Day, I help filter out junk bugs for upstreams, I help new users on IRC ...." Some people will want to do some or all of those things, some people will just want to do one bit, or whatever, as long as there's a common place on the wiki to help these people link together. I don't think people will care that it's actually adopt-a-package or adopt-an-upstream, I think they'll start someplace and then as they get to know it they might work on the package or in the direct upstream bug tracker or whatever and will figure out what to do. Or am I oversimplifying? Maybe I'm just paranoid because I expect someone to jump in with "Then we'll have a council to oversee ...." :p -- Jorge Castro jorge (at) ubuntu.com External Project Developer Relations Canonical Ltd. From brunogirin at gmail.com Wed Jan 13 19:08:48 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Wed, 13 Jan 2010 19:08:48 +0000 Subject: Making it easier for people to work with upstreams In-Reply-To: References: <1263382157.4675.10.camel@miyazaki> Message-ID: <1263409728.3082.81.camel@nuuk> On Wed, 2010-01-13 at 12:48 -0500, Jorge O. Castro wrote: > On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: > > Then there is the Upstream Contact. An Upstream Contact is the formalised > > link between upstream and Ubuntu. However, is this for a whole upstream, or > > like Adopt-an-Upstream mostly centred around one application? What is the > > relation between the tasks of the Upstream Contact and the Adopt-an-Upstream > > group, who should do what? The list of tasks on the wiki[3] seems a bit too much > > for one person to me. > > Daniel and I discussed this today during our call. > > I think this is getting too complicated, so I think we should just > grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. > Me personally, I don't care too much about what the person's title is > or whether the relationship is formal or informal. As long as > $potential_volunteer has a place where they can see what kinds of > things they can do to work better with upstreams then I'm ok with > that. Good idea. We should keep it simple and flexible otherwise people won't volunteer. At the end of the day, if it works well, we will probably need several upstream people for large upstreams like Gnome, maybe one per application, or maybe even several for a single application like OpenOffice. On the other hand, small utilities can probably be handled by someone who cares about that utility but is also doing a lot of other stuff. > > Does anyone have any objection to Daniel and I just merging > Upstream/Contacts into Adopt-an-upstream? Not me. > > > I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of > > the Adopt-an-Upstream group, or a subteam, depending on the size of the group. > > This because the description of the Upstream Contact[3] does suggest the Contact > > to take ownership of all bugs and work on them with a group of volunteers. This > > group of volunteers could be what's now the Adopt-a-Package group[4] and this > > subteam would also report to the Bug Squad in order to allow us to keep an eye > > on the bug status of Ubuntu. A separate adoption team could be created for > > moving bugs without package to the right one. > > This is starting to get complicated with teams and subteams, etc. At > the end of the day it breaks down to "My name is Jorge and I care > about making Banshee better in Ubuntu; I read/write X wiki pages, > handle Y bugs, on occasions I try to run a Bug Day, I help filter out > junk bugs for upstreams, I help new users on IRC ...." Exactly. An upstream contact should be a way to interact with that upstream for all Ubuntu teams, not just BugSquad so it's better if it's separate. However, there's nothing precluding the same person from adopting an upstream and also adopting the corresponding package in Ubuntu for bug handling. > > Some people will want to do some or all of those things, some people > will just want to do one bit, or whatever, as long as there's a common > place on the wiki to help these people link together. I don't think > people will care that it's actually adopt-a-package or > adopt-an-upstream, I think they'll start someplace and then as they > get to know it they might work on the package or in the direct > upstream bug tracker or whatever and will figure out what to do. > > Or am I oversimplifying? Maybe I'm just paranoid because I expect > someone to jump in with "Then we'll have a council to oversee ...." :p No, the simpler the better. What I think is important to do though is to be clear on the wiki that adopt-an-upstream is not necessarily bug related while adopt-a-package is. So scope definition is key. Bruno From komputes at gmail.com Wed Jan 13 19:30:29 2010 From: komputes at gmail.com (komputes) Date: Wed, 13 Jan 2010 17:30:29 -0200 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263409728.3082.81.camel@nuuk> References: <1263382157.4675.10.camel@miyazaki> <1263409728.3082.81.camel@nuuk> Message-ID: <4B4E1F55.4070502@gmail.com> Bruno Girin wrote: > On Wed, 2010-01-13 at 12:48 -0500, Jorge O. Castro wrote: > >> On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: >> >>> Then there is the Upstream Contact. An Upstream Contact is the formalised >>> link between upstream and Ubuntu. However, is this for a whole upstream, or >>> like Adopt-an-Upstream mostly centred around one application? What is the >>> relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >>> group, who should do what? The list of tasks on the wiki[3] seems a bit too much >>> for one person to me. >>> >> Daniel and I discussed this today during our call. >> >> I think this is getting too complicated, so I think we should just >> grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. >> Me personally, I don't care too much about what the person's title is >> or whether the relationship is formal or informal. As long as >> $potential_volunteer has a place where they can see what kinds of >> things they can do to work better with upstreams then I'm ok with >> that. >> > > Good idea. We should keep it simple and flexible otherwise people won't > volunteer. At the end of the day, if it works well, we will probably > need several upstream people for large upstreams like Gnome, maybe one > per application, or maybe even several for a single application like > OpenOffice. On the other hand, small utilities can probably be handled > by someone who cares about that utility but is also doing a lot of other > stuff. > > >> Does anyone have any objection to Daniel and I just merging >> Upstream/Contacts into Adopt-an-upstream? >> > > Not me. > Um, I don't see a page called 'Adopt-an-upstream'. I think you may mean merging Upstream/Contacts into /Upstream. I like the idea, of /Upstream being the central page for people who say 'How can I help Ubuntu?' so if this is what you mean, yes I support it. As mentioned previously, I feel it needs some serious readability cleaned up, sorting (I suggested by difficulty, but internal/external tasks could be another choice), and links to existing pages which explain the process more thoroughly. I think the page should take less than 2 minutes to read, giving a motivated user a good idea of where they can help. > >>> I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >>> the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >>> This because the description of the Upstream Contact[3] does suggest the Contact >>> to take ownership of all bugs and work on them with a group of volunteers. This >>> group of volunteers could be what's now the Adopt-a-Package group[4] and this >>> subteam would also report to the Bug Squad in order to allow us to keep an eye >>> on the bug status of Ubuntu. A separate adoption team could be created for >>> moving bugs without package to the right one. >>> >> This is starting to get complicated with teams and subteams, etc. At >> the end of the day it breaks down to "My name is Jorge and I care >> about making Banshee better in Ubuntu; I read/write X wiki pages, >> handle Y bugs, on occasions I try to run a Bug Day, I help filter out >> junk bugs for upstreams, I help new users on IRC ...." >> > > Exactly. An upstream contact should be a way to interact with that > upstream for all Ubuntu teams, not just BugSquad so it's better if it's > separate. However, there's nothing precluding the same person from > adopting an upstream and also adopting the corresponding package in > Ubuntu for bug handling. > > > >> Some people will want to do some or all of those things, some people >> will just want to do one bit, or whatever, as long as there's a common >> place on the wiki to help these people link together. I don't think >> people will care that it's actually adopt-a-package or >> adopt-an-upstream, I think they'll start someplace and then as they >> get to know it they might work on the package or in the direct >> upstream bug tracker or whatever and will figure out what to do. >> >> Or am I oversimplifying? Maybe I'm just paranoid because I expect >> someone to jump in with "Then we'll have a council to oversee ...." :p >> > > No, the simpler the better. What I think is important to do though is to > be clear on the wiki that adopt-an-upstream is not necessarily bug > related while adopt-a-package is. So scope definition is key. > > Bruno > > > > I feel that you're right. This initiative covers more than just 'Adopt-a-package', and presents many ways people can help (when and where they want). I'm for making /Upstream the central place where people can learn the many ways they can help. Cheers! -komputes (]( -. .- )[) From dave.crook68 at gmail.com Thu Jan 14 02:21:29 2010 From: dave.crook68 at gmail.com (David Crook) Date: Wed, 13 Jan 2010 21:21:29 -0500 Subject: Ubuntu-bugsquad Digest, Vol 43, Issue 8 In-Reply-To: References: Message-ID: Hi All. Hope everyone is enjoying the new year. i am sorry to go off topic for a second, however, being still unexperienced and very green and honestly the more I read the more I am weary of really screwing something up.... With "standard" everyday bugs I have been forwarded a list of canned responses used for various issues. is there such a thing with nautilus? I would feel better if there were a list of programs I should have loaded on my laptop that could help in reproduce bug issues? I really would like to feel like I am contributing to this project, thus embracing the Ubuntu philosophy. I would very much like to give back to what is by and far the best operating system I have used. So could someone show me a compass and point me in the right direction, I would like to feel comfortable In processing these bugs. Thanks Dave I was also wondering were I could make some suggestions concerning the on-line help/ documentation. Sometime the information is written in a way that is difficult for a new user to understand. For example, I was having video card issues, sought help via on line documentation sated that the xservers should be restarted however the exact terminal command was not listed. The terminal is a daunting thing for ex windows users.. Anyway , sorry for eating up space and time any direction would be helpful D On Wed, Jan 13, 2010 at 12:48 PM, wrote: > Send Ubuntu-bugsquad mailing list submissions to >        ubuntu-bugsquad at lists.ubuntu.com > > To subscribe or unsubscribe via the World Wide Web, visit >        https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > or, via email, send a message with subject or body 'help' to >        ubuntu-bugsquad-request at lists.ubuntu.com > > You can reach the person managing the list at >        ubuntu-bugsquad-owner at lists.ubuntu.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ubuntu-bugsquad digest..." > > > Today's Topics: > >   1. Announcing the Next Ubuntu Hug Day! - Thursday 14 January >      2010 (Kamus) >   2. Re: Making it easier for people to work with upstreams (komputes) >   3. Re: Making it easier for people to work with upstreams (komputes) >   4. Re: Making it easier for people to work with upstreams >      (Daniel Holbach) >   5. Re: Making it easier for people to work with upstreams >      (Bruno Girin) >   6. Re: Making it easier for people to work with upstreams >      (Sense Hofstede) >   7. Re: Making it easier for people to work with upstreams >      (Jorge O. Castro) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Jan 2010 09:42:51 -0300 > From: Kamus > Subject: Announcing the Next Ubuntu Hug Day! - Thursday 14 January >        2010 > To: ubuntu-bugsquad at lists.ubuntu.com, >        ubuntu-devel-announce at lists.ubuntu.com, >        ubuntu-bugcontrol at lists.launchpad.net > Message-ID: >         > Content-Type: text/plain; charset=ISO-8859-1 > > Fellow Ubuntu Triagers! > > This week's Bug Day target is *drum roll please* gnome-power-manager! > > * 100 New bugs need a hug > > * 100 Incompletes bugs > > * 65 Confirmed bugs need a review > > * 12 Bugs needs to be forwarded > > > Bookmark it, add it to your calendars, turn over those egg-timers! >  ?* Thursday 14 January 2010 >  ?* https://wiki.ubuntu.com/UbuntuBugDay/20100114 > > > Are you looking for a way to start giving some love back to your > adorable Ubuntu Project? Did you ever wonder what Triage is? Want to > learn about that? > This is a perfect time!, Everybody can help in a Bug Day! > > Open your IRC Client and go to #ubuntu-bugs (FreeNode) the BugSquad > will be happy to help you to start contributing! > > Wanna be famous? Is easy! remember to use 5-A-day so if you do a good > work your name could be listed at the top 5-A-Day Contributors in the > Ubuntu Hall of Fame page! > > We are always looking for new tasks or ideas for the Bug Days, if you have one > add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning > > > If you're new to all this (like me!) and you want to know > more about ubuntu?, head to http://wiki.ubuntu.com/Bugs > > Have a nice day, >  ? Kamus >  [From the BugSquad] > > > > -- > Victor Vargas B. > Latitud:  -33.439177,-70.625267 > Santiago, Chile. > > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Jan 2010 10:56:41 -0200 > From: komputes > Subject: Re: Making it easier for people to work with upstreams > To: Daniel Holbach ,         Ubuntu Bugsquad >         > Message-ID: <4B4DC309.3060705 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Daniel Holbach wrote: >>  - what is confusing in our processes today >> > I don't find that the current process is very confusing. Some of the > 'Upstream' documentation for this initiative is scattered, lacks > content, and duplicates efforts that were already made by the BugSquad. > > The process to help is basically: > 1) Person interested in helping with bugs joins BugSquad > 2) Person interested in a particular application/package they sign up to > adopt the package on https://wiki.ubuntu.com/BugSquad/AdoptPackage > 3) Person takes on certain tasks they feel comfortable with to help out > >>  - what we need to clarify in terms of documentation >> > Generalized documentation is best. Duplicate documentation is not > helpful. I don't feel that *every* package should have it's own > restrictive 'special process' for working with the upstream, as this > will be a lot of work and create unnecessary pollution. For some > packages/projects that need personalized documentation on how to work > with an upstream, "Workspaces" can be used (although something like that > already exists, see below). I think setting general guidelines should do > the job for most cases. > > Let the adopters develop relationships with upstream developers and > understand how things are done upstream through experience. As long as > upstream contact is done respectfully, I don't foresee issues. > > That said, I have a few recommendations for the wiki category you guys > are building. > > 1) I do feel that https://wiki.ubuntu.com/Upstream/Contacts need to be > easier to read. > > 2) https://wiki.ubuntu.com/DanielHolbach/Upstream > should be merged with > https://wiki.ubuntu.com/Upstream > > 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt > Should be merged with (and a link should take its place) > https://wiki.ubuntu.com/BugSquad/AdoptPackage > > 4) I don't find this page useful at all: > https://wiki.ubuntu.com/Upstream/Contributions > > 5) I would put this in a workspace for Debian: > https://wiki.ubuntu.com/Upstream/Contributions/Debian > > 6) Translations should be one thing in a list of what people can do to > help listed here: > https://wiki.ubuntu.com/Upstream/Contacts > > 7) The 'Contribution' section at the top of the page can then be removed. > > 8) I think duplicate work is being done here: > https://wiki.ubuntu.com/Bugs/Upstream > > 9) As well the bottom of /Bugs/Upstream can be merged with > /Upstream/Workspaces > > I think this covers the whole over-documentation/duplication issue I see > with this initiative. The initiative becomes more of a central page then > for people who are all like 'How can I help with Ubuntu?' > > >>  - how interested people find out about the possibilities >> > This would be the page built by this initiative. This will present > possibilities to assist with a package, I would say we create a general > checklist of things you can do to help. This was mentioned in my > previous email and was based on /Upstream/Contacts > >>  - how we learn from each other and form best practices >> > Communication: IRC, Mailing Lists. Users should not feel shy to ask for > help if they want to learn. > > One improvement I would request is for users themselves to be able to > modify the 'Most active in' section of their Launchpad profile. That way > they become contacts for that application/package. For example, I have > adopted and been working a lot on usb-creator bugs, but I don't see it > in the 'Most active in' section of  https://launchpad.net/~komputes > > Afterwards, being able to find who is active in a project through LP, > could be a big step forward. > > >> We want to revisit how people who are passionate about a certain piece >> of software can be most useful, both to Ubuntu and upstream. >> > I think that setting guidelines for the following tasks on the wiki (in > an easy, concise and easy to read way) could help passionate people be > helpful to a specific project and its upstream: > > -bug ownership > -stale bug checking > -testing > -version tracking (Compare our version to upstream) > -patch notifying (Upstream) > -synchronization requesting (From Upstream) > -upstream updating (This is what we do which is related to your project) > -schedule notifying (This is when we release, will a new version be out > by then? What bugs will it fix) > -IRC presence (Hang out in the freenode channel for that project, > connect to another server if that is where upstream discussion takes place) > -mailing list presence > -patch review > -going to upstream sprints > -fixing (going through top confirmed/triaged bugs and > working/coordinating to release fixes) > -translations > > I would review https://wiki.ubuntu.com/Upstream/Contacts, order them in > simple/medium/hard (depending on user proficiency), shorten the > sentences/explanations and link to existing pages which explain the > process more thoroughly. > > Cheers, > > -komputes > >  (]( -. .- )[) > > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Jan 2010 11:06:33 -0200 > From: komputes > Subject: Re: Making it easier for people to work with upstreams > To: Daniel Holbach ,         Ubuntu Bugsquad >         > Message-ID: <4B4DC559.20504 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I almost forgot to add to that list... > > -creating documentation > -reviewing stale documentation/wiki > -creating a PPA with the latest stable upstream version > -creating a PPA with the latest experimental upstream version > > Cheers, > > -komputes > >  (]( -. .- )[) > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Jan 2010 14:44:28 +0100 > From: Daniel Holbach > Subject: Re: Making it easier for people to work with upstreams > To: Ubuntu Bugsquad > Message-ID: <4B4DCE3C.9020508 at ubuntu.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 13.01.2010 13:56, komputes wrote: >> 2) https://wiki.ubuntu.com/DanielHolbach/Upstream >> should be merged with >> https://wiki.ubuntu.com/Upstream > > This is a _proposal_ I'm working on right now. > > >> 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >> Should be merged with (and a link should take its place) >> https://wiki.ubuntu.com/BugSquad/AdoptPackage > > I'm not sure about that. The page I started writing there was supposed > to give people an overview over ALL the different parts of the community > that are an interface between Ubuntu and an Upstream project. It's not > meant to replace and BugSquad documentation and it's not supposed to > replace a PPA guide or anything that's in UbuntuDevelopment. > > The idea is to give people who are passionate about some kind of > software the necessary overview to afterwards know > >  - where to start in terms of bugs >  - how to be a bridge between Ubuntu and upstream >  - how to set up a PPA if they need one >  - how to get changes uploaded >  - how to get upload rights later on >  - where debugging pages live on the wiki >  - best-practices of user testing >  - etc. > > Please note how this spans across multiple parts of the community. This > is not intending to overwrite any other initiative of any other part of > community. > > As far as I'm concerned a good overview over what people can do, some > cheat-sheets, some clarification, a nice outreach campaign and a way for > people share their best-practices would get us a lot more contributors > that are 1) passionate and effective about the collaboration with the > upstream they care about and 2) a great contributors to the BugSquad, > the MOTU team, the testing team, etc. > > Have a great day, >  Daniel > > > > ------------------------------ > > Message: 5 > Date: Wed, 13 Jan 2010 14:43:56 +0000 > From: Bruno Girin > Subject: Re: Making it easier for people to work with upstreams > To: ubuntu-bugsquad at lists.ubuntu.com > Message-ID: <1263393836.3082.50.camel at nuuk> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2010-01-13 at 14:44 +0100, Daniel Holbach wrote: >> On 13.01.2010 13:56, komputes wrote: >> > 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >> > Should be merged with (and a link should take its place) >> > https://wiki.ubuntu.com/BugSquad/AdoptPackage >> >> I'm not sure about that. The page I started writing there was supposed >> to give people an overview over ALL the different parts of the community >> that are an interface between Ubuntu and an Upstream project. It's not >> meant to replace and BugSquad documentation and it's not supposed to >> replace a PPA guide or anything that's in UbuntuDevelopment. > > I agree. The scope of adopt-an-upstream is not the same as > adopt-a-package. However, both intersect and should work together. > > For example, Sense started the Adopt Nautilus group. One thing we've > identified is that Nautilus has a lot of bugs in the Triaged state that > have been reported upstream but that don't seem to have been handled. An > upstream adopter could help us with: >      * moving forward bugs in the upstream tracker >      * feeding back to us the quality of the bug reports (e.g. is there >        a piece of information that we should provide on all bug reports >        to facilitate handling upstream but that we never provide?); >        this could also lead to developing an apport-plugin for that >        package to ensure that the missing info becomes included by >        default >      * advising us about upcoming functionality that is likely to close >        bugs so that we don't spend too much time on issues that have >        already been identified and are in the process of being closed > > >> >> The idea is to give people who are passionate about some kind of >> software the necessary overview to afterwards know >> >>  - where to start in terms of bugs >>  - how to be a bridge between Ubuntu and upstream >>  - how to set up a PPA if they need one >>  - how to get changes uploaded >>  - how to get upload rights later on >>  - where debugging pages live on the wiki >>  - best-practices of user testing >>  - etc. > > I would add to this: >      * give us advance warning when some functionality is going to be >        deprecated, change dramatically, or will require a newer version >        to keep working; e.g. the anki package in Karmic is an older >        version that cannot connect to the Anki servers anymore because >        they changed the way client-server interaction worked: knowing >        this in advance would enable us to upgrade the relevant package >        before it becomes an issue for users >      * help us test and validate their packages on the upcoming version >        of Ubuntu; e.g. the OpenERP version in the Ubuntu repositories >        only works well with Python 2.5, not 2.6. However, since Karmic >        (or Jaunty can't remember) the default version of Python is 2.6 >        => OpenERP doesn't work out of the box; this is now solved in >        the OpenERP trunk but it means that for it to work on Lucid out >        of the box we will need to ensure the latest version is used >      * advise us whether they think we should add other related >        packages to offer Ubuntu users the best functionality that the >        upstream can offer; e.g. Karmic has packages for OpenERP server >        and desktop client but not the web client => adding the web >        client would make OpenERP more versatile for Ubuntu users > > >> >> Please note how this spans across multiple parts of the community. This >> is not intending to overwrite any other initiative of any other part of >> community. >> >> As far as I'm concerned a good overview over what people can do, some >> cheat-sheets, some clarification, a nice outreach campaign and a way for >> people share their best-practices would get us a lot more contributors >> that are 1) passionate and effective about the collaboration with the >> upstream they care about and 2) a great contributors to the BugSquad, >> the MOTU team, the testing team, etc. > > Agreed. The scope for upstream contacts is orthogonal to the scope of > the different teams in the Ubuntu community and people who adopt an > upstream may have different interests: ensuring bugs are resolved, > talking to devs and MOTU about upcoming features, talking to the art > team on visual integration, or to the LoCo teams to do stuff in their > community, etc. > > >> >> Have a great day, > > Unlikely at the moment as I've got to write a spec for a customer but it > will definitely get a lot better once I reach the pub (snow permitting). > Have a great day too! > > Bruno > > > > > > ------------------------------ > > Message: 6 > Date: Wed, 13 Jan 2010 17:49:29 +0100 > From: Sense Hofstede > Subject: Re: Making it easier for people to work with upstreams > To: Daniel Holbach > Cc: ubuntu-bugsquad at lists.ubuntu.com > Message-ID: >         > Content-Type: text/plain; charset=UTF-8 > > Hello, > > Op maandag 13-1-2010 schreef Daniel Holbach : >> When we started thinking of "Adopt an Upstream" it was the name of an >> initiative. It's not meant to replace anything. >> >> The discussion: >> >>  - what is confusing in our processes today >>  - what we need to clarify in terms of documentation >>  - how interested people find out about the possibilities >>  - how we learn from each other and form best practices >> >> to me is much more important than the name of the group people who are >> part of the initiative or the name of the initiative itself. >> >> We want to revisit how people who are passionate about a certain piece >> of software can be most useful, both to Ubuntu and upstream. This was >> never meant to replace anything or shut-down any other initiative. > > Good. It's not that I got the impression that the goal of the project > was to crush > all other related projects and I'm also not interested in a discussion about the > names right now. I just wanted to make sure that no efforts would be duplicated > and that there wouldn't be worked on two different projects with > overlapping goals > -- which Bruno already outlined very well. > > I would suggest to add information to your useful Upstream/Adopt page[1] about > the adoption project of the Bug Squad[2]. > >> What I do think we should make clear though is that there is no "big >> maintainer lock" and there's nobody who handles one project exclusively >> and that we want to collaborate as good as we can. >> > > This is something I wasn't afraid of, and something I also try to emphasize > when writing wiki pages for Adopt-a-Package. I think it would indeed be wise > to make this clear for Adopt-an-Upstream as well, like you said, in order to > not scare casual contributors and novices away. > > Komputes has some good points and I agree with them. > > Lets see if I understand the project well enough already. There is > Adopt-an-Upstream, which is a group of people focussed on a particular part of > an upstream project, mostly centred around a certain application. The tasks of > this group vary and involve almost all parts of the community. > > Then there is the Upstream Contact. An Upstream Contact is the formalised > link between upstream and Ubuntu. However, is this for a whole upstream, or > like Adopt-an-Upstream mostly centred around one application? What is the > relation between the tasks of the Upstream Contact and the Adopt-an-Upstream > group, who should do what? The list of tasks on the wiki[3] seems a bit too much > for one person to me. > > I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of > the Adopt-an-Upstream group, or a subteam, depending on the size of the group. > This because the description of the Upstream Contact[3] does suggest the Contact > to take ownership of all bugs and work on them with a group of volunteers. This > group of volunteers could be what's now the Adopt-a-Package group[4] and this > subteam would also report to the Bug Squad in order to allow us to keep an eye > on the bug status of Ubuntu. A separate adoption team could be created for > moving bugs without package to the right one. > > [1] https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt > [2] https://wiki.ubuntu.com/BugSquad/AdoptPackage > [3] https://wiki.ubuntu.com/Upstream/Contacts > [4] https://wiki.ubuntu.com/BugSquad/AdoptionTeam > > Regards, > -- > Sense Hofstede > [?s?n.s? ???f.ste?d?] > > > > ------------------------------ > > Message: 7 > Date: Wed, 13 Jan 2010 12:48:35 -0500 > From: "Jorge O. Castro" > Subject: Re: Making it easier for people to work with upstreams > To: Sense Hofstede > Cc: ubuntu-bugsquad > Message-ID: >         > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: >> Then there is the Upstream Contact. An Upstream Contact is the formalised >> link between upstream and Ubuntu. However, is this for a whole upstream, or >> like Adopt-an-Upstream mostly centred around one application? What is the >> relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >> group, who should do what? The list of tasks on the wiki[3] seems a bit too much >> for one person to me. > > Daniel and I discussed this today during our call. > > I think this is getting too complicated, so I think we should just > grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. > Me personally, I don't care too much about what the person's title is > or whether the relationship is formal or informal. As long as > $potential_volunteer has a place where they can see what kinds of > things they can do to work better with upstreams then I'm ok with > that. > > Does anyone have any objection to Daniel and I just merging > Upstream/Contacts into Adopt-an-upstream? > >> I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >> the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >> This because the description of the Upstream Contact[3] does suggest the Contact >> to take ownership of all bugs and work on them with a group of volunteers. This >> group of volunteers could be what's now the Adopt-a-Package group[4] and this >> subteam would also report to the Bug Squad in order to allow us to keep an eye >> on the bug status of Ubuntu. A separate adoption team could be created for >> moving bugs without package to the right one. > > This is starting to get complicated with teams and subteams, etc. At > the end of the day it breaks down to "My name is Jorge and I care > about making Banshee better in Ubuntu; I read/write X wiki pages, > handle Y bugs, on occasions I try to run a Bug Day, I help filter out > junk bugs for upstreams, I help new users on IRC ...." > > Some people will want to do some or all of those things, some people > will just want to do one bit, or whatever, as long as there's a common > place on the wiki to help these people link together. I don't think > people will care that it's actually adopt-a-package or > adopt-an-upstream, I think they'll start someplace and then as they > get to know it they might work on the package or in the direct > upstream bug tracker or whatever and will figure out what to do. > > Or am I oversimplifying? Maybe I'm just paranoid because I expect > someone to jump in with "Then we'll have a council to oversee ...." :p > > -- > Jorge Castro > jorge (at) ubuntu.com > External Project Developer Relations > Canonical Ltd. > > > > ------------------------------ > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > End of Ubuntu-bugsquad Digest, Vol 43, Issue 8 > ********************************************** > From mrooney at gmail.com Thu Jan 14 02:26:13 2010 From: mrooney at gmail.com (Mike Rooney) Date: Wed, 13 Jan 2010 18:26:13 -0800 Subject: Ubuntu-bugsquad Digest, Vol 43, Issue 8 In-Reply-To: References: Message-ID: <4f4806ee1001131826p4c5a9b04gff373a7616794e29@mail.gmail.com> On Wed, Jan 13, 2010 at 6:21 PM, David Crook wrote: > I was also wondering  were I could make some suggestions concerning > the on-line help/ documentation. Sometime the information is written > in a way that is difficult for a new user to understand.  For example, >  I was having video card issues, sought help via on line documentation > sated that the xservers should be restarted however the exact terminal > command was not listed. The terminal is a daunting thing for  ex > windows users..  Anyway , sorry for eating up space and time any > direction would be helpful Regarding the documentation issues, those are great bugs to file yourself! I'm not sure what the correct package would be, it varies where you find it, but I suspect there is a package or project on LP (ubuntu-website?) where you can file documentation bugs/improvements. -- Michael Rooney mrooney at ubuntu.com Sent from San Mateo, CA, United States From cyan.spam at gmail.com Thu Jan 14 02:52:03 2010 From: cyan.spam at gmail.com (David Tombs) Date: Wed, 13 Jan 2010 21:52:03 -0500 Subject: Ubuntu-bugsquad Digest, Vol 43, Issue 8 In-Reply-To: References: Message-ID: <4B4E86D3.2090404@gmail.com> Hi Dave, > i am sorry to go off topic for a second, however, being still > unexperienced and very green and honestly the more I read the more I > am weary of really screwing something up.... With "standard" > everyday bugs I have been forwarded a list of canned responses used > for various issues. is there such a thing with nautilus? I would feel > better if there were a list of programs I should have loaded on my > laptop that could help in reproduce bug issues? I really would like > to feel like I am contributing to this project, thus embracing the > Ubuntu philosophy. I would very much like to give back to what is by > and far the best operating system I have used. So could someone show > me a compass and point me in the right direction, I would like to feel > comfortable In processing these bugs. > Glad you want to contribute! I only recently started bug work myself. You've probably already seen , which has some good information. The FindRightPackage and HowToTriage pages are especially helpful to read. Definitely ask any questions you have on #ubuntu-bugs IRC channel or this mailing list. Probably your best opportunity is actually coming up tomorrow, with the hug day (). I know it sounds strange, but there doesn't actually have to be any hugging involved. ;) It /will/ involve triaging bugs, though, and it's a good chance to join the IRC channel when there will be more people than average paying attention. Hope all of that helps. Regards, David From dave.crook68 at gmail.com Thu Jan 14 03:30:29 2010 From: dave.crook68 at gmail.com (David Crook) Date: Wed, 13 Jan 2010 22:30:29 -0500 Subject: Ubuntu-bugsquad Digest, Vol 43, Issue 9 In-Reply-To: References: Message-ID: The merging of the two projects is sound Dave On Wed, Jan 13, 2010 at 9:21 PM, wrote: > Send Ubuntu-bugsquad mailing list submissions to >        ubuntu-bugsquad at lists.ubuntu.com > > To subscribe or unsubscribe via the World Wide Web, visit >        https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > or, via email, send a message with subject or body 'help' to >        ubuntu-bugsquad-request at lists.ubuntu.com > > You can reach the person managing the list at >        ubuntu-bugsquad-owner at lists.ubuntu.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ubuntu-bugsquad digest..." > > > Today's Topics: > >   1. Re: Making it easier for people to work with upstreams >      (Bruno Girin) >   2. Re: Making it easier for people to work with upstreams (komputes) >   3. Re: Ubuntu-bugsquad Digest, Vol 43, Issue 8 (David Crook) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Jan 2010 19:08:48 +0000 > From: Bruno Girin > Subject: Re: Making it easier for people to work with upstreams > To: ubuntu-bugsquad at lists.ubuntu.com > Message-ID: <1263409728.3082.81.camel at nuuk> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2010-01-13 at 12:48 -0500, Jorge O. Castro wrote: >> On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: >> > Then there is the Upstream Contact. An Upstream Contact is the formalised >> > link between upstream and Ubuntu. However, is this for a whole upstream, or >> > like Adopt-an-Upstream mostly centred around one application? What is the >> > relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >> > group, who should do what? The list of tasks on the wiki[3] seems a bit too much >> > for one person to me. >> >> Daniel and I discussed this today during our call. >> >> I think this is getting too complicated, so I think we should just >> grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. >> Me personally, I don't care too much about what the person's title is >> or whether the relationship is formal or informal. As long as >> $potential_volunteer has a place where they can see what kinds of >> things they can do to work better with upstreams then I'm ok with >> that. > > Good idea. We should keep it simple and flexible otherwise people won't > volunteer. At the end of the day, if it works well, we will probably > need several upstream people for large upstreams like Gnome, maybe one > per application, or maybe even several for a single application like > OpenOffice. On the other hand, small utilities can probably be handled > by someone who cares about that utility but is also doing a lot of other > stuff. > >> >> Does anyone have any objection to Daniel and I just merging >> Upstream/Contacts into Adopt-an-upstream? > > Not me. > >> >> > I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >> > the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >> > This because the description of the Upstream Contact[3] does suggest the Contact >> > to take ownership of all bugs and work on them with a group of volunteers. This >> > group of volunteers could be what's now the Adopt-a-Package group[4] and this >> > subteam would also report to the Bug Squad in order to allow us to keep an eye >> > on the bug status of Ubuntu. A separate adoption team could be created for >> > moving bugs without package to the right one. >> >> This is starting to get complicated with teams and subteams, etc. At >> the end of the day it breaks down to "My name is Jorge and I care >> about making Banshee better in Ubuntu; I read/write X wiki pages, >> handle Y bugs, on occasions I try to run a Bug Day, I help filter out >> junk bugs for upstreams, I help new users on IRC ...." > > Exactly. An upstream contact should be a way to interact with that > upstream for all Ubuntu teams, not just BugSquad so it's better if it's > separate. However, there's nothing precluding the same person from > adopting an upstream and also adopting the corresponding package in > Ubuntu for bug handling. > > >> >> Some people will want to do some or all of those things, some people >> will just want to do one bit, or whatever, as long as there's a common >> place on the wiki to help these people link together. I don't think >> people will care that it's actually adopt-a-package or >> adopt-an-upstream, I think they'll start someplace and then as they >> get to know it they might work on the package or in the direct >> upstream bug tracker or whatever and will figure out what to do. >> >> Or am I oversimplifying? Maybe I'm just paranoid because I expect >> someone to jump in with "Then we'll have a council to oversee ...." :p > > No, the simpler the better. What I think is important to do though is to > be clear on the wiki that adopt-an-upstream is not necessarily bug > related while adopt-a-package is. So scope definition is key. > > Bruno > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Jan 2010 17:30:29 -0200 > From: komputes > Subject: Re: Making it easier for people to work with upstreams > Cc: ubuntu-bugsquad at lists.ubuntu.com > Message-ID: <4B4E1F55.4070502 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Bruno Girin wrote: >> On Wed, 2010-01-13 at 12:48 -0500, Jorge O. Castro wrote: >> >>> On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: >>> >>>> Then there is the Upstream Contact. An Upstream Contact is the formalised >>>> link between upstream and Ubuntu. However, is this for a whole upstream, or >>>> like Adopt-an-Upstream mostly centred around one application? What is the >>>> relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >>>> group, who should do what? The list of tasks on the wiki[3] seems a bit too much >>>> for one person to me. >>>> >>> Daniel and I discussed this today during our call. >>> >>> I think this is getting too complicated, so I think we should just >>> grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. >>> Me personally, I don't care too much about what the person's title is >>> or whether the relationship is formal or informal. As long as >>> $potential_volunteer has a place where they can see what kinds of >>> things they can do to work better with upstreams then I'm ok with >>> that. >>> >> >> Good idea. We should keep it simple and flexible otherwise people won't >> volunteer. At the end of the day, if it works well, we will probably >> need several upstream people for large upstreams like Gnome, maybe one >> per application, or maybe even several for a single application like >> OpenOffice. On the other hand, small utilities can probably be handled >> by someone who cares about that utility but is also doing a lot of other >> stuff. >> >> >>> Does anyone have any objection to Daniel and I just merging >>> Upstream/Contacts into Adopt-an-upstream? >>> >> >> Not me. >> > Um, I don't see a page called 'Adopt-an-upstream'. I think you may mean > merging Upstream/Contacts into /Upstream. > > I like the idea, of /Upstream being the central page for people who say > 'How can I help Ubuntu?' so if this is what you mean, yes I support it. > > As mentioned previously, I feel it needs some serious readability > cleaned up, sorting (I suggested by difficulty, but internal/external > tasks could be another choice), and links to existing pages which > explain the process more thoroughly. I think the page should take less > than 2 minutes to read, giving a motivated user a good idea of where > they can help. > >> >>>> I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >>>> the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >>>> This because the description of the Upstream Contact[3] does suggest the Contact >>>> to take ownership of all bugs and work on them with a group of volunteers. This >>>> group of volunteers could be what's now the Adopt-a-Package group[4] and this >>>> subteam would also report to the Bug Squad in order to allow us to keep an eye >>>> on the bug status of Ubuntu. A separate adoption team could be created for >>>> moving bugs without package to the right one. >>>> >>> This is starting to get complicated with teams and subteams, etc. At >>> the end of the day it breaks down to "My name is Jorge and I care >>> about making Banshee better in Ubuntu; I read/write X wiki pages, >>> handle Y bugs, on occasions I try to run a Bug Day, I help filter out >>> junk bugs for upstreams, I help new users on IRC ...." >>> >> >> Exactly. An upstream contact should be a way to interact with that >> upstream for all Ubuntu teams, not just BugSquad so it's better if it's >> separate. However, there's nothing precluding the same person from >> adopting an upstream and also adopting the corresponding package in >> Ubuntu for bug handling. >> >> >> >>> Some people will want to do some or all of those things, some people >>> will just want to do one bit, or whatever, as long as there's a common >>> place on the wiki to help these people link together. I don't think >>> people will care that it's actually adopt-a-package or >>> adopt-an-upstream, I think they'll start someplace and then as they >>> get to know it they might work on the package or in the direct >>> upstream bug tracker or whatever and will figure out what to do. >>> >>> Or am I oversimplifying? Maybe I'm just paranoid because I expect >>> someone to jump in with "Then we'll have a council to oversee ...." :p >>> >> >> No, the simpler the better. What I think is important to do though is to >> be clear on the wiki that adopt-an-upstream is not necessarily bug >> related while adopt-a-package is. So scope definition is key. >> >> Bruno >> >> >> >> > > I feel that you're right. This initiative covers more than just > 'Adopt-a-package', and presents many ways people can help (when and > where they want). I'm for making /Upstream the central place where > people can learn the many ways they can help. > > Cheers! > > -komputes > >  (]( -. .- )[) > > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Jan 2010 21:21:29 -0500 > From: David Crook > Subject: Re: Ubuntu-bugsquad Digest, Vol 43, Issue 8 > To: ubuntu-bugsquad at lists.ubuntu.com > Message-ID: >         > Content-Type: text/plain; charset=ISO-8859-1 > > Hi All. Hope everyone is enjoying the new year. > > > i am sorry to go off topic for a second, however, being still > unexperienced and very green and honestly the more I read the more I > am weary of  really screwing something up....  With "standard" > everyday bugs I have been forwarded a list of canned responses used > for various issues. is there such a thing with nautilus?  I would feel > better if there were a list of programs I should have loaded on my > laptop that could help in reproduce bug issues?  I really would like > to  feel like I am contributing to this project, thus embracing the > Ubuntu philosophy. I would very much like to give back to what is by > and far the best operating system I have used. So could someone show > me a compass and point me in the right direction, I would like to feel > comfortable  In processing these bugs. > > Thanks > > Dave > > I was also wondering  were I could make some suggestions concerning > the on-line help/ documentation. Sometime the information is written > in a way that is difficult for a new user to understand.  For example, >  I was having video card issues, sought help via on line documentation > sated that the xservers should be restarted however the exact terminal > command was not listed. The terminal is a daunting thing for  ex > windows users..  Anyway , sorry for eating up space and time any > direction would be helpful > > D > > On Wed, Jan 13, 2010 at 12:48 PM, > wrote: >> Send Ubuntu-bugsquad mailing list submissions to >> ? ? ? ?ubuntu-bugsquad at lists.ubuntu.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> ? ? ? ?https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> or, via email, send a message with subject or body 'help' to >> ? ? ? ?ubuntu-bugsquad-request at lists.ubuntu.com >> >> You can reach the person managing the list at >> ? ? ? ?ubuntu-bugsquad-owner at lists.ubuntu.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Ubuntu-bugsquad digest..." >> >> >> Today's Topics: >> >> ? 1. Announcing the Next Ubuntu Hug Day! - Thursday 14 January >> ? ? ?2010 (Kamus) >> ? 2. Re: Making it easier for people to work with upstreams (komputes) >> ? 3. Re: Making it easier for people to work with upstreams (komputes) >> ? 4. Re: Making it easier for people to work with upstreams >> ? ? ?(Daniel Holbach) >> ? 5. Re: Making it easier for people to work with upstreams >> ? ? ?(Bruno Girin) >> ? 6. Re: Making it easier for people to work with upstreams >> ? ? ?(Sense Hofstede) >> ? 7. Re: Making it easier for people to work with upstreams >> ? ? ?(Jorge O. Castro) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 13 Jan 2010 09:42:51 -0300 >> From: Kamus >> Subject: Announcing the Next Ubuntu Hug Day! - Thursday 14 January >> ? ? ? ?2010 >> To: ubuntu-bugsquad at lists.ubuntu.com, >> ? ? ? ?ubuntu-devel-announce at lists.ubuntu.com, >> ? ? ? ?ubuntu-bugcontrol at lists.launchpad.net >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Fellow Ubuntu Triagers! >> >> This week's Bug Day target is *drum roll please* gnome-power-manager! >> >> * 100 New bugs need a hug >> >> * 100 Incompletes bugs >> >> * 65 Confirmed bugs need a review >> >> * 12 Bugs needs to be forwarded >> >> >> Bookmark it, add it to your calendars, turn over those egg-timers! >> ??* Thursday 14 January 2010 >> ??* https://wiki.ubuntu.com/UbuntuBugDay/20100114 >> >> >> Are you looking for a way to start giving some love back to your >> adorable Ubuntu Project? Did you ever wonder what Triage is? Want to >> learn about that? >> This is a perfect time!, Everybody can help in a Bug Day! >> >> Open your IRC Client and go to #ubuntu-bugs (FreeNode) the BugSquad >> will be happy to help you to start contributing! >> >> Wanna be famous? Is easy! remember to use 5-A-day so if you do a good >> work your name could be listed at the top 5-A-Day Contributors in the >> Ubuntu Hall of Fame page! >> >> We are always looking for new tasks or ideas for the Bug Days, if you have one >> add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning >> >> >> If you're new to all this (like me!) and you want to know >> more about ubuntu?, head to http://wiki.ubuntu.com/Bugs >> >> Have a nice day, >> ?? Kamus >> ?[From the BugSquad] >> >> >> >> -- >> Victor Vargas B. >> Latitud: ?-33.439177,-70.625267 >> Santiago, Chile. >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 13 Jan 2010 10:56:41 -0200 >> From: komputes >> Subject: Re: Making it easier for people to work with upstreams >> To: Daniel Holbach , ? ? ? ? Ubuntu Bugsquad >> ? ? ? ? >> Message-ID: <4B4DC309.3060705 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Daniel Holbach wrote: >>> ?- what is confusing in our processes today >>> >> I don't find that the current process is very confusing. Some of the >> 'Upstream' documentation for this initiative is scattered, lacks >> content, and duplicates efforts that were already made by the BugSquad. >> >> The process to help is basically: >> 1) Person interested in helping with bugs joins BugSquad >> 2) Person interested in a particular application/package they sign up to >> adopt the package on https://wiki.ubuntu.com/BugSquad/AdoptPackage >> 3) Person takes on certain tasks they feel comfortable with to help out >> >>> ?- what we need to clarify in terms of documentation >>> >> Generalized documentation is best. Duplicate documentation is not >> helpful. I don't feel that *every* package should have it's own >> restrictive 'special process' for working with the upstream, as this >> will be a lot of work and create unnecessary pollution. For some >> packages/projects that need personalized documentation on how to work >> with an upstream, "Workspaces" can be used (although something like that >> already exists, see below). I think setting general guidelines should do >> the job for most cases. >> >> Let the adopters develop relationships with upstream developers and >> understand how things are done upstream through experience. As long as >> upstream contact is done respectfully, I don't foresee issues. >> >> That said, I have a few recommendations for the wiki category you guys >> are building. >> >> 1) I do feel that https://wiki.ubuntu.com/Upstream/Contacts need to be >> easier to read. >> >> 2) https://wiki.ubuntu.com/DanielHolbach/Upstream >> should be merged with >> https://wiki.ubuntu.com/Upstream >> >> 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >> Should be merged with (and a link should take its place) >> https://wiki.ubuntu.com/BugSquad/AdoptPackage >> >> 4) I don't find this page useful at all: >> https://wiki.ubuntu.com/Upstream/Contributions >> >> 5) I would put this in a workspace for Debian: >> https://wiki.ubuntu.com/Upstream/Contributions/Debian >> >> 6) Translations should be one thing in a list of what people can do to >> help listed here: >> https://wiki.ubuntu.com/Upstream/Contacts >> >> 7) The 'Contribution' section at the top of the page can then be removed. >> >> 8) I think duplicate work is being done here: >> https://wiki.ubuntu.com/Bugs/Upstream >> >> 9) As well the bottom of /Bugs/Upstream can be merged with >> /Upstream/Workspaces >> >> I think this covers the whole over-documentation/duplication issue I see >> with this initiative. The initiative becomes more of a central page then >> for people who are all like 'How can I help with Ubuntu?' >> >> >>> ?- how interested people find out about the possibilities >>> >> This would be the page built by this initiative. This will present >> possibilities to assist with a package, I would say we create a general >> checklist of things you can do to help. This was mentioned in my >> previous email and was based on /Upstream/Contacts >> >>> ?- how we learn from each other and form best practices >>> >> Communication: IRC, Mailing Lists. Users should not feel shy to ask for >> help if they want to learn. >> >> One improvement I would request is for users themselves to be able to >> modify the 'Most active in' section of their Launchpad profile. That way >> they become contacts for that application/package. For example, I have >> adopted and been working a lot on usb-creator bugs, but I don't see it >> in the 'Most active in' section of ?https://launchpad.net/~komputes >> >> Afterwards, being able to find who is active in a project through LP, >> could be a big step forward. >> >> >>> We want to revisit how people who are passionate about a certain piece >>> of software can be most useful, both to Ubuntu and upstream. >>> >> I think that setting guidelines for the following tasks on the wiki (in >> an easy, concise and easy to read way) could help passionate people be >> helpful to a specific project and its upstream: >> >> -bug ownership >> -stale bug checking >> -testing >> -version tracking (Compare our version to upstream) >> -patch notifying (Upstream) >> -synchronization requesting (From Upstream) >> -upstream updating (This is what we do which is related to your project) >> -schedule notifying (This is when we release, will a new version be out >> by then? What bugs will it fix) >> -IRC presence (Hang out in the freenode channel for that project, >> connect to another server if that is where upstream discussion takes place) >> -mailing list presence >> -patch review >> -going to upstream sprints >> -fixing (going through top confirmed/triaged bugs and >> working/coordinating to release fixes) >> -translations >> >> I would review https://wiki.ubuntu.com/Upstream/Contacts, order them in >> simple/medium/hard (depending on user proficiency), shorten the >> sentences/explanations and link to existing pages which explain the >> process more thoroughly. >> >> Cheers, >> >> -komputes >> >> ?(]( -. .- )[) >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 13 Jan 2010 11:06:33 -0200 >> From: komputes >> Subject: Re: Making it easier for people to work with upstreams >> To: Daniel Holbach , ? ? ? ? Ubuntu Bugsquad >> ? ? ? ? >> Message-ID: <4B4DC559.20504 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> I almost forgot to add to that list... >> >> -creating documentation >> -reviewing stale documentation/wiki >> -creating a PPA with the latest stable upstream version >> -creating a PPA with the latest experimental upstream version >> >> Cheers, >> >> -komputes >> >> ?(]( -. .- )[) >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 13 Jan 2010 14:44:28 +0100 >> From: Daniel Holbach >> Subject: Re: Making it easier for people to work with upstreams >> To: Ubuntu Bugsquad >> Message-ID: <4B4DCE3C.9020508 at ubuntu.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On 13.01.2010 13:56, komputes wrote: >>> 2) https://wiki.ubuntu.com/DanielHolbach/Upstream >>> should be merged with >>> https://wiki.ubuntu.com/Upstream >> >> This is a _proposal_ I'm working on right now. >> >> >>> 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >>> Should be merged with (and a link should take its place) >>> https://wiki.ubuntu.com/BugSquad/AdoptPackage >> >> I'm not sure about that. The page I started writing there was supposed >> to give people an overview over ALL the different parts of the community >> that are an interface between Ubuntu and an Upstream project. It's not >> meant to replace and BugSquad documentation and it's not supposed to >> replace a PPA guide or anything that's in UbuntuDevelopment. >> >> The idea is to give people who are passionate about some kind of >> software the necessary overview to afterwards know >> >> ?- where to start in terms of bugs >> ?- how to be a bridge between Ubuntu and upstream >> ?- how to set up a PPA if they need one >> ?- how to get changes uploaded >> ?- how to get upload rights later on >> ?- where debugging pages live on the wiki >> ?- best-practices of user testing >> ?- etc. >> >> Please note how this spans across multiple parts of the community. This >> is not intending to overwrite any other initiative of any other part of >> community. >> >> As far as I'm concerned a good overview over what people can do, some >> cheat-sheets, some clarification, a nice outreach campaign and a way for >> people share their best-practices would get us a lot more contributors >> that are 1) passionate and effective about the collaboration with the >> upstream they care about and 2) a great contributors to the BugSquad, >> the MOTU team, the testing team, etc. >> >> Have a great day, >> ?Daniel >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Wed, 13 Jan 2010 14:43:56 +0000 >> From: Bruno Girin >> Subject: Re: Making it easier for people to work with upstreams >> To: ubuntu-bugsquad at lists.ubuntu.com >> Message-ID: <1263393836.3082.50.camel at nuuk> >> Content-Type: text/plain; charset="UTF-8" >> >> On Wed, 2010-01-13 at 14:44 +0100, Daniel Holbach wrote: >>> On 13.01.2010 13:56, komputes wrote: >>> > 3) https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >>> > Should be merged with (and a link should take its place) >>> > https://wiki.ubuntu.com/BugSquad/AdoptPackage >>> >>> I'm not sure about that. The page I started writing there was supposed >>> to give people an overview over ALL the different parts of the community >>> that are an interface between Ubuntu and an Upstream project. It's not >>> meant to replace and BugSquad documentation and it's not supposed to >>> replace a PPA guide or anything that's in UbuntuDevelopment. >> >> I agree. The scope of adopt-an-upstream is not the same as >> adopt-a-package. However, both intersect and should work together. >> >> For example, Sense started the Adopt Nautilus group. One thing we've >> identified is that Nautilus has a lot of bugs in the Triaged state that >> have been reported upstream but that don't seem to have been handled. An >> upstream adopter could help us with: >> ? ? ?* moving forward bugs in the upstream tracker >> ? ? ?* feeding back to us the quality of the bug reports (e.g. is there >> ? ? ? ?a piece of information that we should provide on all bug reports >> ? ? ? ?to facilitate handling upstream but that we never provide?); >> ? ? ? ?this could also lead to developing an apport-plugin for that >> ? ? ? ?package to ensure that the missing info becomes included by >> ? ? ? ?default >> ? ? ?* advising us about upcoming functionality that is likely to close >> ? ? ? ?bugs so that we don't spend too much time on issues that have >> ? ? ? ?already been identified and are in the process of being closed >> >> >>> >>> The idea is to give people who are passionate about some kind of >>> software the necessary overview to afterwards know >>> >>> ?- where to start in terms of bugs >>> ?- how to be a bridge between Ubuntu and upstream >>> ?- how to set up a PPA if they need one >>> ?- how to get changes uploaded >>> ?- how to get upload rights later on >>> ?- where debugging pages live on the wiki >>> ?- best-practices of user testing >>> ?- etc. >> >> I would add to this: >> ? ? ?* give us advance warning when some functionality is going to be >> ? ? ? ?deprecated, change dramatically, or will require a newer version >> ? ? ? ?to keep working; e.g. the anki package in Karmic is an older >> ? ? ? ?version that cannot connect to the Anki servers anymore because >> ? ? ? ?they changed the way client-server interaction worked: knowing >> ? ? ? ?this in advance would enable us to upgrade the relevant package >> ? ? ? ?before it becomes an issue for users >> ? ? ?* help us test and validate their packages on the upcoming version >> ? ? ? ?of Ubuntu; e.g. the OpenERP version in the Ubuntu repositories >> ? ? ? ?only works well with Python 2.5, not 2.6. However, since Karmic >> ? ? ? ?(or Jaunty can't remember) the default version of Python is 2.6 >> ? ? ? ?=> OpenERP doesn't work out of the box; this is now solved in >> ? ? ? ?the OpenERP trunk but it means that for it to work on Lucid out >> ? ? ? ?of the box we will need to ensure the latest version is used >> ? ? ?* advise us whether they think we should add other related >> ? ? ? ?packages to offer Ubuntu users the best functionality that the >> ? ? ? ?upstream can offer; e.g. Karmic has packages for OpenERP server >> ? ? ? ?and desktop client but not the web client => adding the web >> ? ? ? ?client would make OpenERP more versatile for Ubuntu users >> >> >>> >>> Please note how this spans across multiple parts of the community. This >>> is not intending to overwrite any other initiative of any other part of >>> community. >>> >>> As far as I'm concerned a good overview over what people can do, some >>> cheat-sheets, some clarification, a nice outreach campaign and a way for >>> people share their best-practices would get us a lot more contributors >>> that are 1) passionate and effective about the collaboration with the >>> upstream they care about and 2) a great contributors to the BugSquad, >>> the MOTU team, the testing team, etc. >> >> Agreed. The scope for upstream contacts is orthogonal to the scope of >> the different teams in the Ubuntu community and people who adopt an >> upstream may have different interests: ensuring bugs are resolved, >> talking to devs and MOTU about upcoming features, talking to the art >> team on visual integration, or to the LoCo teams to do stuff in their >> community, etc. >> >> >>> >>> Have a great day, >> >> Unlikely at the moment as I've got to write a spec for a customer but it >> will definitely get a lot better once I reach the pub (snow permitting). >> Have a great day too! >> >> Bruno >> >> >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 13 Jan 2010 17:49:29 +0100 >> From: Sense Hofstede >> Subject: Re: Making it easier for people to work with upstreams >> To: Daniel Holbach >> Cc: ubuntu-bugsquad at lists.ubuntu.com >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=UTF-8 >> >> Hello, >> >> Op maandag 13-1-2010 schreef Daniel Holbach : >>> When we started thinking of "Adopt an Upstream" it was the name of an >>> initiative. It's not meant to replace anything. >>> >>> The discussion: >>> >>> ?- what is confusing in our processes today >>> ?- what we need to clarify in terms of documentation >>> ?- how interested people find out about the possibilities >>> ?- how we learn from each other and form best practices >>> >>> to me is much more important than the name of the group people who are >>> part of the initiative or the name of the initiative itself. >>> >>> We want to revisit how people who are passionate about a certain piece >>> of software can be most useful, both to Ubuntu and upstream. This was >>> never meant to replace anything or shut-down any other initiative. >> >> Good. It's not that I got the impression that the goal of the project >> was to crush >> all other related projects and I'm also not interested in a discussion about the >> names right now. I just wanted to make sure that no efforts would be duplicated >> and that there wouldn't be worked on two different projects with >> overlapping goals >> -- which Bruno already outlined very well. >> >> I would suggest to add information to your useful Upstream/Adopt page[1] about >> the adoption project of the Bug Squad[2]. >> >>> What I do think we should make clear though is that there is no "big >>> maintainer lock" and there's nobody who handles one project exclusively >>> and that we want to collaborate as good as we can. >>> >> >> This is something I wasn't afraid of, and something I also try to emphasize >> when writing wiki pages for Adopt-a-Package. I think it would indeed be wise >> to make this clear for Adopt-an-Upstream as well, like you said, in order to >> not scare casual contributors and novices away. >> >> Komputes has some good points and I agree with them. >> >> Lets see if I understand the project well enough already. There is >> Adopt-an-Upstream, which is a group of people focussed on a particular part of >> an upstream project, mostly centred around a certain application. The tasks of >> this group vary and involve almost all parts of the community. >> >> Then there is the Upstream Contact. An Upstream Contact is the formalised >> link between upstream and Ubuntu. However, is this for a whole upstream, or >> like Adopt-an-Upstream mostly centred around one application? What is the >> relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >> group, who should do what? The list of tasks on the wiki[3] seems a bit too much >> for one person to me. >> >> I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >> the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >> This because the description of the Upstream Contact[3] does suggest the Contact >> to take ownership of all bugs and work on them with a group of volunteers. This >> group of volunteers could be what's now the Adopt-a-Package group[4] and this >> subteam would also report to the Bug Squad in order to allow us to keep an eye >> on the bug status of Ubuntu. A separate adoption team could be created for >> moving bugs without package to the right one. >> >> [1] https://wiki.ubuntu.com/DanielHolbach/Upstream/Adopt >> [2] https://wiki.ubuntu.com/BugSquad/AdoptPackage >> [3] https://wiki.ubuntu.com/Upstream/Contacts >> [4] https://wiki.ubuntu.com/BugSquad/AdoptionTeam >> >> Regards, >> -- >> Sense Hofstede >> [?s?n.s? ???f.ste?d?] >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 13 Jan 2010 12:48:35 -0500 >> From: "Jorge O. Castro" >> Subject: Re: Making it easier for people to work with upstreams >> To: Sense Hofstede >> Cc: ubuntu-bugsquad >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Wed, Jan 13, 2010 at 11:49 AM, Sense Hofstede wrote: >>> Then there is the Upstream Contact. An Upstream Contact is the formalised >>> link between upstream and Ubuntu. However, is this for a whole upstream, or >>> like Adopt-an-Upstream mostly centred around one application? What is the >>> relation between the tasks of the Upstream Contact and the Adopt-an-Upstream >>> group, who should do what? The list of tasks on the wiki[3] seems a bit too much >>> for one person to me. >> >> Daniel and I discussed this today during our call. >> >> I think this is getting too complicated, so I think we should just >> grab what's in Upstream/Contacts and merge it into Adopt-an-Upstream. >> Me personally, I don't care too much about what the person's title is >> or whether the relationship is formal or informal. As long as >> $potential_volunteer has a place where they can see what kinds of >> things they can do to work better with upstreams then I'm ok with >> that. >> >> Does anyone have any objection to Daniel and I just merging >> Upstream/Contacts into Adopt-an-upstream? >> >>> I would suggest to make the Bug Squad's Adopt-a-Package[2] initiative a part of >>> the Adopt-an-Upstream group, or a subteam, depending on the size of the group. >>> This because the description of the Upstream Contact[3] does suggest the Contact >>> to take ownership of all bugs and work on them with a group of volunteers. This >>> group of volunteers could be what's now the Adopt-a-Package group[4] and this >>> subteam would also report to the Bug Squad in order to allow us to keep an eye >>> on the bug status of Ubuntu. A separate adoption team could be created for >>> moving bugs without package to the right one. >> >> This is starting to get complicated with teams and subteams, etc. At >> the end of the day it breaks down to "My name is Jorge and I care >> about making Banshee better in Ubuntu; I read/write X wiki pages, >> handle Y bugs, on occasions I try to run a Bug Day, I help filter out >> junk bugs for upstreams, I help new users on IRC ...." >> >> Some people will want to do some or all of those things, some people >> will just want to do one bit, or whatever, as long as there's a common >> place on the wiki to help these people link together. I don't think >> people will care that it's actually adopt-a-package or >> adopt-an-upstream, I think they'll start someplace and then as they >> get to know it they might work on the package or in the direct >> upstream bug tracker or whatever and will figure out what to do. >> >> Or am I oversimplifying? Maybe I'm just paranoid because I expect >> someone to jump in with "Then we'll have a council to oversee ...." :p >> >> -- >> Jorge Castro >> jorge (at) ubuntu.com >> External Project Developer Relations >> Canonical Ltd. >> >> >> >> ------------------------------ >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> >> End of Ubuntu-bugsquad Digest, Vol 43, Issue 8 >> ********************************************** >> > > > > ------------------------------ > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > End of Ubuntu-bugsquad Digest, Vol 43, Issue 9 > ********************************************** > From komputes at gmail.com Thu Jan 14 13:47:57 2010 From: komputes at gmail.com (komputes) Date: Thu, 14 Jan 2010 11:47:57 -0200 Subject: Ubuntu-bugsquad Digest, Vol 43, Issue 8 In-Reply-To: References: Message-ID: <4B4F208D.5000502@gmail.com> David Crook wrote: > With "standard" > everyday bugs I have been forwarded a list of canned responses used > for various issues. is there such a thing with nautilus? The canned responses at https://wiki.ubuntu.com/Bugs/Responses are varied and most can be used for different packages. > I would feel > better if there were a list of programs I should have loaded on my > laptop that could help in reproduce bug issues? This is actually quite simple and mostly doesn't require extra packages. Make sure the bug reporter has provided steps to reproduce the issue. If not, request it[1] and mark the bug "Status: Incomplete" and subscribe to the bug. If the steps are there, and you can reproduce the bug, then mark the bug as "Status: Confirmed". If there are any notes you would like to make, add a comment to the bug. This would already help out with the many untouched bugs that are in "Status: New". > I really would like > to feel like I am contributing to this project, thus embracing the > Ubuntu philosophy. I would very much like to give back to what is by > and far the best operating system I have used. So could someone show > me a compass and point me in the right direction, I would like to feel > comfortable In processing these bugs. > I believe this is what Jorge and Daniel have been working on producing (in relation to helping/improving upstream projects in Ubuntu). I have created a checklist of how you can help the Ubuntu project here: https://wiki.ubuntu.com/komputes/HowToHelpUbuntu > Thanks > > Dave > > I was also wondering were I could make some suggestions concerning > the on-line help/ documentation. Sometime the information is written > in a way that is difficult for a new user to understand. For example, > I was having video card issues, sought help via on line documentation > sated that the xservers should be restarted however the exact terminal > command was not listed. The terminal is a daunting thing for ex > windows users.. Anyway , sorry for eating up space and time any > direction would be helpful > It happens that documentation is not properly updated sometimes. Truth is, the process for restarting X has changed multiple times in just the last few releases. To restart X without restarting the computer entirely, in Ubuntu 9.04 and 9.10, check out the following documentation[2]. If you point me to the confusing wiki document in question, I would update that part to include a link to this page[2]. [1] https://wiki.ubuntu.com/Bugs/Responses#Missing%20Steps%20to%20Recreate%20Bug [2] https://wiki.ubuntu.com/X/Config/DontZap From jhaitas at gmail.com Thu Jan 14 16:26:38 2010 From: jhaitas at gmail.com (John Haitas) Date: Thu, 14 Jan 2010 10:26:38 -0600 Subject: ubuntu 10.04 alpha1's sound In-Reply-To: <20100110024101.771.51241.launchpad@wampee.canonical.com> References: <20100110024101.771.51241.launchpad@wampee.canonical.com> Message-ID: <535499f11001140826v309e7055x9de7aca67c05a34f@mail.gmail.com> Are you using the most recent version of Virtualbox? Have you installed the Virtualbox Guest Additons? I have found that this helps. On Sat, Jan 9, 2010 at 8:41 PM, shingomizuno1984 at yahoo.co.jp < shingomizuno1984 at yahoo.co.jp> wrote: > hello im using latest 10.04 alpha1 on virtualbox (latest version too) > but i found little bit problem of sounds. i saw youtube video but i > could musics is so slow seem like who guy using voice changer. i meant > low ton but video motion was good work at youtube. different only sounds > and rhythembox. my setting is 365MB memory, 8GB HDD on virtualbox and im > using them on macbook pro 13inch intel core 2 duo 2.26GHz. > -- > This message was sent from Launchpad by the user > shingomizuno1984 at yahoo.co.jp (https://launchpad.net/~shingomizuno1984) > using the "Contact this team" link on the Ubuntu BugSquad team page. > For more information see > https://help.launchpad.net/YourAccount/ContactingPeople > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -- John Haitas jhaitas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From karljkr at hotmail.com Thu Jan 14 16:09:55 2010 From: karljkr at hotmail.com (EL_Flippo Kristiansen) Date: Thu, 14 Jan 2010 17:09:55 +0100 Subject: Sis671 3-d driver Message-ID: Hello I sent the following letter to sis-PR: Why don\'t you distribute sis671 driver to Linux? Anyone who has this graphic card curses the day they bought a computer with Sis, and will never again buy a computer with your product in it - and further recommend other people who uses Linux not to buy your product. Bad service quality equals few customers, i assure you, in a long time perspective. Regards Karl and the whole Linux community The answer i got was quite optimistic: Dear Sir: Thanks for your reminding. We are considering how to upstream the code to Linux community, but need time to study how to do. If you can help, we can speed up the progress. I wonder if you could contribute? It would be great to finally solve this problem once and for all. Regards Karl _________________________________________________________________ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erdemevin at gmail.com Thu Jan 14 14:01:47 2010 From: erdemevin at gmail.com (Erdem) Date: Thu, 14 Jan 2010 14:01:47 -0000 Subject: A bug for UNR Message-ID: <20100114140147.771.35404.launchpad@wampee.canonical.com> I'm using the UNR (Ubuntu-Netbook-Remix 9.10) at present. It is brilliant for my LG model lgx13 996,1 m intel atom processor. I find out two important bugs in this version. 1- USB ports recognise plugged devices very soon but udev is processing late for some devices. For example some usb gsm/3g modems. 2- More important, if a usb port was used and if I plug a flashdisk or my printer HP 1020 or my scanner Canoscan Lide etc. to another usb port, system is freezing. This is not for always. But especially, if I listen an internet radio (by VLC) , it is becoming highly often. In this case radio is starting to repeat the last sound. Only solution in this case, I press the power button of my computer and hold it. After this, I am booting the computer again and everything returns normal. On the out of these, everything is brilliant. On the other hand, I realy prefer UNR to regular Ubuntu. Using is very easy and user friendly. (Of course, my device is a netbook) For your attention. -- This message was sent from Launchpad by the user Erdem (https://launchpad.net/~erdemevin) using the "Contact this team" link on the Ubuntu BugSquad team page. For more information see https://help.launchpad.net/YourAccount/ContactingPeople From daniel.holbach at ubuntu.com Thu Jan 14 16:58:37 2010 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Thu, 14 Jan 2010 17:58:37 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: <1263488317.23230.1.camel@miyazaki> Am Donnerstag, den 07.01.2010, 14:41 -0500 schrieb Jorge O. Castro: > I've started to put together a little "best practices" > guide for people who want to do this kind of thing: > https://wiki.ubuntu.com/Upstream/Contacts I just merged this into https://wiki.ubuntu.com/Upstream/Adopt and factored in a few people's feedback. Is this a bit clearer now? Have a great day, Daniel From sense at qense.nl Thu Jan 14 17:15:02 2010 From: sense at qense.nl (Sense Hofstede) Date: Thu, 14 Jan 2010 18:15:02 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263488317.23230.1.camel@miyazaki> References: <1263488317.23230.1.camel@miyazaki> Message-ID: 2010/1/14 Daniel Holbach : > Am Donnerstag, den 07.01.2010, 14:41 -0500 schrieb Jorge O. Castro: >> I've started to put together a little "best practices" >> guide for people who want to do this kind of thing: >> https://wiki.ubuntu.com/Upstream/Contacts > > I just merged this into https://wiki.ubuntu.com/Upstream/Adopt and > factored in a few people's feedback. > > Is this a bit clearer now? > > Have a great day, >  Daniel > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > It seems that the link to the Bug Squad maillist is broken. I would also include a link to the Bug Squad mentorship programme[1]. I haven't had a look at the other sections, but in general it looks good to me. [1] https://wiki.ubuntu.com/BugSquad/Mentors Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From brunogirin at gmail.com Fri Jan 15 00:43:01 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 15 Jan 2010 00:43:01 +0000 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263488317.23230.1.camel@miyazaki> References: <1263488317.23230.1.camel@miyazaki> Message-ID: <1263516181.2375.8.camel@nuuk> On Thu, 2010-01-14 at 17:58 +0100, Daniel Holbach wrote: > Am Donnerstag, den 07.01.2010, 14:41 -0500 schrieb Jorge O. Castro: > > I've started to put together a little "best practices" > > guide for people who want to do this kind of thing: > > https://wiki.ubuntu.com/Upstream/Contacts > > I just merged this into https://wiki.ubuntu.com/Upstream/Adopt and > factored in a few people's feedback. > > Is this a bit clearer now? It is yes, just a few comments: In the last bullet point in the "Bugs" section, the link is not closed properly. I would rephrase this sentence: "You should have some experience with the upstream project, it doesn't help if you're working on something you barely know." to "You should have some experience with the upstream project, it really helps if you're working on something you know well." Bruno From hggdh2 at ubuntu.com Fri Jan 15 03:11:20 2010 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Thu, 14 Jan 2010 21:11:20 -0600 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263516181.2375.8.camel@nuuk> References: <1263488317.23230.1.camel@miyazaki> <1263516181.2375.8.camel@nuuk> Message-ID: <4B4FDCD8.8090206@ubuntu.com> On 01/14/10 18:43, Bruno Girin wrote: > I would rephrase this sentence: "You should have some experience with > the upstream project, it doesn't help if you're working on something you > barely know." to "You should have some experience with the upstream > project, it really helps if you're working on something you know well." > > Much better indeed -- goes positive instead of negative. Why don't you update it? Thank you, BTW. ..C.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From daniel.holbach at ubuntu.com Fri Jan 15 09:31:20 2010 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Fri, 15 Jan 2010 10:31:20 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: References: <1263488317.23230.1.camel@miyazaki> Message-ID: <4B5035E8.5090306@ubuntu.com> On 14.01.2010 18:15, Sense Hofstede wrote: > It seems that the link to the Bug Squad maillist is broken. > I would also include a link to the Bug Squad mentorship programme[1]. > > I haven't had a look at the other sections, but in general it looks good to me. > > [1] https://wiki.ubuntu.com/BugSquad/Mentors Which link on which page? Can you fix it? Thanks a lot in advance, Daniel From brunogirin at gmail.com Fri Jan 15 10:03:20 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 15 Jan 2010 10:03:20 +0000 Subject: Making it easier for people to work with upstreams In-Reply-To: <4B5035E8.5090306@ubuntu.com> References: <1263488317.23230.1.camel@miyazaki> <4B5035E8.5090306@ubuntu.com> Message-ID: <1263549800.2389.2.camel@nuuk> On Fri, 2010-01-15 at 10:31 +0100, Daniel Holbach wrote: > Which link on which page? Can you fix it? It was on https://wiki.ubuntu.com/Upstream/Adopt It's now fixed. I also slightly rephrased one bullet point. Bruno From daniel.holbach at ubuntu.com Fri Jan 15 10:12:13 2010 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Fri, 15 Jan 2010 11:12:13 +0100 Subject: Making it easier for people to work with upstreams In-Reply-To: <1263549800.2389.2.camel@nuuk> References: <1263488317.23230.1.camel@miyazaki> <4B5035E8.5090306@ubuntu.com> <1263549800.2389.2.camel@nuuk> Message-ID: <4B503F7D.6090903@ubuntu.com> On 15.01.2010 11:03, Bruno Girin wrote: > It was on https://wiki.ubuntu.com/Upstream/Adopt > It's now fixed. I also slightly rephrased one bullet point. Thanks a lot! Daniel From shahar at shahar-or.co.il Fri Jan 15 10:48:06 2010 From: shahar at shahar-or.co.il (Shahar Or) Date: Fri, 15 Jan 2010 12:48:06 +0200 Subject: Making it easier for people to work with upstreams In-Reply-To: References: Message-ID: Glad for how this turned out. Just like to say well done. On Thu, Jan 7, 2010 at 9:41 PM, Jorge O. Castro wrote: > Hi everyone, > > At UDS we had a discussion on how people can be better "upstream > contacts". This is that person that picks their favorite little app > and does their best to work with an upstream to get the bugs to the > right place. I've started to put together a little "best practices" > guide for people who want to do this kind of thing: > https://wiki.ubuntu.com/Upstream/Contacts > > This person could be a person who is just doing general bug work, or > someone who wants to work on a specific application. Since many of you > tend to do this kind of work already I was hoping for some feedback on > this page and see if it matches up with the kinds of things you might > be talking to upstreams about. The idea for this page is if someone > who wants to make Foobar better then they have a general idea of what > kinds of things they can do to help move bugs along. Thoughts? > > -- > Jorge Castro > jorge (at) ubuntu.com > External Project Developer Relations > Canonical Ltd. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leann.ogasawara at canonical.com Fri Jan 15 17:09:19 2010 From: leann.ogasawara at canonical.com (Leann Ogasawara) Date: Fri, 15 Jan 2010 17:09:19 +0000 Subject: Kernel Bug Day - Tues 19 Jan, 2010 Message-ID: <1263575359.4884.84.camel@emiko> Hi All, This is a friendly reminder that we're starting up Kernel Bug Day's again for the new year. Don't know what a Kernel Bug Day is [1]? This is the perfect opportunity to find out what it's all about. The next Kernel Bug Day will be held Tues. 19 Jan, 2010 [2]. We'll be focusing on bugs with a closed upstream bug watch. These would be good targets in Launchpad to overlook and possibly close as well. Please join us Tuesday in the #ubuntu-kernel IRC channel on FreeNode as we tackle this list of bugs together. Thanks in advance, Leann [1] https://wiki.ubuntu.com/KernelTeam/BugDay [2] https://wiki.ubuntu.com/KernelTeam/BugDay/20100119 From ubuntu.bugsquad at micahscomputing.com Sun Jan 17 20:33:02 2010 From: ubuntu.bugsquad at micahscomputing.com (Micah Gersten) Date: Sun, 17 Jan 2010 14:33:02 -0600 Subject: Ubuntu Translation bug handling process In-Reply-To: References: <1260181297.3621.103.camel@lenovo> <1260612977.7276.54.camel@adi-laptop> <1262615740.2870.111.camel@lenovo> Message-ID: <4B5373FE.1020907@micahscomputing.com> The Bugsquad meeting was postponed to Jan 19th at 1600 UTC -- FYI On 01/04/2010 11:06 AM, Sense Hofstede wrote: > 2010/1/4 David Planella: >> El ds 12 de 12 de 2009 a les 12:16 +0200, en/na Adi Roiban va escriure: >>> Just my 2 cents and I try to be brief and concise.... but I failed >>> >>> I think that all Ubuntu Translators will be happy to make >>> ubuntu-translators less useful by not having to do bug triaging. >>> The bughandling wikipage was just a brainstorming page. I would be happy >>> to delete it and have all info on bugsquad wiki. >>> >>> Ubuntu Translations bugs are something special from the following points >>> of view: >>> >>> * They can be fixed without having someone patching and uploading a new >>> package >>> >>> * Most of them can be fixed in less than 2 minutes, just from the web >>> UI. You only need to read the bug, to to Launchpad translation, fix the >>> translation and then come back and mark that bug as fixed. >>> >>> * Many translators are not technical persons. >>> >>> We can channel all bug to Ubuntu and make them use apport, but I think >>> that this will stop them from reporting bugs. >>> >>> ------------- >>> >>> I like to keep things simple and this is why I went for a divide and >>> conquer approach for handling Ubuntu translations bugs. >>> >>> I think that reporting a bug in Ubuntu is ok when you don't know exactly >>> what component is affected and who can fix it. >>> >>> For translations bug we know they affect ubuntu-translation and they can >>> be fixed by the ubuntu-l10n-CC (replace CC with your language) team. >>> The triaging process can be done by the bug reporter at the time they >>> report the bug. >>> No need to add extra work to other persons. >>> >>> ------------ >>> >>> My goal is to have ubuntu-translation bugs fixed. Fast. Without stepping >>> on others feet. >>> >>> What are the drawbacks of the current process? >>> >>> Right now, in Ubuntu we have 39668 new bugs. What do we gain if we put >>> Ubuntu Translation bugs together? >>> >>> --------- >>> >>> I think we should add this topic on the next team meeting agenda. >>> Next for translations is 7 Jan, bugsquad 12. I am available for both. >>> >>> Kindest regards, >>> >> >> Let's try to move this forward. I like Adi's suggestion to discuss it on >> a meeting, and I see that micahg has already added it to the next >> Bugsquad's meeting on the 12th of January, so we can talk about it >> there. >> >> I've summarised the main points at >> >> https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background >> https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming >> >> I think so far we agree that we can move that page to the bugsquad's >> wiki and let the bugsquad channel translation bugs to the >> ubuntu-translations project as appropriate. >> >> The main point for me is that I'm open to any suggestions for >> optimization. While I'd be prepared to sacrifice the pool of >> translations bugs the ubuntu-translations project offers by submitting >> them only to the source packages, though, I wouln't want to compromise >> the additional benefits it has provided so far: bugmail and the >> ubuntu-translations-coordinators team acting as a driver. I think these >> last points have made all the difference in comparison to the situation >> we already had, that is, having translation bugs reported only against >> the source packages. >> >> Thanks. >> >> Regards, >> David. >> >> -- >> David Planella >> Ubuntu Translations Coordinator >> david(dot)planella(at)ubuntu(dot)com >> www.ubuntu.com >> >> >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > Hello, > > If the separate 'ubuntu-translation' project helps the translations > team then of course it should stay. Reading your mails and the project > documentation made it clear to me that this project has been a great > help for the translators. > I'll try to attend the meeting at January the 12th. Because I do think > that it would be good to define the roles of the Bug Squad and the > Translations team here. The meeting would be a good way to do so since > IRC allows direct communication and ensures the presence and attention > of the team leaders. You already have a workflow in place and of > course we shouldn't force our policies upon you, but there are > overlapping areas where both teams have to deal with the bug reports. > What we should do is to come up with a way to let the bugs show up in > such a way that they are useful to both teams and don't mess up the > statistics of either one of them. > > Thank you for adding the explanation to the wiki page! Now I know > where to direct people to if they want to know more about the policy > of Translations. > > Regards, From siretart at ubuntu.com Mon Jan 18 06:08:33 2010 From: siretart at ubuntu.com (Reinhard Tartler) Date: Mon, 18 Jan 2010 07:08:33 +0100 Subject: strange upgrade bugs with "cannot access archive: No such file or directory" Message-ID: <87ljfweyhq.fsf@faui44a.informatik.uni-erlangen.de> hi folks, While going through my bugmail I've noticed a number of bugs with the same pattern that are assigned to various packages by bug triagers. All Terminal logs look like this: dpkg: error processing /var/cache/apt/archives/libmp3lame0_3.98.2+debian-0ubuntu1_amd64.deb (--unpack): cannot access archive: No such file or directory With googling it seems that the following bugs follow that pattern. https://bugs.edge.launchpad.net/ubuntu/+source/lame/+bug/446801 https://bugs.edge.launchpad.net/ubuntu/+source/cabextract/+bug/471901 https://bugs.edge.launchpad.net/ubuntu/+source/suitesparse/+bug/307078 https://bugs.edge.launchpad.net/ubuntu/+source/xvidcore/+bug/446807 I'm a big puzzled how these failures can happen. Did the file somehow got deleted during the install process? I cannot imagine that some user is calling an 'apt-get clean' deliberatly simultanous to running an dist-upgrade, so I suspect something else is doing this. Moreover, perhaps bugsquad has some infrastructure to batch-process this kind of bugs? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From siretart at ubuntu.com Mon Jan 18 06:28:15 2010 From: siretart at ubuntu.com (Reinhard Tartler) Date: Mon, 18 Jan 2010 07:28:15 +0100 Subject: "Exec format error" bugs Message-ID: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> another pattern of bugs I've encountered end with "Exec format errors". Normally I would expect that if someone tried to execute and amd64 binary on a i386 system. However, this does not seem to be the case e.g. in this bug: https://bugs.edge.launchpad.net/ubuntu/+source/dirac/+bug/482413 Moreover, googling shows that this is not a that uncommon problem (about 1670 hits for me): http://www.google.com/search?hl=en&q=dpkg+"Exec+format+error" I wonder where this is caused from. A possible explanation would be that the download was corrupted in some way. However apt is supposed to cryptographically verify the integrity of downloaded archive, so either there is some serious problem with apt here, or there must be some other explanation for this pattern. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From shahar at shahar-or.co.il Mon Jan 18 08:20:29 2010 From: shahar at shahar-or.co.il (Shahar Or) Date: Mon, 18 Jan 2010 10:20:29 +0200 Subject: Sis671 3-d driver In-Reply-To: References: Message-ID: I've sent this along to the Linux Foundation asking them what to do. Did anyone else do anything? Are there folks at the kernel development which serve as chip company contacts or something? On Thu, Jan 14, 2010 at 6:09 PM, EL_Flippo Kristiansen wrote: > Hello > I sent the following letter to sis-PR: > > Why don\'t you distribute sis671 driver to Linux? Anyone who has this > graphic card curses the day they bought a computer with Sis, and will never > again buy a computer with your product in it - and further recommend other > people who uses Linux not to buy your product. Bad service quality equals > few customers, i assure you, in a long time perspective. > > Regards > Karl and the whole Linux community > > The answer i got was quite optimistic: > > Dear Sir: > > > > Thanks for your reminding. We are considering how to upstream the code to > Linux community, but need time to study how to do. If you can help, we can > speed up the progress. > > > > I wonder if you could contribute? It would be great to finally solve this > problem once and for all. > > Regards Karl > > ------------------------------ > Windows Live: Friends get your Flickr, Yelp, and Digg updates when they > e-mail you. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicedar at gmail.com Mon Jan 18 09:51:15 2010 From: vicedar at gmail.com (Savvas Radevic) Date: Mon, 18 Jan 2010 10:51:15 +0100 Subject: strange upgrade bugs with "cannot access archive: No such file or directory" In-Reply-To: <87ljfweyhq.fsf@faui44a.informatik.uni-erlangen.de> References: <87ljfweyhq.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: Maybe one of the following: 1. Not enough free space? 2. Problems with ext4? (Maybe the file got corrupt during a hard reboot?) 3. Maybe they have adsl or cable internet with limited downloading/uploading. Perhaps once they reached the limit, the file was downloaded as an HTML page or something of that sort. ("E: Read error - read (9: Bad file descriptor)") For (2), I had a totally weird bug once and the question still remains between ext4 and dpkg: https://bugs.launchpad.net/bugs/338607 It was a one-time thing and never happened again. But I still think it was ext4. :) 2010/1/18 Reinhard Tartler > hi folks, > > While going through my bugmail I've noticed a number of bugs with the > same pattern that are assigned to various packages by bug triagers. All > Terminal logs look like this: > > dpkg: error processing > /var/cache/apt/archives/libmp3lame0_3.98.2+debian-0ubuntu1_amd64.deb > (--unpack): > cannot access archive: No such file or directory > > With googling it seems that the following bugs follow that pattern. > > https://bugs.edge.launchpad.net/ubuntu/+source/lame/+bug/446801 > https://bugs.edge.launchpad.net/ubuntu/+source/cabextract/+bug/471901 > https://bugs.edge.launchpad.net/ubuntu/+source/suitesparse/+bug/307078 > https://bugs.edge.launchpad.net/ubuntu/+source/xvidcore/+bug/446807 > > I'm a big puzzled how these failures can happen. Did the file somehow > got deleted during the install process? I cannot imagine that some user > is calling an 'apt-get clean' deliberatly simultanous to running an > dist-upgrade, so I suspect something else is doing this. > > Moreover, perhaps bugsquad has some infrastructure to batch-process this > kind of bugs? > > -- > Gruesse/greetings, > Reinhard Tartler, KeyID 945348A4 > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diesch at spamfence.net Mon Jan 18 14:26:57 2010 From: diesch at spamfence.net (Florian Diesch) Date: Mon, 18 Jan 2010 15:26:57 +0100 Subject: "Exec format error" bugs In-Reply-To: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> (Reinhard Tartler's message of "Mon, 18 Jan 2010 07:28:15 +0100") References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <87636za3pq.fsf@scenic.florian-diesch.de> Reinhard Tartler writes: > another pattern of bugs I've encountered end with "Exec format > errors". Normally I would expect that if someone tried to execute and > amd64 binary on a i386 system. However, this does not seem to be the > case e.g. in this bug: > > https://bugs.edge.launchpad.net/ubuntu/+source/dirac/+bug/482413 > > Moreover, googling shows that this is not a that uncommon problem (about > 1670 hits for me): > > http://www.google.com/search?hl=en&q=dpkg+"Exec+format+error" > > I wonder where this is caused from. A possible explanation would be that > the download was corrupted in some way. However apt is supposed to > cryptographically verify the integrity of downloaded archive, so either > there is some serious problem with apt here, or there must be some other > explanation for this pattern. I've seen a few cases where this was caused by the post-install script being an empty file, maybe caused by I/O errors during install Florian -- GUIs programmieren mit Python und Glade: From sense at qense.nl Mon Jan 18 15:16:22 2010 From: sense at qense.nl (Sense Hofstede) Date: Mon, 18 Jan 2010 16:16:22 +0100 Subject: Nautilus Adoption statistics recording started Message-ID: Hello, In order to keep track of your progress properly you need data and old data for comparison. I've written a small script -- available at lp:~qense/+junk/adoptionstats -- that outputs the request time in UTC and a dictionary of statuses and the number of bugs in that status. You can call the script with the command './adoptionstats -p {source_package}'. It uses optparse and logging, so you can provide the '-v' option to see debug level messages. The script writes directly to stdout, so you can use that if you want to set stdout to something differently. I've already added the first entry to the Nautilus Adoption page[1] and am planning to generate nice graphs from the the list of data as soon as there is more. Now we can see how Nautilus is doing and people can see where the most help is needed. The closed statuses are also included, but I do plan to make those less visible in the graphs to outline the fact that they don't need to be focused on anymore. [1] https://wiki.ubuntu.com/BugSquad/AdoptPackage/Nautilus#Status Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From przemekkulczycki at gmail.com Mon Jan 18 15:24:04 2010 From: przemekkulczycki at gmail.com (Przemek Kulczycki) Date: Mon, 18 Jan 2010 15:24:04 +0000 Subject: Translation help - working with translated logs - can syslog keep an untranslated copy? Message-ID: Hi guys. I was referred to this list by Ara, who replied to my email to ubuntu-qa list and mention a recent thread from this list named "Translation help". https://lists.ubuntu.com/archives/ubuntu-bugsquad/2009-December/001668.html I would like to follow up on this discussion with the email that I've sent earlier to ubu-qa and ubu-dev-discuss. Sorry for the duplication to those of you who already have read it. Here's the email: ----- Recently, while reviewing lots of logs for bugs in msttcorefonts I have been struck by an idea. Lots of these logs were translated to local languages (german, french, spanish, chinese, ...) which makes it a lot harder to troubleshoot the issues since most people do not know all these languages at the same time. So I came up with this idea: can Syslog be configured or patched so it would keep 2 sets of logs? - 1 translated for the user, and another 1 untranslated (in english) for reporting bugs. This would make bug troubleshooting much easier, since all logs could be sent in 1 language, also apport could be patched then to send only the english logs instead of the translated ones. What do you think about it? Would it be worth to implement it? English is the lingua franca of bug reporting so I think it would be worth it, even if the size of the logs on the disk would be doubled. ----- In addition to my original email I can now see that this would probably require modifying all the apps that send the messages to syslog, or maybe just modify gettext and other translation/localisation engines. Regards, -- ## Przemysław Kulczycki <<=>> Azrael Nightwalker ## # Jabber/XMPP/Gtalk/Tlen ID: azrael[na]jabster.pl # # (Co to jest? Zobacz na: http://jabberfaq.info ) # ## www: http://reksio.ftj.agh.edu.pl/~azrael/ ##### From brunogirin at gmail.com Mon Jan 18 15:34:45 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 18 Jan 2010 15:34:45 +0000 Subject: Nautilus Adoption statistics recording started In-Reply-To: References: Message-ID: <1263828885.2560.14.camel@nuuk> On Mon, 2010-01-18 at 16:16 +0100, Sense Hofstede wrote: > Hello, > > In order to keep track of your progress properly you need data and old > data for comparison. > I've written a small script -- available at > lp:~qense/+junk/adoptionstats -- that outputs the request > time in UTC and a dictionary of statuses and the number of bugs in that status. > You can call the script with the command './adoptionstats -p > {source_package}'. It uses optparse > and logging, so you can provide the '-v' option to see debug level messages. > The script writes directly to stdout, so you can use that if you want > to set stdout to something > differently. Works great, thanks! > > I've already added the first entry to the Nautilus Adoption page[1] > and am planning to generate > nice graphs from the the list of data as soon as there is more. Now we > can see how Nautilus is > doing and people can see where the most help is needed. > The closed statuses are also included, but I do plan to make those > less visible in the graphs to > outline the fact that they don't need to be focused on anymore. If the idea is to highlight what areas need to be worked on, is it possible also filter the number of bugs that need to be forwarded upstream please? On the web page, it would also be nice if next to each category, you had a link to the list of bugs in that category on LP, just to make it easier to get to them. Bruno From siretart at ubuntu.com Tue Jan 19 06:45:27 2010 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 19 Jan 2010 07:45:27 +0100 Subject: "Exec format error" bugs In-Reply-To: <87636za3pq.fsf@scenic.florian-diesch.de> (Florian Diesch's message of "Mon, 18 Jan 2010 15:26:57 +0100") References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> <87636za3pq.fsf@scenic.florian-diesch.de> Message-ID: <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> On Mo, Jan 18, 2010 at 15:26:57 (CET), Florian Diesch wrote: > Reinhard Tartler writes: > >> another pattern of bugs I've encountered end with "Exec format >> errors". Normally I would expect that if someone tried to execute and >> amd64 binary on a i386 system. However, this does not seem to be the >> case e.g. in this bug: >> >> https://bugs.edge.launchpad.net/ubuntu/+source/dirac/+bug/482413 >> >> Moreover, googling shows that this is not a that uncommon problem (about >> 1670 hits for me): >> >> http://www.google.com/search?hl=en&q=dpkg+"Exec+format+error" >> >> I wonder where this is caused from. A possible explanation would be that >> the download was corrupted in some way. However apt is supposed to >> cryptographically verify the integrity of downloaded archive, so either >> there is some serious problem with apt here, or there must be some other >> explanation for this pattern. > > I've seen a few cases where this was caused by the post-install script > being an empty file, maybe caused by I/O errors during install Can we do better than closing the bugs with "we believe that your computer has hardware problems, please retry with reinstallation of ubuntu and reopen if you still experience this issue"? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From hyperair at ubuntu.com Tue Jan 19 07:32:46 2010 From: hyperair at ubuntu.com (Chow Loong Jin) Date: Tue, 19 Jan 2010 15:32:46 +0800 Subject: "Exec format error" bugs In-Reply-To: <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> <87636za3pq.fsf@scenic.florian-diesch.de> <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <4B55601E.9000204@ubuntu.com> On Tuesday 19,January,2010 02:45 PM, Reinhard Tartler wrote: > [...] >> I've seen a few cases where this was caused by the post-install script >> being an empty file, maybe caused by I/O errors during install > > Can we do better than closing the bugs with "we believe that your > computer has hardware problems, please retry with reinstallation of > ubuntu and reopen if you still experience this issue"? > Shouldn't dpkg realize if there are I/O errors while unpacking the {pre,post}{inst,rm} scripts? Perhaps this warning should be put there instead, and dpkg should probably abort and roll back whatever it was doing. This is probably related to the out of disk space error -- dpkg creates the file and tries to write but cannot because there is no more space. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From sense at qense.nl Tue Jan 19 18:26:23 2010 From: sense at qense.nl (Sense Hofstede) Date: Tue, 19 Jan 2010 19:26:23 +0100 Subject: Policy for translation bugs determined Message-ID: Hello, Earlier today we had the monthly Bug Squad meeting[1] that was postponed to this date last week. We discussed the interaction between the Ubuntu Bug Squad[2] and the Ubuntu Translations[3] teams. The reasons for a separate Launchpad project for translations bug are on the wiki pages of the Translations team[4], as well as a summary of the discussion held previously on these maillists[5]. During this meeting the following policy was determined: all bugs in Ubuntu related to translation should get a separate task for the 'ubuntu-translations' project. This task can be added immediately when the bug has been identified as a translations bug. Next to the usual reports about string fixes, typos and others this also includes bugs regarding the Launchpad integration. When a bug's task for the 'ubuntu' project is marked as 'Triaged' the people working on the bugs in 'ubuntu-translations' know that they can start working on it. When they've fixed the issue in the translations the 'ubuntu' task can be used like any other bug report that is linked to an issue upstream. Members of Ubuntu Bug Control[6] and the Ubuntu Translations Coordinators[7], a member of the 'ubuntu-translations-bugsupervisors' team[8], which is the Bug Supervisor for the 'ubuntu-translations' project. They have the permission to set 'ubuntu-translation' tasks to Triaged as well. A new section has been added to Bugs/HowToTriage[9] explaining how translation bugs should be treated. David Planella suggested to remove the reference to Launchpad integration in the documentation in order to make the text less confusing for new triagers. Do you agree? Any feedback on the description would be appreciated. [1] https://wiki.ubuntu.com/BugSquad/Meeting/Minutes/2010-01-19 [2] https://wiki.ubuntu.com/BugSquad [3] https://wiki.ubuntu.com/Translations [4] https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background [5] https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming [6] https://wiki.ubuntu.com/UbuntuBugControl [7] https://launchpad.net/~ubuntu-translations-coordinators [8] https://launchpad.net/~ubuntu-translations-bugsupervisors [9] https://wiki.ubuntu.com/Bugs/HowToTriage#Translation_Bugs_and_Launchpad_integration Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From sense at qense.nl Tue Jan 19 19:00:24 2010 From: sense at qense.nl (Sense Hofstede) Date: Tue, 19 Jan 2010 20:00:24 +0100 Subject: Nautilus Adoption statistics recording started In-Reply-To: <1263828885.2560.14.camel@nuuk> References: <1263828885.2560.14.camel@nuuk> Message-ID: > If the idea is to highlight what areas need to be worked on, is it > possible also filter the number of bugs that need to be forwarded > upstream please? > Good idea! I'll make the script fetch that information as well. However, please keep in mind that it can only count the bugs with open tasks for upstream; bugs that should be forwarded upstream but don't have a task open won't show up on these stats. > On the web page, it would also be nice if next to each category, you had > a link to the list of bugs in that category on LP, just to make it > easier to get to them. > A few from those links should be in the task descriptions but were broken by my wrong use of MoinMoin variables. I'll clean the task descriptions and create a separate section on the wiki page for links. EndOfReply The AdoptionTeam for Nautilus is ready now and if you haven't started with triaging already you should now! I'll blog about the project, but what we need most are people that are willing to do a lot of work and that can do a lot of work. Those numbers of open bugs need to go down! Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] From brunogirin at gmail.com Tue Jan 19 23:30:01 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 19 Jan 2010 23:30:01 +0000 Subject: Nautilus Adoption statistics recording started In-Reply-To: References: <1263828885.2560.14.camel@nuuk> Message-ID: <1263943801.2386.61.camel@nuuk> On Tue, 2010-01-19 at 20:00 +0100, Sense Hofstede wrote: > > If the idea is to highlight what areas need to be worked on, is it > > possible also filter the number of bugs that need to be forwarded > > upstream please? > > > Good idea! I'll make the script fetch that information as well. > However, please keep in mind that it can only count the bugs with open > tasks for upstream; bugs that should be forwarded upstream but don't > have a task open won't show up on these stats. Do you mean you can't implement natural language parsing of the comments to check if it needs to be forwarded upstream? ;-) Another thought I just add that may or may not be useful: on the grounds that most Nautilus bugs should be forwarded upstream at one point or another, would it be useful to also count bugs that are in the "Triaged" state but have no upstream task? > > > On the web page, it would also be nice if next to each category, you had > > a link to the list of bugs in that category on LP, just to make it > > easier to get to them. > > > A few from those links should be in the task descriptions but were > broken by my wrong use of MoinMoin variables. I'll clean the task > descriptions and create a separate section on the wiki page for links. Excellent! > > EndOfReply > > The AdoptionTeam for Nautilus is ready now and if you haven't started > with triaging already you should now! I'll blog about the project, but > what we need most are people that are willing to do a lot of work and > that can do a lot of work. Those numbers of open bugs need to go down! Absolutely right. I've started triaging but not as many as I would like. Next on my list is to set up a couple of VMs to test the most complex of those bugs. Bruno From kamusin at gmail.com Wed Jan 20 13:16:35 2010 From: kamusin at gmail.com (Kamus) Date: Wed, 20 Jan 2010 10:16:35 -0300 Subject: Announcing the Next Ubuntu Hug Day! - Thursday 21 January 2010 Message-ID: Fellow Ubuntu Triagers! This week's Bug Day target is *drum roll please* network-manager-applet! * 100 New bugs need a hug * 26 Incompletes bugs * 40 Confirmed bugs need a review * 6 Bugs needs to be forwarded Bookmark it, add it to your calendars, turn over those egg-timers!   * Thursday 21 January 2010   * https://wiki.ubuntu.com/UbuntuBugDay/20100121 Are you looking for a way to start giving some love back to your adorable Ubuntu Project? Did you ever wonder what Triage is? Want to learn about that? This is a perfect time!, Everybody can help in a Bug Day! Open your IRC Client and go to #ubuntu-bugs (FreeNode) the BugSquad will be happy to help you to start contributing! Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! We are always looking for new tasks or ideas for the Bug Days, if you have one add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning If you're new to all this (like me!) and you want to know more about ubuntu?, head to http://wiki.ubuntu.com/Bugs Have a nice day,    Kamus  [From the BugSquad] -- Victor Vargas B. Latitud: -33.439177,-70.625267 Santiago, Chile. From strycore at gmail.com Mon Jan 25 00:54:19 2010 From: strycore at gmail.com (Mathieu Comandon) Date: Mon, 25 Jan 2010 01:54:19 +0100 Subject: The Bugsquad documentation , from Wiki to PDF Message-ID: <4B5CEBBB.3030108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Bug Squad team I wanted to get more involved with the Bug Squad but I've always found it hard to get anything from the Wiki. I always get to the point where I have more than 10 open tabs on Firefox and I rarely finish reading any page. There's always an hyperlink getting in the way, begging to be clicked, promising new hidden knowledge. On my agenda I had planned to read every single page from the Bug Squad knowledge base, but it still didn't help. So I started making a flat document out of all this documentation. I like books or PDFs more than Wikis, especially if there's a lot to learn. Books have a start and an end, you can continue where you left when you stopped reading, you're not reading 10 pages at the same time and you know how many pages are left before you finish. I try putting pages in a coherent order and I avoid making forward references. Besides reorganizing the pages, I also format the pages so that they look good in Open Office, remove hyperlinks when they are not necessary or put them as footnotes. I intend to add every page from https://wiki.ubuntu.com/CategoryBugSquad in this document (except IRC logs). There might be a few pages that are not related to bug management if necessary (i.e. from CategoryUbuntuDevelopment ). This is also a very good way for me to learn about dealing with bugs in Ubuntu. Bug Triage won't have any secrets for me when I finish this ;) When it's ready, it might be a good idea to make a deb package out of it and include it in the repos. A sneak preview of the work done so far can be fetched here : http://strycore.com/ubuntu-bugs.pdf Hope you like the idea :) Mathieu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktc67sACgkQa0F+7SVw2RKpCACeIAV2deaY7PlIW3oniM0W1R4Q /gEAn2hm/NNTS5hClew4p4fMpB8MIS3/ =r/Jk -----END PGP SIGNATURE----- From cyan.spam at gmail.com Mon Jan 25 02:26:23 2010 From: cyan.spam at gmail.com (David Tombs) Date: Sun, 24 Jan 2010 21:26:23 -0500 Subject: The Bugsquad documentation , from Wiki to PDF In-Reply-To: <4B5CEBBB.3030108@gmail.com> References: <4B5CEBBB.3030108@gmail.com> Message-ID: <4B5D014F.2070001@gmail.com> Hi Mathieu, Personally, I think that's great, and I really appreciate you investing the time into doing it! My only suggestion would be not to be too rigid about having every Wiki page in the PDF. A short, easily-read PDF would be a great introduction and anyone looking for further information can refer to the wiki. If we're going to push this as a good place to start learning about bug work, we don't want to scare anyone off! For example, most people wouldn't be interested in creating a hug day, though it's still good to mention in the PDF. Again, thanks for your work! This will be a great improvement I'm sure. David Mathieu Comandon wrote: > Hello Bug Squad team > > I wanted to get more involved with the Bug Squad but I've always found > it hard to get anything from the Wiki. I always get to the point where > I have more than 10 open tabs on Firefox and I rarely finish reading > any page. There's always an hyperlink getting in the way, begging to > be clicked, promising new hidden knowledge. > > On my agenda I had planned to read every single page from the Bug > Squad knowledge base, but it still didn't help. So I started making a > flat document out of all this documentation. I like books or PDFs more > than Wikis, especially if there's a lot to learn. Books have a start > and an end, you can continue where you left when you stopped reading, > you're not reading 10 pages at the same time and you know how many > pages are left before you finish. > > I try putting pages in a coherent order and I avoid making forward > references. Besides reorganizing the pages, I also format the pages so > that they look good in Open Office, remove hyperlinks when they are > not necessary or put them as footnotes. I intend to add every page > from https://wiki.ubuntu.com/CategoryBugSquad in this document (except > IRC logs). There might be a few pages that are not related to bug > management if necessary (i.e. from CategoryUbuntuDevelopment ). > > This is also a very good way for me to learn about dealing with bugs > in Ubuntu. Bug Triage won't have any secrets for me when I finish this ;) > When it's ready, it might be a good idea to make a deb package out of > it and include it in the repos. > > A sneak preview of the work done so far can be fetched here : > http://strycore.com/ubuntu-bugs.pdf > > Hope you like the idea :) > Mathieu From shahar at shahar-or.co.il Mon Jan 25 09:19:15 2010 From: shahar at shahar-or.co.il (Shahar Or) Date: Mon, 25 Jan 2010 11:19:15 +0200 Subject: The Bugsquad documentation , from Wiki to PDF In-Reply-To: <4B5CEBBB.3030108@gmail.com> References: <4B5CEBBB.3030108@gmail.com> Message-ID: Excellent idea! Keep it up! On Mon, Jan 25, 2010 at 2:54 AM, Mathieu Comandon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Bug Squad team > > I wanted to get more involved with the Bug Squad but I've always found > it hard to get anything from the Wiki. I always get to the point where > I have more than 10 open tabs on Firefox and I rarely finish reading > any page. There's always an hyperlink getting in the way, begging to > be clicked, promising new hidden knowledge. > > On my agenda I had planned to read every single page from the Bug > Squad knowledge base, but it still didn't help. So I started making a > flat document out of all this documentation. I like books or PDFs more > than Wikis, especially if there's a lot to learn. Books have a start > and an end, you can continue where you left when you stopped reading, > you're not reading 10 pages at the same time and you know how many > pages are left before you finish. > > I try putting pages in a coherent order and I avoid making forward > references. Besides reorganizing the pages, I also format the pages so > that they look good in Open Office, remove hyperlinks when they are > not necessary or put them as footnotes. I intend to add every page > from https://wiki.ubuntu.com/CategoryBugSquad in this document (except > IRC logs). There might be a few pages that are not related to bug > management if necessary (i.e. from CategoryUbuntuDevelopment ). > > This is also a very good way for me to learn about dealing with bugs > in Ubuntu. Bug Triage won't have any secrets for me when I finish this ;) > When it's ready, it might be a good idea to make a deb package out of > it and include it in the repos. > > A sneak preview of the work done so far can be fetched here : > http://strycore.com/ubuntu-bugs.pdf > > Hope you like the idea :) > Mathieu > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktc67sACgkQa0F+7SVw2RKpCACeIAV2deaY7PlIW3oniM0W1R4Q > /gEAn2hm/NNTS5hClew4p4fMpB8MIS3/ > =r/Jk > -----END PGP SIGNATURE----- > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brunogirin at gmail.com Mon Jan 25 12:13:13 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 25 Jan 2010 12:13:13 +0000 Subject: The Bugsquad documentation , from Wiki to PDF In-Reply-To: <4B5CEBBB.3030108@gmail.com> References: <4B5CEBBB.3030108@gmail.com> Message-ID: <6cad31401001250413w7db36e93t7448e4b28c2168b7@mail.gmail.com> 2010/1/25 Mathieu Comandon : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Bug Squad team > > I wanted to get more involved with the Bug Squad but I've always found > it hard to get anything from the Wiki. I always get to the point where > I have more than 10 open tabs on Firefox and I rarely finish reading > any page. There's always an hyperlink getting in the way, begging to > be clicked, promising new hidden knowledge. > > On my agenda I had planned to read every single page from the Bug > Squad knowledge base, but it still didn't help. So I started making a > flat document out of all this documentation. I like books or PDFs more > than Wikis, especially if there's a lot to learn. Books have a start > and an end, you can continue where you left when you stopped reading, > you're not reading 10 pages at the same time and you know how many > pages are left before you finish. That's a great idea! A PDF can also be downloaded locally so that you have the info at your fingertips even when no connected to the net. > > I try putting pages in a coherent order and I avoid making forward > references. Besides reorganizing the pages, I also format the pages so > that they look good in Open Office, remove hyperlinks when they are > not necessary or put them as footnotes. I intend to add every page > from https://wiki.ubuntu.com/CategoryBugSquad in this document (except > IRC logs). There might be a few pages that are not related to bug > management if necessary (i.e. from CategoryUbuntuDevelopment ). If you are re-organising or re-wording part of it, it would make sense to feed it back to the wiki. In particular, I like your diagrams on page 7. > > This is also a very good way for me to learn about dealing with bugs > in Ubuntu. Bug Triage won't have any secrets for me when I finish this ;) > When it's ready, it might be a good idea to make a  deb package out of > it and include it in the repos. > > A sneak preview of the work done so far can be fetched here : > http://strycore.com/ubuntu-bugs.pdf > > Hope you like the idea :) This is a great idea! My only concern is how do we ensure that the PDF and the wiki are in sync? It looks like a lot of manual work so it is likely to get out of sync as soon as the wiki gets updated. Anyway, that's a problem we can solve later. On a related subject, would it make sense to also distribute that sort of information as an Ubuntu Help Centre additional package? Bruno From yofel at gmx.net Mon Jan 25 12:39:39 2010 From: yofel at gmx.net (Philip Muskovac) Date: Mon, 25 Jan 2010 13:39:39 +0100 Subject: The Bugsquad documentation , from Wiki to PDF In-Reply-To: <6cad31401001250413w7db36e93t7448e4b28c2168b7@mail.gmail.com> References: <4B5CEBBB.3030108@gmail.com> <6cad31401001250413w7db36e93t7448e4b28c2168b7@mail.gmail.com> Message-ID: <4B5D910B.4010102@gmx.net> >> I try putting pages in a coherent order and I avoid making forward >> references. Besides reorganizing the pages, I also format the pages so >> that they look good in Open Office, remove hyperlinks when they are >> not necessary or put them as footnotes. I intend to add every page >> from https://wiki.ubuntu.com/CategoryBugSquad in this document (except >> IRC logs). There might be a few pages that are not related to bug >> management if necessary (i.e. from CategoryUbuntuDevelopment ). > > If you are re-organising or re-wording part of it, it would make sense > to feed it back to the wiki. In particular, I like your diagrams on > page 7. > Those charts are actually part of the Wiki at https://wiki.ubuntu.com/Bugs/HowToTriage/Charts That page is linked from the HowToTriage page as well as from https://wiki.ubuntu.com/BugSquad/KnowledgeBase maybe the Knowledge Base isn't as prominent as it should be? It should be one of the first places to go when looking for information. >> >> This is also a very good way for me to learn about dealing with bugs >> in Ubuntu. Bug Triage won't have any secrets for me when I finish this ;) >> When it's ready, it might be a good idea to make a deb package out of >> it and include it in the repos. >> >> A sneak preview of the work done so far can be fetched here : >> http://strycore.com/ubuntu-bugs.pdf >> >> Hope you like the idea :) > > This is a great idea! My only concern is how do we ensure that the PDF > and the wiki are in sync? It looks like a lot of manual work so it is > likely to get out of sync as soon as the wiki gets updated. Anyway, > that's a problem we can solve later. > > On a related subject, would it make sense to also distribute that sort > of information as an Ubuntu Help Centre additional package? It certainly would help if we could add it as a package to make it available in the repository. Or maybe add it to the ubuntu-qa-tools? > > Bruno > Yofel From david.planella at ubuntu.com Mon Jan 25 13:16:11 2010 From: david.planella at ubuntu.com (David Planella) Date: Mon, 25 Jan 2010 14:16:11 +0100 Subject: Ubuntu Translations bug supervisor temporarily disabled Message-ID: <1264425371.2588.265.camel@lenovo> Hi all, Just a quick note to say that I've disabled the bug supervisor from the https://bugs.launchpad.net/ubuntu-translations project until we have a mailing list to direct that bug mail to, since that it seems folks were receiving extra mail due to a missing mailing list contact on the https://launchpad.net/~ubuntu-translations-bugsupervisors team [1]. I requested the creation of a ubuntu-translations-bugs mailing list last week and as soon as it is created, I'll set up the bug supervisor again. I apologise for any additional bugmail you might have received. Regards, David. [1] https://wiki.ubuntu.com/BugSquad/Meeting/Minutes/2010-01-19 -- David Planella Ubuntu Translations Coordinator david(dot)planella(at)ubuntu(dot)com www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: Això és una part d'un missatge signada digitalment URL: From jeanbaptiste.lallement at gmail.com Tue Jan 26 17:46:07 2010 From: jeanbaptiste.lallement at gmail.com (Jean-Baptiste Lallement) Date: Tue, 26 Jan 2010 18:46:07 +0100 Subject: [LONG] Re: "Exec format error" bugs In-Reply-To: <4B55601E.9000204@ubuntu.com> References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> <87636za3pq.fsf@scenic.florian-diesch.de> <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> <4B55601E.9000204@ubuntu.com> Message-ID: <2770b9f71001260946p3b04258dhf8a35b20317c6e98@mail.gmail.com> 2010/1/19 Chow Loong Jin : > On Tuesday 19,January,2010 02:45 PM, Reinhard Tartler wrote: >> [...] >>> I've seen a few cases where this was caused by the post-install script >>> being an empty file, maybe caused by I/O errors during install >> >> Can we do better than closing the bugs with "we believe that your >> computer has hardware problems, please retry with reinstallation of >> ubuntu and reopen if you still experience this issue"? >> > Shouldn't dpkg realize if there are I/O errors while unpacking the > {pre,post}{inst,rm} scripts? Perhaps this warning should be put there instead, > and dpkg should probably abort and roll back whatever it was doing. > > This is probably related to the out of disk space error -- dpkg creates the file > and tries to write but cannot because there is no more space. > Hi, I reviewed around 50 of these reports and here is the result. Firstly, nearly half of the reports are not in english. It's not easy to find a pattern to identify and process those reports. The following messages are the same error in different languages: - Erreur de format pour exec() - Error de formato ejecutable - Errore di formato di exec - Exec format error - Formatfel på körbar fil - Érvénytelen végrehajtható fájlformátum - Exec formátum hiba - Verkeerd uitvoerbaar bestand - Exec 格式错误 Other symptoms are : dpkg exits with status 2 and sometimes an ldconfig error : "/sbin/ldconfig.real: File /usr/lib/libSatLib.so.4 is empty, not checked". This error is due to an empty or corrupted installation/removal script ( /var/lib/dpkg/info/PACKAGE.p* ) . It's very easy to reproduce (but don't do what I say), simply run: $ sudo :> /var/lib/dpkg/info/PACKAGE.postinst Regarding the causes of the failure: - 54% Installation aborted due to : power failure - AC unplugged - , hardware failure, hardware lock, hard reboot, ... Clearly a data loss situation. - 29% No unpack : Only the dpkg configure step is executed and no dpkg unpack is shown in the log files. In other words, the following sequence is shown in the term.log: == Log started: 2009-10-31 22:26:39 [...] * nothing in the log file about the package libntfs-3g54 * [...] Processing triggers for python-support ... Setting up libntfs-3g54 (1:2009.4.4-1ubuntu4) ... dpkg (subprocess): unable to execute installed post-installation script: Exec format error dpkg: error processing libntfs-3g54 (--configure): subprocess installed post-installation script returned error exit status 2 == The package has been unpacked but no information written to disk. A system crash is likely to blame. - 7% Bus error or Segmentation fault during installation of the package. - 10% : I don't know This tends to show that most of the errors (90%) are caused by a system failure during a previous installation and not related to an I/O error, lack of disk space or apt bug. The really bad point is that the next runs of dpkg will trigger the error and there is no easy way to recover from it for the common user. What could be done ? Some suggestions: - package manager : try to unpack the archive again in order to overwrite the faulty files, if it's not found fetch then unpack the archive, and try performing the requested operation again. If that fails, then really cancel the installation. But the package manager need to know it's an "exec format error" and that's not easy due to the comments above. Another option could be to ask to the user if he wants to try the workaround. - dpkg : add a 'force' option to 'vanish' the package if the removal script fails during a removal and/or configuration purging ( with a BIG RED warning that it can seriously damage the user's installation) instead of running abort-remove or leaving the package half-installed. But I don't know the dpkg internals to know if it's a valid option. Finally, I filed a master report as bug 512096 [1], explaining the error and workarounds, so please mark any related report you may find as duplicate of that one. This issue is documented on the bugsquad's wiki page [2] Feel free to add additional informations. Additional note: The same symptom exists for dkms with the following pattern run-parts: failed to exec /etc/kernel/postinst.d/dkms: Exec format error run-parts: /etc/kernel/postinst.d/dkms exited with return code 1 This is due to /etc/kernel/postinst.d/dkms being empty. Don't mark it as duplicate of bug 512096 because the error is not with one the installation script. [1] https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/512096 [2] https://wiki.ubuntu.com/DebuggingInstallationIssues#Exec%20format%20error -- Sincerely, - JB From siretart at ubuntu.com Tue Jan 26 22:02:52 2010 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 26 Jan 2010 23:02:52 +0100 Subject: [LONG] Re: "Exec format error" bugs In-Reply-To: <2770b9f71001260946p3b04258dhf8a35b20317c6e98@mail.gmail.com> (Jean-Baptiste Lallement's message of "Tue, 26 Jan 2010 18:46:07 +0100") References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> <87636za3pq.fsf@scenic.florian-diesch.de> <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> <4B55601E.9000204@ubuntu.com> <2770b9f71001260946p3b04258dhf8a35b20317c6e98@mail.gmail.com> Message-ID: <87aaw0plrn.fsf@faui44a.informatik.uni-erlangen.de> On Di, Jan 26, 2010 at 18:46:07 (CET), Jean-Baptiste Lallement wrote: > I reviewed around 50 of these reports and here is the result. > [...] Wow. Thank you for your analysis, your report is really impressive. The suggested approach to mark the bugs as duplicate for the master bug seems totally appropriate here! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From kamusin at gmail.com Wed Jan 27 15:06:27 2010 From: kamusin at gmail.com (Kamus) Date: Wed, 27 Jan 2010 12:06:27 -0300 Subject: Announcing the Next Ubuntu Hug Day! - Thursday 28 January 2010 Message-ID: Fellow Ubuntu Triagers! This week's Bug Day target is *drum roll please* ubuntuone-client! * 115 New bugs need a hug * 148 Incompletes bugs * 34 Confirmed bugs need a review Bookmark it, add it to your calendars, turn over those egg-timers!   * Thursday 28 January 2010   * https://wiki.ubuntu.com/UbuntuBugDay/20100128 Are you looking for a way to start giving some love back to your adorable Ubuntu Project? Did you ever wonder what Triage is? Want to learn about that? This is a perfect time!, Everybody can help in a Bug Day! Open your IRC Client and go to #ubuntu-bugs (FreeNode) the BugSquad will be happy to help you to start contributing! Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! We are always looking for new tasks or ideas for the Bug Days, if you have one add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning If you're new to all this (like me!) and you want to know more about ubuntu?, head to http://wiki.ubuntu.com/Bugs Have a nice day,    Kamus  [From the BugSquad] -- Victor Vargas B. Latitud: -33.439177,-70.625267 Santiago, Chile. From mrand at pobox.com Thu Jan 28 14:35:44 2010 From: mrand at pobox.com (Marc Randolph) Date: Thu, 28 Jan 2010 08:35:44 -0600 Subject: Fwd: Ground Control released: Launchpad for your desktop In-Reply-To: References: <4B619035.10004@ubuntu.com> Message-ID: ---------- Forwarded message ---------- From: Fabian Rodriguez Date: Thu, Jan 28, 2010 at 7:25 AM Subject: Ground Control released: Launchpad for your desktop To: "Ubuntu local community team (LoCo) contacts" Hi all, Ground Control has been released today. I'll refer you to the announcement at: http://doctormo.wordpress.com/2010/01/27/ground-control-demonstration I spent some time in a few sessions with Doctor MO (Martin Owens) at the last UDS and no doubt this should be an exciting development. "Ground control is a project that hopes to bring the collaboration of Launchpad and Bazaar branches to every day users abilities. It does away with the need for a command line and has removed a lot of the complex distractions leaving a simplified workflow for users to follow. It uses all the existing libraries and practices of the community, so if you need to move back to the command line you can continue were you left off. It’s also flexible enough to allow you to manage your existing bazaar checkouts via nautilus. If your want to." I encourage all loco team contacts to translate the original announcement and circulate it around your team members. There is also a video which I believe shows why this is important. But don't take my word for it, take a look: http://blip.tv/file/3141629 Cheers, Fabian Rodriguez Ubuntu Quebec LoCo Team -- loco-contacts mailing list loco-contacts at lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/loco-contacts From ryanprior at gmail.com Thu Jan 28 15:11:29 2010 From: ryanprior at gmail.com (Ryan Prior) Date: Thu, 28 Jan 2010 09:11:29 -0600 Subject: Ground Control released: Launchpad for your desktop In-Reply-To: References: <4B619035.10004@ubuntu.com> Message-ID: <1172c9071001280711i37afd79jb59a92c9585df859@mail.gmail.com> > "Ground control is a project that hopes to bring the collaboration of > Launchpad and Bazaar branches to every day users abilities. It does away > with the need for a command line and has removed a lot of the complex > distractions leaving a simplified workflow for users to follow. It uses > all the existing libraries and practices of the community, so if you > need to move back to the command line you can continue were you left off. > > It’s also flexible enough to allow you to manage your existing bazaar > checkouts via nautilus. If your want to." Thank you for your announcement, Fabian! Here's an English translation: Ground Control is a project aiming to bring Launchpad and Bazaar branch collaboration to more users. It eliminates the need for the command line from many tasks, which will provide for some a simpler and less distracting work flow. Ground Control uses existing code and best practices to allow easy transition between tools. Among the optional features of Ground Control is bzr checkout via Nautilus. But don't take my word for it: take a look at http://blip.tv/file/3141629 ! Yours, Ryan From raphael at ouaza.com Wed Jan 27 08:15:52 2010 From: raphael at ouaza.com (Raphael Hertzog) Date: Wed, 27 Jan 2010 09:15:52 +0100 Subject: [LONG] Re: "Exec format error" bugs In-Reply-To: <2770b9f71001260946p3b04258dhf8a35b20317c6e98@mail.gmail.com> References: <87eiloexkw.fsf@faui44a.informatik.uni-erlangen.de> <87636za3pq.fsf@scenic.florian-diesch.de> <871vhmtwxk.fsf@faui44a.informatik.uni-erlangen.de> <4B55601E.9000204@ubuntu.com> <2770b9f71001260946p3b04258dhf8a35b20317c6e98@mail.gmail.com> Message-ID: <20100127081552.GF22322@rivendell> Package: dpkg Version: 1.15.5.6 Severity: important [ For debian-dpkg, see https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/512096 for a description of the problem, basically a configuration script is empty /broken due to data loss and the recovery needs manual intervention ] Le mardi 26 janvier 2010, Jean-Baptiste Lallement a écrit : > What could be done ? Some suggestions: > - package manager : try to unpack the archive again in order to > overwrite the faulty files, if it's not found fetch then unpack the > archive, and try performing the requested operation again. If that > fails, then really cancel the installation. But the package manager > need to know it's an "exec format error" and that's not easy due to > the comments above. Another option could be to ask to the user if he > wants to try the workaround. > - dpkg : add a 'force' option to 'vanish' the package if the removal > script fails during a removal and/or configuration purging ( with a > BIG RED warning that it can seriously damage the user's installation) > instead of running abort-remove or leaving the package half-installed. > But I don't know the dpkg internals to know if it's a valid option. I would suggest that dpkg detects the error and brings back the package state to half-installed forcing the package manager to unpack it again. It seems to me that the error code ENOEXEC is sufficiently specific (and it could be associated to a check of the file length if needed) for this to be reasonable. BTW, I think it would have been wise to include the upstream dpkg maintainers in the discussion from the start, you're lucky that I'm following ubuntu-devel... We would also be glad if some people could volunteer to triage dpkg bugs on launchpad and make sure we have everything filed in the Debian BTS. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com From komputes at gmail.com Fri Jan 29 02:12:48 2010 From: komputes at gmail.com (komputes) Date: Thu, 28 Jan 2010 21:12:48 -0500 Subject: Ground Control released: Launchpad for your desktop In-Reply-To: <1172c9071001280711i37afd79jb59a92c9585df859@mail.gmail.com> References: <4B619035.10004@ubuntu.com> <1172c9071001280711i37afd79jb59a92c9585df859@mail.gmail.com> Message-ID: <4B624420.10104@gmail.com> Ryan Prior wrote: >> "Ground control is a project that hopes to bring the collaboration of >> Launchpad and Bazaar branches to every day users abilities. It does away >> with the need for a command line and has removed a lot of the complex >> distractions leaving a simplified workflow for users to follow. It uses >> all the existing libraries and practices of the community, so if you >> need to move back to the command line you can continue were you left off. >> >> It’s also flexible enough to allow you to manage your existing bazaar >> checkouts via nautilus. If your want to." >> > > Thank you for your announcement, Fabian! > > Here's an English translation: > > Ground Control is a project aiming to bring Launchpad and Bazaar > branch collaboration to more users. It eliminates the need for the > command line from many tasks, which will provide for some a simpler > and less distracting work flow. Ground Control uses existing code and > best practices to allow easy transition between tools. Among the > optional features of Ground Control is bzr checkout via Nautilus. But > don't take my word for it: take a look at http://blip.tv/file/3141629 > ! > > > Yours, > Ryan > > Looks awesome for developers and doc contributors. Now I wish we had an offline LP bug client... Project idea "Offline Bug Holder" described here: https://wiki.ubuntu.com/komputes/Projects -komputes (]( -. .- )[) From joshua.hoover at canonical.com Fri Jan 29 16:40:45 2010 From: joshua.hoover at canonical.com (Joshua Hoover) Date: Fri, 29 Jan 2010 10:40:45 -0600 Subject: Thank you! Message-ID: <4B630F8D.1080008@canonical.com> Yesterday was the first time the Ubuntu One team has had a package that was a target of a HugDay and it was a great experience. Thank you to all who helped us put this together and to all who triaged bugs with us! Joshua Hoover From jeremy.foshee at canonical.com Fri Jan 29 17:18:37 2010 From: jeremy.foshee at canonical.com (Jeremy Foshee) Date: Fri, 29 Jan 2010 09:18:37 -0800 Subject: Kernel Bug Day - Tues 2 Feb, 2010 Postponed Message-ID: <1264785517.2231.4.camel@jfo-lappy> Hi All, We will be postponing the Kernel Bug Day originally scheduled for Tuesday the 2nd of February until after the Platform Sprint occurring next week. I will send out an e-mail announcing the next Bug Day as soon as we have set the date. Thanks, JFo From adriangoodyer at gmail.com Sat Jan 30 20:05:11 2010 From: adriangoodyer at gmail.com (AdeGoodyer) Date: Sat, 30 Jan 2010 20:05:11 -0000 Subject: Help!? Message-ID: <20100130200511.19326.55543.launchpad@soybean.canonical.com> Hi, I'm new to triaging and having particular difficulty with the following bug. Would it be possible for someone to please have a look at it and correct me, as I'm not sure I am taking the correct action. https://bugs.launchpad.net/ubuntu/+source/kubuntu-kde4-meta/+bug/510138 Firstly, I'm not sure if the user is running ubuntu or kubuntu and when I try to get them to run apport to find out, that fails. If they are running kubuntu do we even deal with their bugs? Secondly, Ive found a package to place the bug in but have also had a browse on google and found what I thought was a separate launchpad for kubuntu bugs? So in short I guess I need to know the following things; - Is this a kubuntu bug? If so do we deal with them and if yes, then what package do I assign it too. - Is apport not working because of an error above? If not and I've done everything right then why isn't apport working and how to I go about making it work. I'm guessing I'm just being ridiculous and am just missing something really simple but I am aware I am representing ubuntu and in particularly the bugsquad so I need to know if I'm doing the right things and if I'm not then what I should be doing. Many thanks, everyone keep up the good work! Ade Goodyer -- This message was sent from Launchpad by the user AdeGoodyer (https://launchpad.net/~adriangoodyer) using the "Contact this team" link on the Ubuntu BugSquad team page. For more information see https://help.launchpad.net/YourAccount/ContactingPeople From yuriy-kozlov at kubuntu.org Sat Jan 30 21:23:25 2010 From: yuriy-kozlov at kubuntu.org (Yuriy Kozlov) Date: Sat, 30 Jan 2010 16:23:25 -0500 Subject: Help!? In-Reply-To: <20100130200511.19326.55543.launchpad@soybean.canonical.com> References: <20100130200511.19326.55543.launchpad@soybean.canonical.com> Message-ID: <714626161001301323r6a898855vc9676e1deb6b4b23@mail.gmail.com> On Sat, Jan 30, 2010 at 3:05 PM, AdeGoodyer wrote: > Hi, > > I'm new to triaging and having particular difficulty with the following > bug. Would it be possible for someone to please have a look at it and > correct me, as I'm not sure I am taking the correct action. > > https://bugs.launchpad.net/ubuntu/+source/kubuntu-kde4-meta/+bug/510138 > > Firstly, I'm not sure if the user is running ubuntu or kubuntu and when > I try to get them to run apport to find out, that fails. If they are > running kubuntu do we even deal with their bugs? Secondly, Ive found a > package to place the bug in but have also had a browse on google and > found what I thought was a separate launchpad for kubuntu bugs? > > So in short I guess I need to know the following things; > > - Is this a kubuntu bug? If so do we deal with them and if yes, then > what package do I assign it too. > > - Is apport not working because of an error above? If not and I've done > everything right then why isn't apport working and how to I go about > making it work. > > I'm guessing I'm just being ridiculous and am just missing something > really simple but I am aware I am representing ubuntu and in > particularly the bugsquad so I need to know if I'm doing the right > things and if I'm not then what I should be doing. Many thanks, everyone > keep up the good work! > > Ade Goodyer > -- > This message was sent from Launchpad by the user > AdeGoodyer (https://launchpad.net/~adriangoodyer) > using the "Contact this team" link on the Ubuntu BugSquad team page. > For more information see > https://help.launchpad.net/YourAccount/ContactingPeople > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > Hi Ade, Thanks for starting to help out. The user did say he is using Kubuntu. Kubuntu is just Ubuntu with some different packages installed, so there is nothing more apport would tell you with regard to that, and there is no separate bug tracker. The bug squad deals with bugs for all packages in Ubuntu. That includes KDE packages. However, like many development teams, the Kubuntu team has some of its own policies for dealing with bug reports: https://wiki.kubuntu.org/Kubuntu/Specs/LucidBugTriagePolicy Apport fails because the package assigned is wrong. kubuntu-kde4-meta only existed in Hardy (8.04) and the -meta package just defines a collection of packages, in this case the packages that are part of the KDE4 Remix CD released for 8.04. -meta packages do not contain any actual software, so they are very rarely the correct package to assign to. In this case, the correct package is either kdebase-runtime or kde4libs. I'm not sure what exactly handles screen brightness and power management at this point. ~ Yuriy From yuriy-kozlov at kubuntu.org Sat Jan 30 21:29:02 2010 From: yuriy-kozlov at kubuntu.org (Yuriy Kozlov) Date: Sat, 30 Jan 2010 16:29:02 -0500 Subject: Help!? In-Reply-To: <714626161001301323r6a898855vc9676e1deb6b4b23@mail.gmail.com> References: <20100130200511.19326.55543.launchpad@soybean.canonical.com> <714626161001301323r6a898855vc9676e1deb6b4b23@mail.gmail.com> Message-ID: <714626161001301329l50a262fcm71aa5f6b6356d84b@mail.gmail.com> > > Apport fails because the package assigned is wrong.  kubuntu-kde4-meta > only existed in Hardy (8.04) and the -meta package just defines a > collection of packages, in this case the packages that are part of the > KDE4 Remix CD released for 8.04.  -meta packages do not contain any > actual software, so they are very rarely the correct package to assign > to.  In this case, the correct package is either kdebase-runtime or > kde4libs.  I'm not sure what exactly handles screen brightness and > power management at this point. > > ~ Yuriy > That is, if it is indeed a KDE bug. It sounds like it could be lower down in the stack, especially if you read the link he gave with a workaround. Likely the correct package is actually linux (the kernel) or maybe hal. ~ Yuriy