Re: [Wikitech-l] Release process
On Thu, Oct 21, 2010 at 7:56 AM, Rob Lanphier wrote: > 1. Is the release cadence is more important (i.e. reverting features > if they pose a schedule risk) or is shipping a set of features is > important (i.e. slipping the date if one of the predetermined feature > isn't ready)? For example, as pointed out in another thread + IRC, > there was a suggestion for creating a branch point prior to the > introduction of the Resource Loader.[1] Is our priority going to be > about ensuring a fixed list of features is ready to go, or should we > be ruthless about cutting features to make a date, even if there isn't > much left on the feature list for that date? > I'm afraid that branching before RL merge is not going to help in the present state of affairs. We have a zillion of unreviewed and untested revisions before that, so maintaining two branches will require us to virtually double the efforts. > 2. Projects with generally predictable schedules also have a process > for deciding early in the cycle what is going to be in the release. > For example, in Ubuntu's most recently completed release schedule [2], > they alloted a little over 23 weeks for development (a little over 5 > months). The release team slated a "Feature Definition Freeze" on > June 17 (week 7), with what I understand was a pretty high bar for > getting new features listed after that, and a feature freeze on August > 12 (week 15). Many features originally slated in the feature > definition were cut. Right now, we have nothing approaching that > level of formality. Should we? > Obviously, we're not ready to determine the exact date of 1.17 release, because we worked on it (and are continuing doing so) without a set date in mind. The question is what we should do to make things more predictable for 1.18. When we see how well that goes on, we could decide how strict we want our schedule to be - IMHO, Ubuntu's way results in buggy releases, as people reported some blatantly stupid regressions in 10.10. > 3. How deep is the belief that Wikimedia production deployment must > precede a MediaWiki tarball release? Put another way, how tightly are > they coupled? > I believe that every developer believes so. > Thoughts on these? Any other tradeoffs we need to consider? We're going to have a number of conversations over the coming days on this topic, so I wanted to add a little structure and get some (more) > initial impressions now. > Can these discussions be made accessible to those of us who will not be present? A skypecast would be ideal, but simpler ways would do, including text transcripts. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Release process
Hi everyone, There have been a number of calls to make the release process more predictable (or maybe just faster). There are plenty of examples of projects that have very predictable release schedules, such as the GNOME project or the Ubuntu Linux distribution. It's not at all unreasonable to expect that we could achieve that same level of predictability if we're prepared to make some tradeoffs, such as: 1. Is the release cadence is more important (i.e. reverting features if they pose a schedule risk) or is shipping a set of features is important (i.e. slipping the date if one of the predetermined feature isn't ready)? For example, as pointed out in another thread + IRC, there was a suggestion for creating a branch point prior to the introduction of the Resource Loader.[1] Is our priority going to be about ensuring a fixed list of features is ready to go, or should we be ruthless about cutting features to make a date, even if there isn't much left on the feature list for that date? 2. Projects with generally predictable schedules also have a process for deciding early in the cycle what is going to be in the release. For example, in Ubuntu's most recently completed release schedule [2], they alloted a little over 23 weeks for development (a little over 5 months). The release team slated a "Feature Definition Freeze" on June 17 (week 7), with what I understand was a pretty high bar for getting new features listed after that, and a feature freeze on August 12 (week 15). Many features originally slated in the feature definition were cut. Right now, we have nothing approaching that level of formality. Should we? 3. How deep is the belief that Wikimedia production deployment must precede a MediaWiki tarball release? Put another way, how tightly are they coupled? Thoughts on these? Any other tradeoffs we need to consider? We're going to have a number of conversations over the coming days on this topic, so I wanted to add a little structure and get some (more) initial impressions now. Rob [1] MZMcBride's mail: http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/049969.html ...which in turn references IRC from 2010-10-18 @ 14:08 or so: http://toolserver.org/~mwbot/logs/%23mediawiki/20101018.txt [2] Ubuntu Maverick Meerkat (10.10) release schedule: https://wiki.ubuntu.com/MaverickReleaseSchedule ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Convention for logged vs not-logged page requests
Marco Schuster wrote: >> In your case, I would append ctype=text/javascript to the query string, >> so it >> a) Looks more like something that will give out javascript. >> b) Forces it to use the long style. > Nope, appending parameters works also in the short form: > http://en.wikipedia.org/wiki/Special:BannerController?ctype=text/javascript > > Works also for ?action=edit etc. > > Marco You could do that. But using the appropiate functions for creating the link, you will be given the "ugly url". That's what I referred to. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Convention for logged vs not-logged page requests
On Wed, Oct 20, 2010 at 5:51 AM, Domas Mituzas wrote: >> It seems like an awful lot of trouble to teach every software author >> that they need to follow a particular convention just so the stats >> engine will work as intended. It would seem like it would be much >> simpler to teach the stats engine to simply detect and ignore this >> special case. Or is there a reason that doing so is not possible? > > Heh, apparently stats became a big deal lately, so one with powers to > change that can feel important! ;-) > > Anyway, there're few choices to resolve it on the stats side: > > 1) Implement pulling of a namespace map for each project, build out > an efficient rules engine (in C) for dealing with this (do note, every > project will have different namespace for this URL). Also, make it > extensible, so each developer tells about which names will be > not-a-pageview ;-) There's nothing as fun as writing that kind of > code, and do note, it won't be just five (or fifty) lines. > 3) Not care about inflated per-project numbers, or have people adjust > the numbers, as the source data is there (They can filter out banner > loader themselves!) I think my comment about "stats engine" may have been confusing. I tend to think of the entire process chain as part of the stats engine, even though it is implemented as distinct collection and interpretation bits. There is no reason that the filtering has to be done in the stats collector. It could be done there, but given the language variants that is likely to be hard to code and slow, as you rightly point out. I think I had more in mind that it be filtered at the interpretation side of the stats process. In other words, that Zachte (or whoever) generate a list of pages that are ignored for the purposes of counting stats. That would seem to be an easier place to deal with an exclusion list and to pull all language versions of those page names, and such. Having such an exclusion list for interpretation will be necessary anyway if we plan to reprocess the existing logs that don't follow the suggested convention. (I'm assuming we don't want to simply throw out three weeks of logs.) -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] using parserTests code for selenium test framework
Hi, Automatic testing with a clean database sounds good, the scheme looks reasonable. Will it be possible to have cleaning of separate databases, used by extensions, added, also? In the context of wiki identification, I was wondering: At the moment I am mainly testing SMW instances having the selenium-server, the application under test, and the tests each on the same machine. Wiki identification is no issue, here. Of course, it would be great to eventually have the WM/extension testing on external (possibly Wikimania) infrastructure, resulting in higher security requirements; Is this planned or much considered in the discussions? Keep up the good work! Regards, Benedikt -- Karlsruhe Institute of Technology (KIT) Institute of Applied Informatics and Formal Description Methods (AIFB) Benedikt Kämpgen Research Associate Kaiserstraße 12 Building 11.40 76131 Karlsruhe, Germany Phone: +49 721 608-7946 Fax: +49 721 608-6580 Email: benedikt.kaemp...@kit.edu Web: http://www.kit.edu/ KIT University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Markus Glaser Sent: Friday, October 15, 2010 3:54 PM To: Wikimedia developers Subject: Re: [Wikitech-l] using parserTests code for selenium test framework Hi, I recently suggested some scheme for dynamically creating clean wikis for Selenium tests, which can be found here: http://www.mediawiki.org/wiki/SeleniumFramework#Testing_with_a_clean_databas e_and_file_state After some discussion in the Testing group, I would like to elaborate a bit further on some of the steps that need to be done: 2.2 Create temporal resources 2.2.1 create a new database with name "se"+testID 2.2.2 create a new images folder with name "se"+testID 2.2.3 populate database and images with template data. there is a standard (vanilla) template, but also, test suites can have their own templates, which then would be used. this test data should be placed in the same folder as the tests, with the same name. 2.3 Create test tracker with timestamp I suggest we use a textfile called "se"+testID.txt in a folder wiki/seRunningTests. The timestamp would be the creation date of the file. The next important question is, how should the wiki be identified? Brion suggested using a subdomain, e.g. "sn"+testID.yourwiki.org. If I understand webserver correctly, however, this would need some specific setup. In the selenium testing group we were discussion identifying the wiki via cookie. So the wiki under test would read the cookie and reconfigure accordingly. The reconfiguration would need to take place right after LocalSettings.php, since the following call to Setup.php already assumes some configurations as set. As far as I know, Priyanka already has written some code to do this. 3.1 start testsuites via selenium 3.1.1 First, the SeleniumTestRunner needs to store the testID in order to identify the ressources for teardown. 3.1.2 Start the test suite 5.1 send teardown request fetch the testID stored in 3.1.1 and request the wiki under test to teardown the ressources for that id I would be very happy about comments and thoughts. Are we heading in the right direction? Cheers, Markus -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Markus Glaser Gesendet: Mittwoch, 29. September 2010 20:02 An: Wikimedia developers Betreff: Re: [Wikitech-l] using parserTests code for selenium test framework Hi, since the wiki under test is not neccessarily the wiki running the test, it might be useful to visualize that (I have numbered the individual steps to make reference to them easier in the discussion): testrunner wiki under test -- --- 1.1 start selenium which in turn starts a browser to talk to the wiki under test 1.2 send request for new test with unique test id and tests that will be fired 2.1 create cookie with test id 2.2 create temporal resources according to tests list 2.3 create test tracker with timestamp 2.4 return success code 3.1 start testsuites via selenium 3.2 send a lot of individual requests according to the tests 4.1 testrunner is identified by test id 4.2 reconfigure database and resources according to test id 4.3 ? Do something with memcached ? 4.4 execute request 4.5 update timestamp in test tracker 5.1 send a teardown request 6.1 execute teardown, i.e. delete
Re: [Wikitech-l] Selenium Framework - test run configuration data
Hi, The selenium framework configuration using a config file [1] is much clearer now. Thanks. Regards, Benedikt [1] http://www.mediawiki.org/wiki/SeleniumFramework#Configure_Selenium_using_a_c onfiguration_file -- Karlsruher Institut für Technologie (KIT) Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB) Benedikt Kämpgen Wissenschaftlicher Mitarbeiter Kaiserstraße 12 Gebäude 11.40 76131 Karlsruhe Telefon: +49 721 608-7946 Fax: +49 721 608-6580 E-Mail: benedikt.kaemp...@kit.edu Web: http://www.kit.edu/ KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Benedikt Kaempgen Sent: Thursday, October 07, 2010 11:28 PM To: pdha...@wikimedia.org; Wikimedia developers Subject: Re: [Wikitech-l] Selenium Framework - test run configuration data Hi Priyanka, Thanks for the update of the framework documentation. I will try to have a look at it soon. Cheers! Benedikt -- Karlsruhe Institute of Technology (KIT) Institute of Applied Informatics and Formal Description Methods (AIFB) Benedikt Kämpgen Research Associate Kaiserstraße 12 Building 11.40 76131 Karlsruhe, Germany Phone: +49 721 608-7946 Fax: +49 721 608-6580 Email: benedikt.kaemp...@kit.edu Web: http://www.kit.edu/ KIT University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Priyanka Dhanda Sent: Wednesday, September 22, 2010 2:29 AM To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Selenium Framework - test run configuration data I made a few changes to the test runner and how we configure it. Also changed the mediawiki page to reflect this: http://www.mediawiki.org/wiki/SeleniumFramework#Configure_the_framework -p On 09/07/2010 09:52 AM, Ryan Lane wrote: >> I should also point out that what I was planning to do was not hidden. >> I wrote about these changes in my weekly report the Monday before I >> committed them (http://bit.ly/cqAcqz) and pointed to the weekly >> report from my Ohloh, Twitter, Identi.ca and Facebook accounts. >> >> Granted, this is not the same as posting to the mailing list, and for >> that I apologize. >> >> Looking back in the archives on gmane, it looks like you are very >> interested in MW testing. Since this is a large part of my focus >> currently as well, perhaps we should coordinate our work? >> >> > Please coordinate through wikitech-l and the SeleniumFramework page on > mediawiki.org [1]. It is good to broadcast information through other > sources as well, but normal communication methods are best. If changes > are being made to the framework, the documentation should also be > updated. > > -- Ryan > > [1] http://www.mediawiki.org/wiki/SeleniumFramework > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Priyanka Dhanda Code Maintenance Engineer Wikimedia Foundation http://wikimediafoundation.org San Francisco, CA ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Convention for logged vs not-logged page requests
Hi! > will still return the same results, wouldn't it make more sense to > teach the stat's logger to ignore both? Or is there a reason that we > actually want to track one and not the other? Pretty URLs are for being pretty URLs (e.g. in your address bar). That leads to very easy assumption, that if there's a pretty URL, it probably indicates a pageview :-) We quite like other pretty URLs for Special pages e.g. Watchlist or Recentchanges - as we track their accesses. > It seems like an awful lot of trouble to teach every software author > that they need to follow a particular convention just so the stats > engine will work as intended. It would seem like it would be much > simpler to teach the stats engine to simply detect and ignore this > special case. Or is there a reason that doing so is not possible? Heh, apparently stats became a big deal lately, so one with powers to change that can feel important! ;-) Anyway, there're few choices to resolve it on the stats side: 1) Implement pulling of a namespace map for each project, build out an efficient rules engine (in C) for dealing with this (do note, every project will have different namespace for this URL). Also, make it extensible, so each developer tells about which names will be not-a-pageview ;-) There's nothing as fun as writing that kind of code, and do note, it won't be just five (or fifty) lines. 2) Add additional internal header (X-Pageview: true!), that would be logged by squids inside the stream :) That probably asks for large review inside MediaWiki, as well as squid code changes (and of course, rollout of new binary). Would be nice inter-group effort. 3) Not care about inflated per-project numbers, or have people adjust the numbers, as the source data is there (They can filter out banner loader themselves!) You can pick any of these, make sure it gets into strategy plan, as we don't decide things on wikitech-l anymore :) I prefer, hehehe, not doing anything, and just having pretty URLs just for pageviews ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Collaboration between staff and volunteers: a two-way street
... > +4,294,967,295 see what you did to poor Roan, in this "always be positive" environment this is the only way he can write -1. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Convention for logged vs not-logged page requests
2010/10/19 Robert Rohde : > It seems like an awful lot of trouble to teach every software author > that they need to follow a particular convention just so the stats > engine will work as intended. It would seem like it would be much > simpler to teach the stats engine to simply detect and ignore this > special case. Or is there a reason that doing so is not possible? > As Domas pointed out to RobLa and myself, special page names are internationalized, so you'd have to teach the stats logger about every translation of it, which is impractical compared to using a different URL. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
