Re: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

List overview All Threads
Download

newer

older

[Pywikipedia-l] Appallingly Slow

[Pywikipedia-l] Using...

Maarten Dammers

15 Nov 2009 15 Nov '09

1:47 p.m.

Hi everyone, I'm getting so freaking tired of these untested sloppy commits which keep breaking the bots. alexsh(a)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

Show replies by date

Nakor

15 Nov 15 Nov

2:05 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

On Sun, Nov 15, 2009 at 7:47 AM, Maarten Dammers <maarten(a)mdammers.nl>wrote;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 Maarten

I agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability. Thansk, N.

Misza

9:41 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

On 2009-11-15 14:05, Nakor wrote:

...

On Sun, Nov 15, 2009 at 7:47 AM, Maarten Dammers <maarten(a)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 Maarten I agree with Marteen. Maybe a branch system should be implemented to garantee trunk stability. Thansk, N.

Or a decent test suite? Regards, Misza

Marcin Cieslak

16 Nov 16 Nov

12:26 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

Dnia 15.11.2009 Nakor <nakor.wp(a)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. -- << Marcin Cieslak // saper(a)saper.info >>

Nicolas Dumazet

12:59 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

Hello, 2009/11/16 Marcin Cieslak <saper(a)saper.info>fo>:

...

Dnia 15.11.2009 Nakor <nakor.wp(a)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(a)saper.info >> _______________________________________________ Pywikipedia-l mailing list Pywikipedia-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l

-- Nicolas Dumazet — NicDumZ

Francesco Cosoleto

5:11 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591] trunk/pywikipedia/wikipedia.py

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. :-) -- Francesco Cosoleto What gets us into truoble is not what we don't know. It's what we know for sure that just ain't so. (Mark Twain)

Russell Blau

10 Dec 10 Dec

10:05 p.m.

New subject: [Pywikipedia-l] [Pywikipedia-svn] SVN: [7591]trunk/pywikipedia/wikipedia.py

"Nicolas Dumazet" <nicdumz(a)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

5250

days inactive

5275

days old

pywikibot@lists.wikimedia.org

Manage subscription

6 comments

7 participants

tags (0)

participants (7)

Francesco Cosoleto
Maarten Dammers
Marcin Cieslak
Misza
Nakor
Nicolas Dumazet
Russell Blau