I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
This is a good idea, same idea as Gentoo Bug Days, and those have been extremely successful.
On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock adam@nemesys.ca wrote:
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
This is a good idea, same idea as Gentoo Bug Days, and those have been extremely successful.
Awesome, I think it could be really successful with wine too.
James Hawkins wrote:
On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock adam@nemesys.ca wrote:
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
This is a good idea, same idea as Gentoo Bug Days, and those have been extremely successful.
Awesome, I think it could be really successful with wine too.
This is a good idea but how do we decide which bug(s) to fix... Here is what I think.
- The program that the bug involves has to be available to anyone. at least for the first sessions (Search for keyword download in bugzilla reveals 146 candidates) http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&a...
- Older bugs bugs should be fixed first.
- More Popular programs should be take higher priority
--
Tony Lambregts
On Tue, 30 Nov 2004 23:23:46 -0700, tony_lambregts@telusplanet.net tony_lambregts@telusplanet.net wrote:
James Hawkins wrote:
On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock adam@nemesys.ca wrote:
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
This is a good idea, same idea as Gentoo Bug Days, and those have been extremely successful.
Awesome, I think it could be really successful with wine too.
This is a good idea but how do we decide which bug(s) to fix... Here is what I think.
- The program that the bug involves has to be available to anyone. at least for
the first sessions (Search for keyword download in bugzilla reveals 146 candidates) http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&a...
Older bugs bugs should be fixed first.
More Popular programs should be take higher priority
--
Tony Lambregts
I agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though.
On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote:
agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though.
Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs:
I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.
Mike Hearn wrote:
On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote:
agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though.
Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs:
I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.
Maybe we can hack the regression tests too? Many of them bug me to no end, but I haven't got a clue how to fix most of them. (Not once have we had an all green run of winetest.exe.)
regards, Jakob
Mike Hearn wrote:
On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote:
agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though.
Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs:
I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.
There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insites into debugging wine.
That being said, I would agree that at least to some degree this should be a training execise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word BugBuster to keep track of candidates. Hopefully after several sesions we will have a list of fixed bugs that new developers can use as a reference.
-- Tony Lambregts
On Wed, 2004-12-01 at 09:24 -0700, tony_lambregts@telusplanet.net wrote:
There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insites into debugging wine.
Well, yes if you assume infinite manpower. We don't have that so I'd personally rather spend my time helping budding developers.
Debugging random apps users bring into a channel is just asking to be overwhelmed and anyway, I can't really justify the time to do that these days when I could be working on paying customers stuff. Whereas I can justify (to myself at any rate) getting new developers on board who will go on to write bugfixes themselves.
thanks -mike
Mike Hearn wrote:
On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote:
agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though.
Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs:
I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.
There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insites into debugging wine.
That being said, I would agree that at least to some degree this should be a training execise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word "BugBuster" in Bugzilla to keep track of candidates. Hopefully after several sesions we will have a list of fixed bugs that new developers can use as a reference.
-- Tony Lambregts
On Wed, 01 Dec 2004 14:54:59 +0000, Mike Hearn mh@codeweavers.com wrote:
On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote:
Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs:
I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.
I think this sounds like the best way for now. Anyone interested in joining should have in mind any bugs they would like to fix, and we will work on those bugs. Concerning the time of the events, I am living in Pennsylvania right now, 5 hours behind GMT (i think), but I am willing to work at whatever time is best for everyone. What time is best for everyone? Also is once a week too much or not enough? I can do this any day of the week including the weekend, but some might not want to work on the weekends. Let's get some ideas for times so we can bust some bugs :)
On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote:
What time is best for everyone? Also is once a week too much or not enough?
I think as long as both USians and Europeans can be awake at the same time, it should be that sort of time. So evening GMT. Before saying "let's do it once a week" it makes sense to just do it once and gauge interest. If there aren't really that many potential hackers wanting help then I'd be pretty demotivated quickly (as pointed out, I'm not so keen on just random untargetted bugfixing)
On Wed, 01 Dec 2004 17:04:49 +0000, Mike Hearn mh@codeweavers.com wrote:
On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote:
What time is best for everyone? Also is once a week too much or not enough?
I think as long as both USians and Europeans can be awake at the same time, it should be that sort of time. So evening GMT. Before saying "let's do it once a week" it makes sense to just do it once and gauge interest. If there aren't really that many potential hackers wanting help then I'd be pretty demotivated quickly (as pointed out, I'm not so keen on just random untargetted bugfixing)
So that the most potential developers will be able to join, let's have the session this Friday Dec. 3, 7pm GMT. Is that a good time for anyone interested or should we push it back a week? Also get the word out to anyone that possibly doesn't read this list but that you know would like to get started with developing wine. The more we have show up, the more future developers we can get on the project (plus more squashing power :)
On Wed, 1 Dec 2004 12:25:38 -0500, James Hawkins truiken@gmail.com wrote:
On Wed, 01 Dec 2004 17:04:49 +0000, Mike Hearn mh@codeweavers.com wrote:
On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote:
What time is best for everyone? Also is once a week too much or not enough?
I think as long as both USians and Europeans can be awake at the same time, it should be that sort of time. So evening GMT. Before saying "let's do it once a week" it makes sense to just do it once and gauge interest. If there aren't really that many potential hackers wanting help then I'd be pretty demotivated quickly (as pointed out, I'm not so keen on just random untargetted bugfixing)
So that the most potential developers will be able to join, let's have the session this Friday Dec. 3, 7pm GMT. Is that a good time for anyone interested or should we push it back a week? Also get the word out to anyone that possibly doesn't read this list but that you know would like to get started with developing wine. The more we have show up, the more future developers we can get on the project (plus more squashing power :)
-- James Hawkins
I forgot to mention that we'll meet on #winehackers on IRC. If you have any questions about logging on, let us know.
On Wed, 2004-12-01 at 12:27 -0500, James Hawkins wrote:
So that the most potential developers will be able to join, let's have the session this Friday Dec. 3, 7pm GMT. Is that a good time for
I think Sunday would be a better day of the week. Friday/Saturday nights people tend to go out on (I know I'll probably be out this Friday).
On Wed, 01 Dec 2004 17:42:26 +0000, Mike Hearn mh@codeweavers.com wrote:
On Wed, 2004-12-01 at 12:27 -0500, James Hawkins wrote:
So that the most potential developers will be able to join, let's have the session this Friday Dec. 3, 7pm GMT. Is that a good time for
I think Sunday would be a better day of the week. Friday/Saturday nights people tend to go out on (I know I'll probably be out this Friday).
haha you're right. I was hesitant about having it on the weekends, but if people would like Sunday better than Sunday it is. Same time of the day and place. This will give us more time to get the word out too.
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
Sounds like a great idea. I've been trying to get into Wine development, but haven't been able to get my foot firmly planted anywhere. The whole thing is just too complex. I'd gladly join a BB session, if only to get some insight into how things work.
Joel Konkle-Parker wrote:
James Hawkins wrote:
I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.
Sounds like a great idea. I've been trying to get into Wine development, but haven't been able to get my foot firmly planted anywhere. The whole thing is just too complex. I'd gladly join a BB session, if only to get some insight into how things work.
Great idea indeed. I find myself spending much more time reading the bug lists and not understanding how to get started than actually implementing stuff. But this might indeed change that.
Problem: we probably will have to deal with multiple time zones (.e.g. I am in Europe) :-).
Also, I am getting the strange feeling that the buglist is somewhat outdated :-). For example: almost all bugs are either NEW or UNCONFIRMED. Isn't that a bit odd?
Robert
Robert van Herk wrote:
Also, I am getting the strange feeling that the buglist is somewhat outdated :-). For example: almost all bugs are either NEW or UNCONFIRMED. Isn't that a bit odd?
It's just that way right now. The way Bugzilla was designed there is supposed to be a default person for each component. typically a bug would be "Assigned" to the owner of that component. The way we use Bugzilla does not work that way. There are a few times that a person will volunteer to take on a bug and Assign it to themselves. Right now we live with the fact that "New" means "Confirmed".
Once our copy of Bugzilla is CVS's I plan to fix this (and other things).
--
Tony Lambregts
-
Adam Babcock -
Jakob Eriksson -
James Hawkins -
Joel Konkle-Parker -
Mike Hearn -
Robert van Herk -
tony_lambregts＠telusplanet.net