Bugs, usertags, and including more people
Hi! One of the things that I proposed in my talk during Debconf5 is to have a friendlier bug interface that allows for bugs to be sorted on the language (c, python, perl, etc) of the code, and the difficulty of solving them (trivial, easy, interesting, tedious, difficult guru-level). The main idea is that I'd like to set up a nifty page that shows the bugs submitted during the last week, or something like that, and allows anyone to browse through them in the search of a bug that they can fix and send a patch for. The final goal of this idea is to get more people involved in helping in Debian. i.e. the main target for this are non-maintainers, but of course it would be open for anyone. Now, Anthony Towns is about to implement some nice changes into the BTS which include the birth of "usertags". These usertags are a way in which _anyone_ can set their _own_ tags, so as to browse through bugs more easily, with their own criteria. Usertags won't be seen by anybody, they'll only be seen if you select the correct "user" (users will actually be _domains_, as in marga.com.ar, qa.debian.org, etc.). Now, I'd like to implement my bug filtering idea through these usertags. I can use my own domain (like marga.com.ar), but since the usertags that I want to apply won't be only for me, and the idea is to make anyone have an easier way of finding what to fix, I'd like these particular usertags to be associated with qa.debian.org Would that be ok? The tags that I've thought of are the ones I mentioned before. But maybe someone else can think of some other tags that will also increase the chances of some helpful non-DD finding a bug, fixing it and sending a patch. -- Besos, Marga
Re: Bugs, usertags, and including more people
Margarita Manterola wrote: > One of the things that I proposed in my talk during Debconf5 is to > have a friendlier bug interface that allows for bugs to be sorted on > the language (c, python, perl, etc) of the code, and the difficulty of > solving them (trivial, easy, interesting, tedious, difficult > guru-level). debtags already tags many packages WRT langugage, so couldn't that be used for the language side of things to avoid duplicating work? -- see shy jo signature.asc Description: Digital signature
Re: Bugs, usertags, and including more people
On 8/3/05, Joey Hess <[EMAIL PROTECTED]> wrote: > Margarita Manterola wrote: > > One of the things that I proposed in my talk during Debconf5 is to > > have a friendlier bug interface that allows for bugs to be sorted on > > the language (c, python, perl, etc) of the code, and the difficulty of > > solving them (trivial, easy, interesting, tedious, difficult > > guru-level). > > debtags already tags many packages WRT langugage, so couldn't that be > used for the language side of things to avoid duplicating work? Well, I thought of this, yes. But there are times when a program uses more than one language. For example, Oregano (an electronics program that I help maintain) is coded in C, uses a lot of GTK, but also has some perl scripts... So, if a bug occured in a perl script, it would show up as a C+GTK bug, which it is not... In any case, it _would_ be nice to make use of the debtags, since in most cases the language tag would be appropiate, I just haven't figured out how to do both. -- Besos, Marga
Re: Bugs, usertags, and including more people
On Wed, Aug 03, 2005 at 01:15:13PM -0400, Joey Hess wrote: > Margarita Manterola wrote: > > One of the things that I proposed in my talk during Debconf5 is to > > have a friendlier bug interface that allows for bugs to be sorted on > > the language (c, python, perl, etc) of the code, and the difficulty of > > solving them (trivial, easy, interesting, tedious, difficult > > guru-level). > > debtags already tags many packages WRT langugage, so couldn't that be > used for the language side of things to avoid duplicating work? Right; I was going to say the same thing. Plus, its not a per-bug property, but a per-package property (usually, as noted). There are 3 related bugs; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111068 The suggestion is for per-package, "unintentional" tags. debtags tags intentional things like "science::astronomy, purpose::viewing, format::fits" or whatever, but the suggested use of tags mentioned in that bug are to report problems, so it is independent from debtags. I like the idea of per-package unintentional tags, like "orphaned, or new-upstream". Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs, usertags, and including more people
On Wed, 2005-08-03 at 13:15 -0400, Joey Hess wrote: > Margarita Manterola wrote: > > One of the things that I proposed in my talk during Debconf5 is to > > have a friendlier bug interface that allows for bugs to be sorted on > > the language (c, python, perl, etc) of the code, and the difficulty of > > solving them (trivial, easy, interesting, tedious, difficult > > guru-level). > > debtags already tags many packages WRT langugage, so couldn't that be > used for the language side of things to avoid duplicating work? Yes, the "made-of::lang"[0] facet from debtags can be used where needed. It will just require package tagging (under heavy progress) and a debbugs patch, still not considered. The difficulty of solving a bug can't be tracked so easily. What's hard to me will be easy for others and sometimes it's a moving target. I feel comfortable with wontfix, moreinfo, unreproducible, pending and some others tags only. These aren't a drop-in replacement but works, imo. [0] = `debtags tagsearch made-of::lang` to see the current vocabulary Best regards, Gustavo Franco -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs, usertags, and including more people
On Wed, 2005-08-03 at 14:35 -0300, Margarita Manterola wrote: > On 8/3/05, Joey Hess <[EMAIL PROTECTED]> wrote: > > Margarita Manterola wrote: > > > One of the things that I proposed in my talk during Debconf5 is to > > > have a friendlier bug interface that allows for bugs to be sorted on > > > the language (c, python, perl, etc) of the code, and the difficulty of > > > solving them (trivial, easy, interesting, tedious, difficult > > > guru-level). > > > > debtags already tags many packages WRT langugage, so couldn't that be > > used for the language side of things to avoid duplicating work? > > Well, I thought of this, yes. But there are times when a program uses > more than one language. For example, Oregano (an electronics program > that I help maintain) is coded in C, uses a lot of GTK, but also has > some perl scripts... So, if a bug occured in a perl script, it would > show up as a C+GTK bug, which it is not... > > In any case, it _would_ be nice to make use of the debtags, since in > most cases the language tag would be appropiate, I just haven't > figured out how to do both. Nice example of a corner case but what are these perl scripts doing ? It's mainly a gtk+ program - as it's already tagged, but lacks made-of::lang:c atm. If you think about it more deeper, what if a random package contain a buggy postinst, prerm, ... but the software itself is written in language x ? The tag won't be useful to prepare a report containing "language x bugs", but "bugs into packages made of language x" imo. Cheers, Gustavo Franco -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs, usertags, and including more people
On Wed, 2005-08-03 at 13:50 -0300, Margarita Manterola wrote: > Hi! > > One of the things that I proposed in my talk during Debconf5 is to > have a friendlier bug interface that allows for bugs to be sorted on > the language (c, python, perl, etc) of the code, and the difficulty of > solving them (trivial, easy, interesting, tedious, difficult > guru-level). > > The main idea is that I'd like to set up a nifty page that shows the > bugs submitted during the last week, or something like that, and > allows anyone to browse through them in the search of a bug that they > can fix and send a patch for. > > The final goal of this idea is to get more people involved in helping > in Debian. i.e. the main target for this are non-maintainers, but of > course it would be open for anyone. > > (...) Hi Margarita, It seems that you're trying to prepare a team like gnome bugsquad[0]. I don't have enough time to help atm and i don't know if there's another initiative like this into the project, starting right now. I recommend you write something like the 'triage guide' and with ajt help and maybe others simplify the BTS interface for "bugsquad" team work. Some "saved searches", usertags or whatever will be the name of this debbugs feature, that i think will be useful for this team if used together with the "today, yesterday, this week, this month" bugs: - too old (x days) already patched, pending and l18n bugs Code to check when the X tag was added will be required. - release critical bugs any RC bug - etch release critical bugs only etch considered RC bugs If you go further and add a "claim" interface with a default expire for a week or two ( to avoid a person claiming a bug and the others start ignoring it for too much time ), it'll be even useful for BSP's and RM team, imo. [0] = http://developer.gnome.org/projects/bugsquad/ -- Gustavo Franco -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs, usertags, and including more people
On 8/3/05, Gustavo Franco <[EMAIL PROTECTED]> wrote: > The difficulty of solving a bug can't be tracked so easily. What's hard > to me will be easy for others and sometimes it's a moving target. Indeed. It's not like tagging a bug 'easy' would be written in stone. Someone may read the bug report and think that finding the problem is easy. Maybe, after further investigation from someone actually trying to solve the bug, it might be discovered that it was actually quite hard, then the tag could be changed. Many times it's possible to assess how hard or how difficult it is to fix a bug, specially for the maintainer of a package. Maybe we could a "need to investigate" level as well. > I feel comfortable with wontfix, moreinfo, unreproducible, pending and some > others tags only. These aren't a drop-in replacement but works, imo. No, this is not the idea, and it won't work as what I want to do. I want to create a new sort of listing that makes bugs that need fixing appealing, for people that are not maintainers, so that they will contribute with patches. The current tags do not serve this purpose. If you are comfortable with the current tags, that's great, because they aren't changing. The usertags are a way for tagging bugs without intruding into the maintainer's way of handling bugs. In this particular case, it's a way of categorizing bugs from the random contributor point of view, which isn't usually the same as the maintainer's point of view. -- Besos, Marga
Re: Bugs, usertags, and including more people
> > Well, I thought of this, yes. But there are times when a program uses > > more than one language. For example, Oregano (an electronics program > > that I help maintain) is coded in C, uses a lot of GTK, but also has > > some perl scripts... So, if a bug occured in a perl script, it would > > show up as a C+GTK bug, which it is not... > Nice example of a corner case but what are these perl scripts doing ? Does it matter? The program uses them to convert from one simulator format to the other, or something like that. > It's mainly a gtk+ program - as it's already tagged, but lacks > made-of::lang:c atm. Well, yes, it's in my TODO list to correctly tag all of my packages. > If you think about it more deeper, what if a random package contain a > buggy postinst, prerm, ... but the software itself is written in > language x ? The tag won't be useful to prepare a report containing > "language x bugs", but "bugs into packages made of language x" imo. Yes, indeed. That's why I don't want to rely _only_ on debtags. There could be a lang-pkg-debian, or similar, because that's the skill needed, even if the script is written in bash, you need to know more than how to use the shell to do a correct postinst script. Or maybe, we could make the language tag be bash, and have another subgroup of tags named "skill" which might include things like ui, pkg-debian, complex maths, etc... It might be nice to have that too, although it might also be more difficult to assess which skills are necessary. -- Besos, Marga
Re: Bugs, usertags, and including more people
On Wed, 2005-08-03 at 16:07 -0300, Margarita Manterola wrote: > > > Well, I thought of this, yes. But there are times when a program uses > > > more than one language. For example, Oregano (an electronics program > > > that I help maintain) is coded in C, uses a lot of GTK, but also has > > > some perl scripts... So, if a bug occured in a perl script, it would > > > show up as a C+GTK bug, which it is not... > > > Nice example of a corner case but what are these perl scripts doing ? > > Does it matter? The program uses them to convert from one simulator > format to the other, or something like that. It doesn't matter, i was just curious. > > It's mainly a gtk+ program - as it's already tagged, but lacks > > made-of::lang:c atm. > > Well, yes, it's in my TODO list to correctly tag all of my packages. No problem but i haven't looked into debtags latest tagdb, it's under heavy update and the merge work with packagebrowser[0] needs volunteers. > > If you think about it more deeper, what if a random package contain a > > buggy postinst, prerm, ... but the software itself is written in > > language x ? The tag won't be useful to prepare a report containing > > "language x bugs", but "bugs into packages made of language x" imo. > > Yes, indeed. That's why I don't want to rely _only_ on debtags. > There could be a lang-pkg-debian, or similar, because that's the skill > needed, even if the script is written in bash, you need to know more > than how to use the shell to do a correct postinst script. > > Or maybe, we could make the language tag be bash, and have another > subgroup of tags named "skill" which might include things like ui, > pkg-debian, complex maths, etc... It might be nice to have that too, > although it might also be more difficult to assess which skills are > necessary. Yes i believe that debtags isn't the answer exactly but can be useful (way better than display section in many packages). You're talking about something like usertags based on bugtags - i invented it now. bugtags aren't flexible as usertags and are closer to debtags but aren't per package itself, bugtags should be per bug. I think that usertags are much more like bugzilla "saved searches" and bugtags aren't, it'll need a vocabulary. If you want to merge usertags and bugtags idea, you'll see a generic tagging system when the user itself can attach any tag in a bug to show his BTS view to others, works well too. [0] = http://debian.vitavonni.de/packagebrowser/ Gustavo Franco -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Bug#320942: aspseek: FTBGS with gcc-4.0]
On Tue, Aug 02, 2005 at 04:34:13AM -0700, Steve Langasek wrote: > This makes three open RC bugs against aspseek, and one fixed in NMU. The > maintainer (who is not a DD and has no other packages) has never replied to > any of them, and the last upload was an NMU over two years ago for the > *last* C++ ABI transition. I think this package needs to be orphaned > immediately, and (if no one picks it up, as I expect will happen) removed > from the archive shortly thereafter. After repeated unkept promises, I put out an sort of ultimatum, that (again) was promised to be kept, but expired a bit over a month ago without any activity so far... Therefore, I'll orphan this package by the end of this week. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
C++ packages still compiled with gcc 2.95
I filed bugs against these packages. The first four appear to have been misbuilds by the maintainers. intel2gas queue robotour maelstrom (non-free) xmovie (contrib) However, xmovie seems to be severely undermaintained. Does anyone know David Martinez Moreno who can politely suggest that he either do something with it, orphan it, or remove it? -- A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: C++ packages still compiled with gcc 2.95
On Wed, Aug 03, 2005 at 08:59:02PM -0400, Nathanael Nerode wrote: > However, xmovie seems to be severely undermaintained. Does anyone know > David Martinez Moreno who can politely suggest that he either do something > with it, orphan it, or remove it? Man, you've stopped following -x so soon? :-) David has been working on the Xorg packages, so I'll forward this on to him. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
