Now that we’ve gotten rid of a ton of code in Pitivi (thanks to the port to GES), Thibault has been doing an incredible job at cleaning and reorganizing the remaining source files in a way that finally makes sense. I’m very happy about this: it means that it will not only make it easier for new contributors to get started, but also for regular contributors to not get lost in the various modules.
Behold, before (left) and after (right):
The old file tree was so big that it did not fit on a rotated 1920×1200 monitor, even with Nautilus fully zoomed out. Note that the tests/ directory is not shown here, it went from 33 test cases to 18 and now runs in one second (since the core tests are now in GES).
If you fail to be utterly amazed and emotional about what I’ve just shown here, I’ll make sure to explain properly the jawdropping significance of this cleanup (and the whole GES port in general), whenever I get a chance to make a talk at some hip conference.
Stuff I’ve been doing in general in the last three weeks:
- Fixed a couple of GES integration bugs in Pitivi. There’s still lots of work to do, but we’re getting closer to being able to make a first alpha release for your enjoyment.
- Redesigned the clip previewing feature. Instead of showing in the tiny timeline previewer, it now shows in a separate window that tries to show the clip at 1:1 size whenever possible. This window can be dismissed by clicking the close button or clicking anywhere outside the window, so there is no reduction of efficiency compared to the old approach.
- Merged, at long last, the power management branch. Pitivi will now inhibit the screensaver when playing and inhibit suspend when rendering.
- Make pitivi use Nautilus/Totem’s thumbnails. The result is prettier and we don’t have to do processing in most cases, which means even faster import/loading times.
- Pushed all that goodness to Pitivi’s origin (main repository) in a “ges” branch.
- Closed over a hundred old PackageKit bug reports on Freedesktop bugzilla. Hughsie should breathe a little bit more easily now.
- Finally killed all the spam pages (1000+) and images (500+) on the pitivi wiki, using the DeletePagePermanently Mediawiki extension (had to patch it for 1.17, see the talk page) and a horrible, horrible homemade python script to delete the pages automatically by opening hundreds of tabs in Firefox, accessing the “&action=delete_permanently” URL directly.
- The remaining problem is that I haven’t found a way to efficiently purge the remaining 800+ fake user accounts yet. Ideas welcome, the UserAdmin extension does not work with anything but Mediawiki 1.16 (and it seems unmaintained).
In related news:
- At the end of January, I will be attending the GStreamer hackfest in Malaga, Spain. I predict that intense bug squashing will ensue. Come say hi if you’re around.
- Can someone please tell me if bug 666916 is a pygtk bug, a gtk bug or something I’ve done wrong? The same code was working a year ago. Current code here, offending line is #911.
Comments
8 responses to “Spring clean-up in January3 min read”
alpha, alpha, alpha !
Fantastic news. Is there a PPA that packages all the gstreamer (GES specifically) dependencies on Ubuntu?
I bet that alpha will be available on the ppa:gstreamer-developers/ppa see http://www.pitivi.org/?go=download
Regarding your MediaWiki questions — there’s an extensions developers meeting on 13 January (tomorrow) at 1900 UTC — https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/MediaWiki_Workshops . It’ll be in IRC in #wikimedia-dev. That might be a good place/time to ask for advice.
@John: no packages for all this in the PPA yet (but I’m hoping we will nudge someone about it by the time we make an alpha release), however if you are interested, check out this script:
http://git.pitivi.org/?p=pitivi.git;a=blob_plain;f=bin/pitivi-git;hb=ges
It has two purposes:
1) It automatically checks out and compiles pygst, GES and pitivi for you (without requiring a systemwide install).
2) Re-running this script afterwards sets you in the “pitivi ges” dev environment (with all the variables set properly) so you can run the thing in-place (the “pitivi” command then redirects to the dev version).
You finally merged that old power-management branch of mine, lol. I’m glad it made it in and sorry I just stopped working on it, there must of been a little bit of work to make use of it.
I’ve been busy with other things in my life and changed a lot, when things stabilise for me I’d love to come develop PiTiVi again with you guys. Until then, good luck & I’m proud of you guys.
Thanks for the invitation Sumana, here is the result of my discussion on #wikimedia-dev on this issue during the meeting today (slightly edited for concision/legibility and to avoid WordPress freaking out on markup):
—————————-
nekohayo So, I maintain wiki.pitivi.org, and over the last 2 years we have been heavily spammed. The situation is now “under control” with a strict account policy, and I managed to recently purge the 1000+ pages and 500+ spam images (including all history). However, 800+ fake user accounts remain. I’d like some advice on how to purge them (including history). There is an extension called UserAdmin, but it seems to work *only* with mediawiki 1.16 and to be unmaintained.
johnduhart We don’t recommend deleteing user accounts, ever.
nekohayo spam user accounts I couldn’t care less 🙂
johnduhart Still applies.
Amgine rename to spamaccount0000001, etc.
nekohayo doing that for 800 accounts is just as much work as deleting them, with no gained clarity in http://wiki.pitivi.org/index.php?title=Special:ListUsers&limit=1500
sumanah I have heard from several MediaWiki administrators that they tried AbuseFilter & other extensions and still get too much spam to deal with, and need help
johnduhart nekohayo: If you don’t clean everything up when you delete users, you’re end up with inconsistancies in your database which could lead to more problems down the road.
nekohayo note that pitivi wiki has less than ten actual users
bawolff nekohayo: icky solution, but you could always rev delete them
gicode nekohayo: You could use Extension:User_Merge_and_Delete to merge them all into one account
johnduhart nekohayo: http://wiki.pitivi.org/index.php?title=Special:ActiveUsers
sumanah One admin writes: “After opening up my wiki for free registration, I immediately got three spam accounts. One turned into real spam being injected into and then cleaned from the wiki. None of the methods aside from preventing self-registration seem to work against spam.”
johnduhart Isn’t this really an administration question?
sumanah johnduhart: I suggested nekohayo come in and ask for help during this meeting
varnent johnduhart: it has extensions applications I’d say
varnent but yeah – hopefully we’ll mimic a session like this for sysadmins as well 🙂
sumanah experienced MW extensions developers are usually also admins
cneubauer Did we already do a session like this for upgrading to 1.18?
nekohayo well, my question is an administration question at its core, but it also is a question of “what is your policy regarding admin extensions, and extensions that seem to be mostly unmaintained”
varnent cneubauer: no – so feel free to ask beyond just MW1.19 – you may ask any questions in general related to developing extensions
sumanah cneubauer: no we did not, this is the first ever session like this
varnent nekohayo: that’s actually a really good question – and one I think we’re just starting to explore
nekohayo for the “DeletePagePermanently” extension for example I had to patch it with some random suggestions in the talk page,and I found that to be a little bit funny in terms of user experience 🙂
varnent nekohayo: this is an effort to try and find all those extensions and utilize new templates to improve things like that – https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Projects/Page_Drive
varnent for example – https://www.mediawiki.org/wiki/Template:Incompatible and https://www.mediawiki.org/wiki/Template:Archived_extension have just recently been created to help with archiving unmaintained extensions, etc. there is also more clarity on https://www.mediawiki.org/wiki/Manual:Developing_extensions#Publishing about what is expected of developers hosting extensions on MW.org
varnent nekohayo: so I think in general the answer is – many others agree there are a lot of extensions in need of archiving and many in need of updating (which should be noted to other developers and sysadmins on their respective pages) – I think until now there’s been a lot of concern about stepping on the toes of those respective extension’s developers – the modifications I mentioned and templates are an effort to work through the concerns and come to some solutions
nekohayo varnent, I have to say I’ve been impressed by wordpress’ extension management system lately, but I guess you might say that’s a completely different target audience 🙂
varnent nekohayo: I agree – I also like how Drupal handles things
sumanah I am hereby jealous of how WP started off as something that ordinary admins were supposed to install & maintain; MediaWiki’s legacy is a tough one in some ways (WP here meaning WordPress), but that’s offtopic
varnent nekohayo: I think we’re trying to get things moved in those directions – and in a way that works for MediaWiki (direct clones of those efforts would be unlikely to work within the Wikimedia communities)
nekohayo WP has a nifty community-based compatibility report for each extension for each release, and their system can actually search and install extensions directly from the admin interface (but I understand this is not exactly trivial to do)
sumanah nekohayo: you saw me talking earlier about the task that would take an experienced developer a lot of time? that sort of dashboard.
varnent nekohayo: but like sumanah said – the original intents of the two projects provides for varying base needs and foundations to work from as the projects are more widely used – I’m not sure the original developers of MediaWiki envisioned a community of literally thousands of sites outside the Wikimedia umbrella running, and in part depending on, the software – although I could be wrong 🙂
sumanah folks, you can subscribe to @MediaWikiMeet on Twitter or Identi.ca to be told of upcoming meetings like this (plus bug triages and hackathons and trainings)
So, judging from some recent conversation
http://lists.wikimedia.org/pipermail/mediawiki-l/2012-February/038924.html
it looks like the recommendation is (to prevent spammers): install QuestyCaptcha, a plugin to the ConfirmEdit extension to MediaWiki. Thought you might want to know!