Hi everyone,
I'm getting so freaking tired of these untested sloppy commits which keep breaking the bots.
alexsh@svn.wikimedia.org schreef:
Revision: 7591 Author: alexsh Date: 2009-11-04 13:22:17 +0000 (Wed, 04 Nov 2009)
Log Message:
- site().getUrl(): change all HTTP process to use urllib2.
- handle and combine Site Authentication, proxy handle and Proxy Authentication in the bottom.
Modified Paths:
trunk/pywikipedia/wikipedia.py
<knip>
-class MyURLopener(urllib.FancyURLopener):
- version="PythonWikipediaBot/1.0"/pywikipedia-svn
How the hell is upload.py supposed to work now?
Traceback (most recent call last): File "D:\Wikipedia\pywikipedia\flickrripper_wlanl.py", line 562, in <module> main() File "D:\Wikipedia\pywikipedia\flickrripper_wlanl.py", line 551, in main uploadedPhotos += processPhoto(flickr, photo_id, flickrreview, reviewer, ove rride, addCategory, removeCategories, autonomous) File "D:\Wikipedia\pywikipedia\flickrripper_wlanl.py", line 252, in processPho to bot.upload_image(debug=False) File "D:\Wikipedia\pywikipedia\upload.py", line 227, in upload_image self.read_file_content() File "D:\Wikipedia\pywikipedia\upload.py", line 108, in read_file_content uo = wikipedia.MyURLopener() AttributeError: OpenerDirector instance has no __call__ method
Please test your stuff decently before you commit it! About every time I do an svn update I have to get rid of dozens of bugs
Maarten
On Sun, Nov 15, 2009 at 7:47 AM, Maarten Dammers maarten@mdammers.nlwrote:
Please test your stuff decently before you commit it! About every time I do an svn update I have to get rid of dozens of bugs
Maarten
I agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability.
Thansk,
N.
On 2009-11-15 14:05, Nakor wrote:
On Sun, Nov 15, 2009 at 7:47 AM, Maarten Dammers <maarten@mdammers.nl mailto:maarten@mdammers.nl> wrote:
Please test your stuff decently before you commit it! About every time I do an svn update I have to get rid of dozens of bugs MaartenI agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability.
Thansk,
N.
Or a decent test suite?
Regards, Misza
Dnia 15.11.2009 Nakor nakor.wp@gmail.com napisał/a:
--===============2429419130569035772==
Please test your stuff decently before you commit it! About every time I do an svn update I have to get rid of dozens of bugs
Maarten
I agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability.
Maybe committer in question could comment on what (s)he is doing? It's not the first time. Branches are not necessary, one is free to experiment in his/her local archive.
We could of course switch to Mercurial if we really need per-developer branches.
Hello,
2009/11/16 Marcin Cieslak saper@saper.info:
Dnia 15.11.2009 Nakor nakor.wp@gmail.com napisał/a:
--===============2429419130569035772==
Please test your stuff decently before you commit it! About every time I do an svn update I have to get rid of dozens of bugs
Maarten
I agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability.
Maybe committer in question could comment on what (s)he is doing? It's not the first time. Branches are not necessary, one is free to experiment in his/her local archive.
The committer in question never comments on what he's doing.
We could of course switch to Mercurial if we really need per-developer branches.
I could not agree more here. Mercurial has a lot of very interesting features. However, if we adopt a "push-all" model, the kind of problems we're experimenting will not go away, as every committer will still be able to break the mainline when pushing his changes. Changing the tool alone does not fix bad development habits.
The only way to ensure stability IMHO is to introduce a strict review process, where a changeset has to be reviewed by a qualified developer other than the submitter before making it into the main development branch. It appears to slow down the process at first, because it introduces a delay in the commit workflow, but in the end code quality significantly improves, and this reduces maintenance costs.
Being now used to the Mercurial community, where each patch is sent to the dev- mailing list before being pulled by the relevant maintainer, I would love to see those practices here. If the community was interested to do the switch, I would be willing to spend a significant part of my time to review patches, and/or give assistance in Mercurial usage. I think that a few developers in the past got tired of pywikipedia, specifically because of our development process. I would love to improve that aspect of our project.
Regards,
-- << Marcin Cieslak // saper@saper.info >>
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Nicolas Dumazet ha scritto:
Being now used to the Mercurial community, where each patch is sent to the dev- mailing list before being pulled by the relevant maintainer, I would love to see those practices here. If the community was interested to do the switch, I would be willing to spend a significant part of my time to review patches, and/or give assistance in Mercurial usage. I think that a few developers in the past got tired of pywikipedia, specifically because of our development process. I would love to improve that aspect of our project.
\o/
Finally. :-)
"Nicolas Dumazet" nicdumz@gmail.com wrote in message news:1f077e770911160359w46689d18o7430a9859b7109f@mail.gmail.com...
... The only way to ensure stability IMHO is to introduce a strict review process, where a changeset has to be reviewed by a qualified developer other than the submitter before making it into the main development branch. It appears to slow down the process at first, because it introduces a delay in the commit workflow, but in the end code quality significantly improves, and this reduces maintenance costs.
Being now used to the Mercurial community, where each patch is sent to the dev- mailing list before being pulled by the relevant maintainer, I would love to see those practices here. If the community was interested to do the switch, I would be willing to spend a significant part of my time to review patches, and/or give assistance in Mercurial usage. I think that a few developers in the past got tired of pywikipedia, specifically because of our development process. I would love to improve that aspect of our project.
I would love to see this improved, as well; what do other developers say? Let's not let this topic drop for lack of response...
Russ
pywikipedia-l@lists.wikimedia.org