Re: [gentoo-dev] Re: Gentoo Bugday
28.02.2013 01:30, Peter Stuge пишет: Tom Wijsman wrote: his sole two bugs Is there a rule in Gentoo that forbids a dev to fix a bug assigned to someone else? That would make absolutely no sense to me. Without primary contact to bug's assignee(personally, of, if bug is assigned to project - to member of this project) - no, it's not good. Exception - maintainer-needed@ bugs. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Gentoo Bugday
From now we are have and an event g+ page : https://plus.google.com/events/cnevit57nm91ulji4bj4vt7910s :) On Thu, Feb 28, 2013 at 1:33 PM, Sergey Popov pinkb...@gentoo.org wrote: 28.02.2013 01:30, Peter Stuge пишет: Tom Wijsman wrote: his sole two bugs Is there a rule in Gentoo that forbids a dev to fix a bug assigned to someone else? That would make absolutely no sense to me. Without primary contact to bug's assignee(personally, of, if bug is assigned to project - to member of this project) - no, it's not good. Exception - maintainer-needed@ bugs. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead
Re: [gentoo-dev] Re: Gentoo Bugday
On 2013.02.28 02:14, Pavlos Ratis wrote: @neddyseagoon: Yeah it would be great to have it back, I think the day should remain as is. Every first Saturday of every month. Thanks. [snip] Pavlos, https://forums.gentoo.org/viewtopic-t-952608.html Poke me the weekend before bugday and I'll do the forums announce. Eventually, it will be a habit. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgppEk_DtZefo.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Bugday
On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote: On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka kensing...@gentoo.org wrote: On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Hi, Thanks for your work, it will be great to see Bugday happening again. What about the old bugday webpage[1]? It seems a bit broken at the moment, but may be useful to get running again. Is the code available somewhere? Who has access to the login in the footer? antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group svnbugday:x:4005:gurligebis It is there, but only gurligebis has r/w. We should migrate it to git.o.g.o if possible (all the secrets should be in a separate infra-owned repo, basically.) I have no idea who has access to login. Best regards, Michael [1] http://bugday.gentoo.org/ I already sent a tarball with the code to Pavlos, let him decide if he wants to move it to git.overlays.g.o or replace it with something else Theo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Gentoo Bugday
Unfortunately I didn't have much time to 'refresh' the website. As Theo said, he gave me the code of the site but I think it would be great to have something new. If anyone wants to join, ping me on irc. We could create a new repo at our Github and start developing. Also if you want to add new ideas for the Bugday feel free to touch the wiki page. :) On Wed, Feb 27, 2013 at 12:19 PM, Theo Chatzimichos tampak...@gentoo.org wrote: On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote: On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka kensing...@gentoo.org wrote: On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Hi, Thanks for your work, it will be great to see Bugday happening again. What about the old bugday webpage[1]? It seems a bit broken at the moment, but may be useful to get running again. Is the code available somewhere? Who has access to the login in the footer? antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group svnbugday:x:4005:gurligebis It is there, but only gurligebis has r/w. We should migrate it to git.o.g.o if possible (all the secrets should be in a separate infra-owned repo, basically.) I have no idea who has access to login. Best regards, Michael [1] http://bugday.gentoo.org/ I already sent a tarball with the code to Pavlos, let him decide if he wants to move it to git.overlays.g.o or replace it with something else Theo
Re: [gentoo-dev] Re: Gentoo Bugday
Pavlos Ratis wrote: Unfortunately I didn't have much time to 'refresh' the website. As Theo said, he gave me the code of the site but I think it would be great to have something new. If anyone wants to join, ping me on irc. We could create a new repo at our Github and start developing. Don't start developing, plz work on bugs instead. //Peter
Re: [gentoo-dev] Re: Gentoo Bugday
On Wed, 27 Feb 2013 20:00:44 +0100 Peter Stuge pe...@stuge.se wrote: Pavlos Ratis wrote: Unfortunately I didn't have much time to 'refresh' the website. As Theo said, he gave me the code of the site but I think it would be great to have something new. If anyone wants to join, ping me on irc. We could create a new repo at our Github and start developing. Don't start developing, plz work on bugs instead. //Peter Then who will develop useful tools to handle bugs more efficiently? While we're at this topic; I could use a duplicate finder for bug wrangling to spare other devs from coming across the same bug again, also a build log parser that only show the relevant bits that matter so I don't have to waste time grepping for keywords that appear in file names as well, not to forget about compressed build logs, and for assigning bugs an integrated herds.xml lookup would be pretty useful... Using these tools I could process bugs in half the time; and those are mostly just tools on the bug wrangling side, the dev and ebuild side could also use some more tools. If nobody wrote tools, we wouldn't have Bugzilla, Mailing List Daemons and Portage; back in the old days... Also, your response is quite funny if you consider his sole two bugs are one low priority bug that's 3 years old and has been reassigned a few times because it's not worth fixing (aka not an actual problem), the other one is actually for a tool called recruiting.gentoo.org. I'd rather see this dev continue developing than wasting time on bugs, this reminds me that I should do some short term development myself instead of wasting a lot of time long term; even if I don't end up benefiting of the cost, any person that follows my footsteps will. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Bugday
Tom Wijsman wrote: We could create a new repo at our Github and start developing. Don't start developing, plz work on bugs instead. Then who will develop useful tools to handle bugs more efficiently? Don't get me wrong: I am not hating on useful tools! I am saying that working on tools is orthogonal to working on open bugs. his sole two bugs Is there a rule in Gentoo that forbids a dev to fix a bug assigned to someone else? That would make absolutely no sense to me. No wonder then, that there are several bugs with no activity for months after I have committed fixed ebuilds to my overlay and mentioned that in a comment. He has become a developer so why would he not be able to take neccessary action to close bugs, even if they haven't been assigned to him? - But Peter, you say, don't you see - that would lead to more fixed bugs! Orly? How is that bad? (I'm obviously assuming that all developers (but not infra) are equally competent, since that's the model taught by recruitment.) short term .. long term Yes, life is tradeoff. In my experience development of tools is rather a long term thing, while a day of working on bugs is more short term. A day short, to be exact. :) If there are numerous unactionable bugs then perhaps skip them on that day, and work on shiny bulk processing tools the next day. Just my 2. But never mind. I guess I'm not supposed to participate in the bugday anyway. Good for me! :) //Peter pgpqgcbNMgxO0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Bugday
On Wed, 27 Feb 2013 22:30:38 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: We could create a new repo at our Github and start developing. Don't start developing, plz work on bugs instead. Then who will develop useful tools to handle bugs more efficiently? Don't get me wrong: I am not hating on useful tools! That's not an answer to my question. I am saying that working on tools is orthogonal to working on open bugs. And I am saying that working on tools that help you work on open bugs is not orthogonal to fixing open bugs, it helps you fix them efficiently. his sole two bugs Is there a rule in Gentoo that forbids a dev to fix a bug assigned to someone else? That would make absolutely no sense to me. No wonder then, that there are several bugs with no activity for months after I have committed fixed ebuilds to my overlay and mentioned that in a comment. Yes, one shall not commit on packages other developers maintain without the permission to do such thing. But let's assume the horribly attaching a patch approach (save two files, compare them, bla...)... Can you write me a tool that shows these kinds of bugs, easily submit patches to them and follow up on whether the developer commits them or retires at one or another point? I don't do any of this for my bugs. I could state that working on bugs assigned to someone else is orthogonal to fixing your own bugs. He has become a developer so why would he not be able to take neccessary action to close bugs, even if they haven't been assigned to him? Because it isn't as simple as you make it seem like, as stated above. - But Peter, you say, don't you see - that would lead to more fixed bugs! Orly? How is that bad? Y u no serious? U mad? (I'm obviously assuming that all developers (but not infra) are equally competent, since that's the model taught by recruitment.) Competence is irrelevant to this discussion, competency is to be assumed. Though, since you want to discuss this; note that with the right tools incompetent developers can become more competent, instead of having no clue where to start they can efficiently start on something right away and finish it in a timely matter. short term .. long term Yes, life is tradeoff. In my experience development of tools is rather a long term thing, while a day of working on bugs is more short term. A day short, to be exact. :) What experience are you even talking about? Did you write a tool that handles upon bugs, build logs or something else that applies to the daily Gentoo Dev process? If there are numerous unactionable bugs then perhaps skip them on that day, and work on shiny bulk processing tools the next day. So, we need another tool to mark and bulk process unactionable bugs! Or at least plan and write the searches for our lovely Bugzilla to do so, oh, and also CC a ton of people with this madness while we're at it. Just my 2. But never mind. I guess I'm not supposed to participate in the bugday anyway. Good for me! :) It's only a day short. The other six days are free to work on tools... With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Bugday
Tom Wijsman wrote: I am saying that working on tools that help you work on open bugs is not orthogonal to fixing open bugs, it helps you fix them efficiently. Sure, but on the bugday itself it sounds on the name like the idea is to work on bugs with currently available tools, rather than work on tools to work on bugs .. some other time. Is there a rule in Gentoo that forbids a dev to fix a bug assigned to someone else? That would make absolutely no sense to me. No wonder then, that there are several bugs with no activity for months after I have committed fixed ebuilds to my overlay and mentioned that in a comment. Yes, one shall not commit on packages other developers maintain without the permission to do such thing. This is basically stupid. Anyway, commit is one thing, but fixing bugs can be done while still respecting that rule. I would however make this simple suggestion: On bugdays every bugfix [optionally for bugs inactive for x days] is fair game for every developer to commit. Those who feel threatened by other people touching their bits might pay more attention to bugs then. It would also promote more acceptance of other fixing their stuff. I know that several (many?) developers give blanket permission, and I think that's good, but I think it's really broken that they have to at all. Back to bugday.. But let's assume the horribly attaching a patch approach (save two files, compare them, bla...)... Yes, web apps are supremely inefficient shitty tools. I'm very happy to be able to simply refer to my overlay when I have fixed something. I do try to also attach fixed files, but I don't always manage. Can you write me a tool that shows these kinds of bugs, easily submit patches to them and follow up on whether the developer commits them or retires at one or another point? I don't do any of this for my bugs. Bugzilla implicitly does much of that for you already, if you tell it to send you email for all changes on bugs you have the raw data in email form, which may be easier to work with sans SQL access to the bugzilla database. That works really well for me to follow any bugs that I am interested in, and it's pretty easy to search in email and see what has happened when, and how much is still open (different folders). Submitting patches, no I think that's too broken on the web, and that something more powerful like an overlay could be used instead - at the very least for fixes from developers. I could state that working on bugs assigned to someone else is orthogonal to fixing your own bugs. Sure - but if all one's own bugs are low priority perhaps it's more useful on bugday to work on bugs assigned to someone else, if they aren't doing it themselves. He has become a developer so why would he not be able to take neccessary action to close bugs, even if they haven't been assigned to him? Because it isn't as simple as you make it seem like, as stated above. For several bugs that I have fixed, it is precisely that simple. Fixes have been ready for months and just need to be committed. I'd dare to call it outright trivial. They still aren't committed. Finding them easily? Well maybe a search query that orders by last activity weighted by severity, number of attachments and fulltext search for fixed would be a start? I guess that's easy to do even in bugzilla's web interface? - But Peter, you say, don't you see - that would lead to more fixed bugs! Orly? How is that bad? Y u no serious? U mad? Not mat, I am being serious - I guess that the uncommitted fixes mean lack of attention to bugs, which I completely understand. I further guess that the bugday is an initiative to attend to bugs. So any developer who wants to help could close bugs by comitting fixes from others, fixes that are already in bugzilla. I guess the few bugs that I have done this for are not unique in Gentoo's bugzilla, likely there are lots of other bugs just like mine, where users have contributed fixes for stuff that they have run into and it still hasn't gotten committed, nor reviewed. At least one of my bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :) (I'm obviously assuming that all developers (but not infra) are equally competent, since that's the model taught by recruitment.) Competence is irrelevant to this discussion, competency is to be assumed. I agree that it is to be assumed, but I think it is relevant because I believe that fear of incompetence is the reason why developers feel threatened by commits from others, so it supports the idea that at the very least on bugday it would be fine for everyone to commit everything. (Again, I am assuming that all fixes are correct.) Though, since you want to discuss this; note that with the right tools incompetent developers can become more competent, instead of having no clue where to start they can efficiently start on something right away and finish it in a timely matter.
Re: [gentoo-dev] Re: Gentoo Bugday
On Thu, 28 Feb 2013 01:20:01 +0100 Peter Stuge pe...@stuge.se wrote: Sure, but on the bugday itself it sounds on the name like the idea is to work on bugs with currently available tools, rather than work on tools to work on bugs .. some other time. Neither of us did suggest such thing. Yes, one shall not commit on packages other developers maintain without the permission to do such thing. This is basically stupid. But that's just the way it is, because random committing makes no sense. Anyway, commit is one thing, but fixing bugs can be done while still respecting that rule. I would however make this simple suggestion: On bugdays every bugfix [optionally for bugs inactive for x days] is fair game for every developer to commit. It works this way for packages (retirement, etc...), but for bugs this introduces the random committing effect; just because you keep one bug around for a package and fix all others doesn't mean someone else can suddenly come and take that bug, fix and apply it blindly. Those who feel threatened by other people touching their bits might pay more attention to bugs then. Again more easily said than done, time is limited; not every bug can be fixed, some require too much effort for what they are worth, ... It would also promote more acceptance of other fixing their stuff. I know that several (many?) developers give blanket permission, and I think that's good, but I think it's really broken that they have to at all. Back to bugday.. This model has been in place for years, it's not easily changed. But let's assume the horribly attaching a patch approach (save two files, compare them, bla...)... Yes, web apps are supremely inefficient shitty tools. I'm very happy to be able to simply refer to my overlay when I have fixed something. ... Submitting patches, no I think that's too broken on the web, and that something more powerful like an overlay could be used instead - at the very least for fixes from developers. That's just moving the extra effort to the person who receives your patch; who now has to obtain the overlay, sync the overlay, obtain the file from the overlay and diff that file against his local file to obtain the actual patch. And if it's not done in a timely manner, too much may have changed already which makes generating a clean patch hard and therefore will need them to spent time to figure out which code actually belongs to the patch. Overlays weren't meant for this... I do try to also attach fixed files, but I don't always manage. I do try to generate patches from overlays, but I don't always manage. Can you write me a tool that shows these kinds of bugs, easily submit patches to them and follow up on whether the developer commits them or retires at one or another point? I don't do any of this for my bugs. Bugzilla implicitly does much of that for you already, if you tell it to send you email for all changes on bugs you have the raw data in email form, which may be easier to work with sans SQL access to the bugzilla database. That works really well for me to follow any bugs that I am interested in, and it's pretty easy to search in email and see what has happened when, and how much is still open (different folders). How exactly does Bugzilla show these kinds of bugs? Submitting patches or using overlays, it makes no difference. Following the bug through mail exactly doesn't show retirement, unless you CC yourself on a ton of bugs and want to maintain these individual CCs into archive folders where you look up the oldest mails (because not every CC is one you want to archive), and you also have to consider that you don't get mails for changes you commit to the bug. Sum that up and it's not a reliable approach, unless you write a tool. I could state that working on bugs assigned to someone else is orthogonal to fixing your own bugs. Sure - but if all one's own bugs are low priority perhaps it's more useful on bugday to work on bugs assigned to someone else, if they aren't doing it themselves. Those bugs are often of equal priority, and I have nothing against that; I'm just stating that it's much harder to fix other people's bugs, this is due to the inefficiency that comes along, without tools being written to aid in this process it'll continue that way. He has become a developer so why would he not be able to take neccessary action to close bugs, even if they haven't been assigned to him? Because it isn't as simple as you make it seem like, as stated above. For several bugs that I have fixed, it is precisely that simple. Fixes have been ready for months and just need to be committed. I'd dare to call it outright trivial. They still aren't committed. just being the whole overlay process I outlined above? Not trivial. Finding them easily? Well maybe a search query that orders by last activity weighted by severity, number of attachments and fulltext search for fixed
Re: [gentoo-dev] Re: Gentoo Bugday
@neddyseagoon: Yeah it would be great to have it back, I think the day should remain as is. Every first Saturday of every month. Thanks. @TomWij and Peter: Well guys, I think you should not expand the topic so much, lets stay to the bugday. As I said in my first post, bugday's goal is to close as many bugs as possible and not to create new tools. We can create tools(small scripts) in the future that can help us before the bugday. But in the bugday as an event we should concentrate on closing bugs. On Thu, Feb 28, 2013 at 3:07 AM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 28 Feb 2013 01:20:01 +0100 Peter Stuge pe...@stuge.se wrote: Sure, but on the bugday itself it sounds on the name like the idea is to work on bugs with currently available tools, rather than work on tools to work on bugs .. some other time. Neither of us did suggest such thing. Yes, one shall not commit on packages other developers maintain without the permission to do such thing. This is basically stupid. But that's just the way it is, because random committing makes no sense. Anyway, commit is one thing, but fixing bugs can be done while still respecting that rule. I would however make this simple suggestion: On bugdays every bugfix [optionally for bugs inactive for x days] is fair game for every developer to commit. It works this way for packages (retirement, etc...), but for bugs this introduces the random committing effect; just because you keep one bug around for a package and fix all others doesn't mean someone else can suddenly come and take that bug, fix and apply it blindly. Those who feel threatened by other people touching their bits might pay more attention to bugs then. Again more easily said than done, time is limited; not every bug can be fixed, some require too much effort for what they are worth, ... It would also promote more acceptance of other fixing their stuff. I know that several (many?) developers give blanket permission, and I think that's good, but I think it's really broken that they have to at all. Back to bugday.. This model has been in place for years, it's not easily changed. But let's assume the horribly attaching a patch approach (save two files, compare them, bla...)... Yes, web apps are supremely inefficient shitty tools. I'm very happy to be able to simply refer to my overlay when I have fixed something. ... Submitting patches, no I think that's too broken on the web, and that something more powerful like an overlay could be used instead - at the very least for fixes from developers. That's just moving the extra effort to the person who receives your patch; who now has to obtain the overlay, sync the overlay, obtain the file from the overlay and diff that file against his local file to obtain the actual patch. And if it's not done in a timely manner, too much may have changed already which makes generating a clean patch hard and therefore will need them to spent time to figure out which code actually belongs to the patch. Overlays weren't meant for this... I do try to also attach fixed files, but I don't always manage. I do try to generate patches from overlays, but I don't always manage. Can you write me a tool that shows these kinds of bugs, easily submit patches to them and follow up on whether the developer commits them or retires at one or another point? I don't do any of this for my bugs. Bugzilla implicitly does much of that for you already, if you tell it to send you email for all changes on bugs you have the raw data in email form, which may be easier to work with sans SQL access to the bugzilla database. That works really well for me to follow any bugs that I am interested in, and it's pretty easy to search in email and see what has happened when, and how much is still open (different folders). How exactly does Bugzilla show these kinds of bugs? Submitting patches or using overlays, it makes no difference. Following the bug through mail exactly doesn't show retirement, unless you CC yourself on a ton of bugs and want to maintain these individual CCs into archive folders where you look up the oldest mails (because not every CC is one you want to archive), and you also have to consider that you don't get mails for changes you commit to the bug. Sum that up and it's not a reliable approach, unless you write a tool. I could state that working on bugs assigned to someone else is orthogonal to fixing your own bugs. Sure - but if all one's own bugs are low priority perhaps it's more useful on bugday to work on bugs assigned to someone else, if they aren't doing it themselves. Those bugs are often of equal priority, and I have nothing against that; I'm just stating that it's much harder to fix other people's bugs, this is due to the inefficiency that comes along, without tools being written to aid in this process it'll continue that way. He has become a developer so why would he not
[gentoo-dev] Re: Gentoo Bugday
On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Hi, Thanks for your work, it will be great to see Bugday happening again. What about the old bugday webpage[1]? It seems a bit broken at the moment, but may be useful to get running again. Is the code available somewhere? Who has access to the login in the footer? Best regards, Michael [1] http://bugday.gentoo.org/
Re: [gentoo-dev] Re: Gentoo Bugday
On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka kensing...@gentoo.org wrote: On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Hi, Thanks for your work, it will be great to see Bugday happening again. What about the old bugday webpage[1]? It seems a bit broken at the moment, but may be useful to get running again. Is the code available somewhere? Who has access to the login in the footer? antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group svnbugday:x:4005:gurligebis It is there, but only gurligebis has r/w. We should migrate it to git.o.g.o if possible (all the secrets should be in a separate infra-owned repo, basically.) I have no idea who has access to login. Best regards, Michael [1] http://bugday.gentoo.org/
