----- Original Nachricht ----
Von: Strainu <[email protected]>
An: Pywikibot discussion list <[email protected]>
Datum: 07.08.2016 20:16
Betreff: Re: [pywikibot] Vital sign
> 016-08-07 19:27 GMT+03:00 Daniel Glus <[email protected]>:
> > On Aug 7, 2016 12:16 PM, "Tobias Schönberg" <[email protected]> wrote:
> >> It really seems like WMF should have a full time employee for Pywikibot
> >> (or if they already do, maybe another one).
> >
> > Yes, agreed.
> >
> >>> 1- Pywikibot has the biggest number of open patchsets after
> >>> mediawiki/core. You might say, it's okay. Pywikibot is completely
> >>> volunteer-based but ratio of distinct users / open patchsets is
> horrifyingly
> >>> high.
> >
> > As someone who's submitted a few patches, I didn't experience *awful*
> > delays, but looking at the open patchsets, I have to agree that the
> backlog
> > is disturbingly large.
>
> Thanks for bringing this subject up, Amir! I personally had reviews
> taking over a year. Obviously, by that time the change was long
> deprecated/useless.
>
> >
> > I think a possible solution is empowering more people to review patch
> sets.
> > Making a review guide would help a lot; publicizing the style guide would
> > help as well.
>
> I think there were a few steps that hurt PWB in the last few years:
> 1. Too much branching. For so many years we had both compat and core,
> now we went to 2.0/master (if i'm not mistaken). There isn't something
> wrong in branching itself, but when you report a bug as a user, you
> always need to know on what branch you are. Additionally, there have
> been instances where bug reports were... let's say, unwelcomed. For a
> (presumably) simple project, a linear development model, with stable
> releases and continuous development on top of that should be enough.
> Instead of backporting bugfixes, push the users to upgrade.
I agree as I mentioned few months ago. The idea was to publish a stable
version. But the version isn't stable when the environment and dependencies
has been changed. And backporting is a very time consuming process if it is
necessary to cherry pick every single patch from master. I've given up 2.0 and
put it out of my scope; it is just to heavy to synchronize 2.0 with master and
keep it up to day or deploy a new release of it. I feel it is much more
difficult as it was between compat and core. We had ~ 250 commits in master
branch but only 18 for core 2.0 in the last 6 months. Enough to discuss whether
this branch is senseless or not.
> 2. Concentrating on the framework and ignoring the scripts. The
> contributions to the scripts/ folder are few compared to the ones in
> pywikibot/. Still, many of the users, especially in smaller wikis,
> have little understanding of python beyond very simple changes and
> prefer to run already-written scrips.
>
Main advantage of core branch is to split between the framework library and the
scripts itself. It is normal to have more contributions to the library than for
scripts because scripts use (or should use) standardized and testes bot classes
of the library.
Best
xqt
_______________________________________________
pywikibot mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/pywikibot
