This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar.
"Dan Kegel" dank@kegel.com wrote:
This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar.
YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'.
I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he come back from his holiday as there are pile of patches awaiting him to review and commit.
Hongbo Ni
_________________________________________________________________ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589
On Sun, Aug 17, 2008 at 11:45 PM, Hongbo Ni hongbo_ni@hotmail.com wrote:
"Dan Kegel" > wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he come back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni
I don't believe that was Dan's intention when he referred to that document. Dan is saying that the overall format of the document is helpful, and we should write our own version of it that matches the Wine development process.
We can always use more help, but for the developers we do have, we're developing at a speedy pace. Also, Julliard hasn't had trouble scaling with the pace of development so far. We just need to write down this process in words in order to reduce the learning curve that keeps developers away from successful Wine development.
Am 18.08.2008 um 06:57 schrieb James Hawkins:
Also, Julliard hasn't had trouble scaling with the pace of development so far.
I'd be not so sure about this. So far I've filed four bugs and sent two patches. Bugs get little or no attention, patches obviously rushed through unnoticed.
Good thing is, with patchwatcher we have a tool for listing open patches now, allowing to monitor their status. At least I hope so.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Markus Hitter wrote:
Am 18.08.2008 um 06:57 schrieb James Hawkins:
Also, Julliard hasn't had trouble scaling with the pace of development so far.
I'd be not so sure about this. So far I've filed four bugs and sent two patches. Bugs get little or no attention, patches obviously rushed through unnoticed.
Bugs are NOT Alexandre's responsibility. There are other people doing the bugzilla triaging and those guys are always on a lookout for help. Even reviewing the patches is not only Alexandre's job. Everybody can and should do that but please try to be polite. For some parts of Wine Alexandre already relies on the "maintainers" of that code to bless the patch; wined3d is probably the most prominent example.
So yes, Alexandre scales pretty well with committing 100 patches a day. He doesn't scale at replying to trivially "wrong" patches but everybody can reply to those and actually they should do that.
Good thing is, with patchwatcher we have a tool for listing open patches now, allowing to monitor their status. At least I hope so.
That's the good part for the developers to see the trivial reasons why their patch was rejected. That will relieve Alexandre from repeating the same boring reasons why a patch was rejected.
bye michael
Am 18.08.2008 um 11:25 schrieb Michael Stefaniuc:
He [Alexandre] doesn't scale at replying to trivially "wrong" patches but everybody can reply to those and actually they should do that.
Unfortunately, a developer can't review his patches himself and if the patch reviewing group is to busy to even drop a line "formatted wrongly" or "functionality not needed" it's unlikely new developers will ever pick up working for Wine. For now I've stopped my work as I haven't even an idea wether my patches will be applied some day, wether they were considered obsolete (they're small) or wether they are considered as wrong in some way. Worsely, there's no obvious way to learn how to do better as I followed the patch sending HowTo closely already.
I'll try again in a few weeks, as suggested in the HowTo, and clutter Alexandre's mailbox even more.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
On Mon, Aug 18, 2008 at 7:40 AM, Markus Hitter mah@jump-ing.de wrote:
Am 18.08.2008 um 11:25 schrieb Michael Stefaniuc:
He [Alexandre] doesn't scale at replying to trivially "wrong" patches but everybody can reply to those and actually they should do that.
Unfortunately, a developer can't review his patches himself and if the patch reviewing group is to busy to even drop a line "formatted wrongly" or "functionality not needed" it's unlikely new developers will ever pick up working for Wine. For now I've stopped my work as I haven't even an idea wether my patches will be applied some day, wether they were considered obsolete (they're small) or wether they are considered as wrong in some way. Worsely, there's no obvious way to learn how to do better as I followed the patch sending HowTo closely already.
Why can't a developer review his own patch? If your patch is not committed, the first thing you should do is look the patch over for obvious mistakes. That is the main reason why a patch is dropped. If you've made sure you're patch is clean, then you can ask on wine-devel or IRC why your patch was rejected. It's your patch and it's your responsibility to put in the amount of work required to get it accepted. It's the same process for everyone.
Am 18.08.2008 um 19:53 schrieb James Hawkins:
Why can't a developer review his own patch? If your patch is not committed, the first thing you should do is look the patch over for obvious mistakes.
Obviously, some people here are used to receive more random diffs instead of carefully crafted patches. If there are obvious (to me) mistakes in a patch, I wouldn't even consider sending it.
then you can ask on wine-devel or IRC why your patch was rejected.
... or not even noticed. Thanks for the explanations, I'll take home "Wine developers don't care to be asked more than once". Thanks to Michael for reviewing my lines.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
On Mon, Aug 18, 2008 at 5:31 PM, Markus Hitter mah@jump-ing.de wrote:
Am 18.08.2008 um 19:53 schrieb James Hawkins:
Why can't a developer review his own patch? If your patch is not committed, the first thing you should do is look the patch over for obvious mistakes.
Obviously, some people here are used to receive more random diffs instead of carefully crafted patches. If there are obvious (to me) mistakes in a patch, I wouldn't even consider sending it.
Of course you wouldn't, but then when the patch doesn't get committed, you should look back at it and really think outside the box about what could possibly be wrong with the patch. I'm pretty sure there are very few developers, if any, who send in a patch knowing it's wrong and expect it to get committed.
then you can ask on wine-devel or IRC why your patch was rejected.
... or not even noticed. Thanks for the explanations, I'll take home "Wine developers don't care to be asked more than once". Thanks to Michael for reviewing my lines.
You assume it wasn't noticed. I can guarantee that's not the case. Give Alexandre a bit more credit than that. I'm not really sure what you're trying to get at with "developers don't like to be asked more than once" or where you even got that. It is the responsibility of no one else but yourself to make sure a patch gets committed. If you don't want to make take those extra steps to make that happen, don't complain to us that the process is at fault. We all have patches that seem to disappear in the cracks, but then we make that extra effort and either figure out what is wrong with it on our own, or ask the community or Alexandre what the problem is.
Am 19.08.2008 um 00:41 schrieb James Hawkins:
when the patch doesn't get committed, you should look back at it and really think outside the box about what could possibly be wrong with the patch.
Essentially, you ask to change code on unfounded guesses (I did the best to my knowledge in the first place already) and to commit into a black hole until some unknown, not communicating person is satisfied to her/his taste.
You assume it wasn't noticed. I can guarantee that's not the case.
So, what did the reviewing person then? Sitting there smiling "Heh, look, he could have done better, but, ha-ha, I won't tell him"? I hope this wasn't the case.
Give Alexandre a bit more credit than that.
I'm fine with Alexandre personally but not so sure about Wine's current patch receiving process.
That said I'm perfectly fine if Wine people consider this process as being effective. There's no law enforcing Wine to accept what I've sent.
[...] or ask the community or Alexandre what the problem is.
Correct. Communication is a plus.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
2008/8/19 Markus Hitter mah@jump-ing.de:
Am 19.08.2008 um 00:41 schrieb James Hawkins:
when the patch doesn't get committed, you should look back at it and really think outside the box about what could possibly be wrong with the patch.
Essentially, you ask to change code on unfounded guesses (I did the best to my knowledge in the first place already) and to commit into a black hole until some unknown, not communicating person is satisfied to her/his taste.
I agree to a point. There are certain things you can check (e.g. do the tests pass on Wine) that usually block a patch.
Other things it can be difficult to spot. Especially if you are not used to the coding conventions, or Windows idiosyncracies.
You assume it wasn't noticed. I can guarantee that's not the case.
So, what did the reviewing person then? Sitting there smiling "Heh, look, he could have done better, but, ha-ha, I won't tell him"? I hope this wasn't the case.
This is why it is important to keep track of the patches you have sent.
Give Alexandre a bit more credit than that.
I'm fine with Alexandre personally but not so sure about Wine's current patch receiving process.
That said I'm perfectly fine if Wine people consider this process as being effective. There's no law enforcing Wine to accept what I've sent.
I think Alexandre does a fantastic job.
[...] or ask the community or Alexandre what the problem is.
Correct. Communication is a plus.
Which is why it is important to ask why your patches have not been committed. Whenever I have asked, I have got a good response.
I have found that this is easier to do on the IRC, but like with everything it requires time and commitment.
- Reece
-
Dan Kegel -
Hongbo Ni -
James Hawkins -
Markus Hitter -
Michael Stefaniuc -
Reece Dunn