Francesco Cosoleto (cosoleto at gmail.com) wrote at Fri Jun 12 15:48:13 UTC 2009:
Proper procedure should be this (for non-trivial changes or files created by you self, common-sense based):
- Post patch in mailing-list (I prefer here instead of using the stupid
patch tracker).
The patch tracker is for use by *all* developers. Patches should be posted there, regardless of what an individual prefers.
2009/6/13 Russell Blau russblau@imapmail.org:
Francesco Cosoleto (cosoleto at gmail.com) wrote at Fri Jun 12 15:48:13 UTC 2009:
Proper procedure should be this (for non-trivial changes or files created by you self, common-sense based):
- Post patch in mailing-list (I prefer here instead of using the stupid
patch tracker).
The patch tracker is for use by *all* developers. Patches should be posted there, regardless of what an individual prefers.
I'll have to agree here. If we think that the patch tracker is stupid. (we == if we _all_ think that...), then something ought to be done. But in the meantime, bypassing the tracker using the mailing-list is just not the correct way here.
Nicolas Dumazet ha scritto:
2009/6/13 Russell Blau russblau@imapmail.org:
[...]
- Post patch in mailing-list (I prefer here instead of using the stupid
patch tracker).
The patch tracker is for use by *all* developers. Patches should be posted there, regardless of what an individual prefers.
I'll have to agree here. If we think that the patch tracker is stupid. (we == if we _all_ think that...), then something ought to be done. But in the meantime, bypassing the tracker using the mailing-list is just not the correct way here.
Patch tracker (current one included) isn't useless, but it's a pain review there, and it doesn't provide a good visibility for the code.
So I think the non trivial code which is going to be included in SVN should be posted here instead. This involving who has SVN access at least.
It's a tested way and looks much better for me. Is this really a problem for you?
2009/6/14 Francesco Cosoleto cosoleto@gmail.com:
Patch tracker (current one included) isn't useless, but it's a pain review there, and it doesn't provide a good visibility for the code.
Agreed.
So I think the non trivial code which is going to be included in SVN should be posted here instead. This involving who has SVN access at least.
I love pull models, where people publish their changes, get review, re-publish the modified patches, and when the serie of patches is deemed perfect and only then, the serie is pulled to the central repository. I like this way of reviewing patches, because it allows to publish patches that are more meaningful. Commit history is more readable, and that's great for the community.
Even if we don't go so far, making sure that every pushed commit has at least been reviewed by another developer is a great step towards code quality.
BUT.
I think that this sort of model would not work for our small community. I myself often spend a complete week without entering my mail "pywikipedia" folder because I lack the time to, and it seems that other core developers (Merlijn, Russ, multichill, siebrand, filnik -- did I forget anyone?) similarly don't have much time. Wouldn't it be frustrating to have to wait weeks before getting reviews?
Honestly, I love those development models, but I think that it would be a burden for our _small_ community.
It's a tested way and looks much better for me. Is this really a problem for you?
Others might have different opinions, thought.
Nicolas Dumazet ha scritto: [...]
Wouldn't it be frustrating to have to wait weeks before getting reviews?
Honestly, I love those development models, but I think that it would be a burden for our _small_ community.
I don't think this procedure slows down the development process, the commiter can specify a number of days depending on patch complexity, past these days then he'll commit the code.
pywikipedia-l@lists.wikimedia.org