[Wikitech-l] UsabilityInitiative extension is going to die
As I mentioned in a prior email, I have been converting UsabilityInitiative/* extensions to work with ResourceLoader, and in the process removing their dependency on UsabilityInitiative.php. Some of these extensions were not really using any functionality in UsabilityInitiative.php, so their conversion was more like cleanup and removing a line that included it unnecessarily. The remaining extensions (WikiEditor, Vector, ClickTracking and PrefStats) are now only compatible with MediaWiki 1.17 because they depend on ResourceLoader functionality. I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Please see the README for UsabilityInitiative (http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/README?view=markup) which you will notice ends in calling out that these extensions should be moved. I've already moved Vector and WikiEditor, and the remaining ones will likely be moved soon if there are no objections. This should put the last nail in the coffin for UsabilityInitiative. (the extension that is, the grant has been over for ages!) - Trevor ___ 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
Dan Nessett wrote: On Sun, 19 Sep 2010 23:42:08 +0200, Platonides wrote: You load originaldb.objectcache, retrieve the specific configuration, and switch into it. For supporting many sumyltaneous configurations, the keyname could have the instance (whatever that cookie is set to) appended, although those dynamic configurations make me a bit nervous. Well, this may work, but consider the following. A nightly build environment (and even a local developer test environment) tests the latest revision using a suite of regression tests. These tests exercise the same wiki code, each parametrized by: + Browser type (e.g., Firefox, IE, Safari, Opera) + Database (e.g., MySQL, Postgres, SQLite) + OS platform (e.g., Linux, BSD unix variant, Windows variant) A particular test environment may not support all permutations of these parameters (in particular a local developer environment may support only one OS), but the code mechanism for supporting the regression tests should. To ensure timely completion of these tests, they will almost certainly run concurrently. So, when a regression test runs, it must not only retrieve the configuration data associated with it, it must create a test run environment (e.g., a test db, a test images directory, test cache data). The creation of this test run environment requires an identifier somewhere so its resources may be reclaimed when the test run completes or after an abnormal end of the test run. Thus, the originaldb must not only hold configuration data with db keys identifying the particular test and its parameters, but also an identifier for the test run that can be used to reclaim resources if the test ends abnormally. The question is whether using a full wiki db for this purpose is advantageous or whether stripping out all of the other tables except the objectcache table is the best implementation strategy. Such originaldb would be empty for an instance used just for regression testing and could in fact only contain the objectcache table. If it's a developer machine he would use the originaldb for local testing, but a nigthly would not need to (in fact, errors trying to access those missing tables would be useful for detecting errors in the isolating system). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
On Mon, Sep 20, 2010 at 4:12 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Is there any sort of timeline for moving this stuff into core? I don't see any (long term) reason to leave these as extensions. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
Trevor Parscal wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. I hope that means we will be running 1.16wmf5 branched post-r72349 in November... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
On 9/20/10 1:35 PM, Platonides wrote: Trevor Parscal wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. I hope that means we will be running 1.16wmf5 branched post-r72349 in November... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l That sounds like a Tim Starling question. - Trevor ___ 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
On Mon, 20 Sep 2010 22:32:24 +0200, Platonides wrote: Dan Nessett wrote: On Sun, 19 Sep 2010 23:42:08 +0200, Platonides wrote: You load originaldb.objectcache, retrieve the specific configuration, and switch into it. For supporting many sumyltaneous configurations, the keyname could have the instance (whatever that cookie is set to) appended, although those dynamic configurations make me a bit nervous. Well, this may work, but consider the following. A nightly build environment (and even a local developer test environment) tests the latest revision using a suite of regression tests. These tests exercise the same wiki code, each parametrized by: + Browser type (e.g., Firefox, IE, Safari, Opera) + Database (e.g., MySQL, Postgres, SQLite) + OS platform (e.g., Linux, BSD unix variant, Windows variant) A particular test environment may not support all permutations of these parameters (in particular a local developer environment may support only one OS), but the code mechanism for supporting the regression tests should. To ensure timely completion of these tests, they will almost certainly run concurrently. So, when a regression test runs, it must not only retrieve the configuration data associated with it, it must create a test run environment (e.g., a test db, a test images directory, test cache data). The creation of this test run environment requires an identifier somewhere so its resources may be reclaimed when the test run completes or after an abnormal end of the test run. Thus, the originaldb must not only hold configuration data with db keys identifying the particular test and its parameters, but also an identifier for the test run that can be used to reclaim resources if the test ends abnormally. The question is whether using a full wiki db for this purpose is advantageous or whether stripping out all of the other tables except the objectcache table is the best implementation strategy. Such originaldb would be empty for an instance used just for regression testing and could in fact only contain the objectcache table. If it's a developer machine he would use the originaldb for local testing, but a nigthly would not need to (in fact, errors trying to access those missing tables would be useful for detecting errors in the isolating system). Sounds reasonable. Using this approach, here is how I see the logical flow of a test run. (NB: by a test run, I mean an execution of a test in the regression test set). The wiki under test is set up with a master database consisting of a single objectcache table. The entries of this table specify a test run identifier as primary key and temporary resource identifiers as dependent fields. Setup of a test run requires the creation of the test run temporary resources and a entry in the objectcache table. A cookie or other state is returned to the testing application. This state is provided by the testing application during the test run on each request to the wiki under test. When a request is sent to the wiki under test, very early in the request processing (e.g., immediately after LocalSettings is processed) a hook is called with the provided state information as an argument that accesses the objectcache table. The extension function handling the hook switches in the temporary resources and returns. After the test run completes, the testing application cleans up the test run by requesting the deletion of the temporary resources and the objectcache table entry associated with the test run. In order to handle prematurely abandoned test runs, the objectcache table entry probably needs an entry that specifies its lifetime. If this lifetime expires, the temporary resources associated with the entry are reclaimed and the entry is delete. -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
Chad wrote: On Mon, Sep 20, 2010 at 4:12 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Is there any sort of timeline for moving this stuff into core? I don't see any (long term) reason to leave these as extensions. I think nearly everyone agrees that most of this should be in core. Saying so is trolling, though. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
On Mon, Sep 20, 2010 at 6:07 PM, MZMcBride z...@mzmcbride.com wrote: I think nearly everyone agrees that most of this should be in core. Saying so is trolling, though. Don't see how it's trolling. But then again, maybe I should defer to your expertise in the area. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
Chad wrote: On Mon, Sep 20, 2010 at 6:07 PM, MZMcBride z...@mzmcbride.com wrote: I think nearly everyone agrees that most of this should be in core. Saying so is trolling, though. Don't see how it's trolling. But then again, maybe I should defer to your expertise in the area. I don't either. :-) Creating an extension called Vector when there's already a skin called Vector is absolutely needlessly confusing. This builds upon the confusion of having a skin called Vector while having a sub-extension called UsabilityInitiative/Vector. It creates more work in the future because there are now two extensions (UsabilityInitiative/Vector and Vector) that have to maintained (translated, etc.) and eventually cleaned up after when the code is finally put in core. It also creates more work for wiki administrators who have to keep track of what's what and install/maintain extensions that shouldn't be extensions in the first place. An artificial deadline has been erected for the release of MediaWiki 1.17 that appears to have no basis in reality (if there's an updated roadmap or official target release date for 1.17, feel free to link me to it), but that was the explanation I was given for the hasty changes. More discussion is available here: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73030 MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
Aryeh Gregor wrote: Implying that particular groups of developers aim to suppress particular technical opinions, without naming the developers or giving any supporting evidence, is definitely trolling. You think calling specific individuals out (getting personal) would _improve_ matters? Interesting. Saying thanks for your input seems like a pretty clear example of developers trying to suppress (or dismiss, rather) particular technical opinions. I included a link to the relevant comments in the follow-up e-mail. This post would have been much improved if the second sentence were deleted, and your follow-up post could have done without language such as artificial, hasty, appears to have no basis in reality when speaking about a developer's actions. Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year. I've seen nothing publicly that supports this, so until then, I'll treat it as dubious. I think it's reasonable to do so. I asked in the follow-up e-mail if I was simply missing an announcement somewhere about an updated roadmap or deadline, which is entirely possible. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote: Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year. I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier ro...@robla.net wrote: I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. I think the primary objection would be that we don't want to do a release of code that hasn't run on Wikimedia for a while. We never have before, certainly. Not many people use wikis running RCs or betas compared to the number who use Wikipedia, so we'll get vastly fewer bug reports and thus ship a much buggier release if we don't scap the code well before we release it. It's also kind of sketchy to say that trunk is good enough for release when it hasn't been vetted as suitable for Wikimedia deployment. So whatever the timetable is, we need to have scap placed somewhere significantly before branch for release. If we say a month before, then that would be five days ago according to your timetable, so I don't think that's a good idea. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
I think someone (RobLa) is planning on populating these areas of the wiki as more meetings take place - so I'm not sure we should be so critical of the number of links in [[Meetings/Release]] - but yeah, you've got a fair point, if we are going to be keeping meeting notes in a public place (a big thank you should go to RobLa here!) some links to the meetings page would help make the public notes a little more public. I would add some myself, but I'm not sure I know where the link to [[Meetings]] should go. I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. - Trevor On 9/20/10 5:01 PM, Guillaume Paumier wrote: Hi, Le lundi 20 septembre 2010 à 16:47 -0700, Rob Lanphier a écrit : I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 The only incoming link for [[Meetings/Release/2010-07-14]] is [[Meetings/Release]], whose only incoming link is [[Meetings]], which doesn't have any incoming link. Discussions involving as major a decision as a release date should probably be a little more advertised :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
Le lundi 20 septembre 2010 à 17:08 -0700, Trevor Parscal a écrit : I think someone (RobLa) is planning on populating these areas of the wiki as more meetings take place - so I'm not sure we should be so critical of the number of links in [[Meetings/Release]] - but yeah, you've got a fair point, if we are going to be keeping meeting notes in a public place (a big thank you should go to RobLa here!) some links to the meetings page would help make the public notes a little more public. I would add some myself, but I'm not sure I know where the link to [[Meetings]] should go. I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. Oh, I'm not specifically criticizing the number of links. I actually think it's great the notes are being posted publicly. I'm just generally commenting on the fact that it's difficult to find the information if you don't know it's even there. Adding a link to [[Meetings]] is easy, but probably not much more helpful in attracting eyeballs. I guess my main general point was Keeping people informed is as easy as sending an email to wikitech-l. -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 8:08 PM, Trevor Parscal tpars...@wikimedia.org wrote: I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. We're not always sure where or how something should be done, so we talk about it and look for ideas. Take this issue for example, we're not sure where something should be linked, but mention it here knowing that someone else probably has some ideas -- that person is then free to be bold and add a link wherever he thinks would be good. Speaking more generally, the reason that people might be better at talking about doing things rather than doing them themselves could be because they're afraid they'll just get reverted if they try to be bold. -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 4:53 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier ro...@robla.net wrote: The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). [...] I think the primary objection would be that we don't want to do a release of code that hasn't run on Wikimedia for a while. We never have before, certainly. Not many people use wikis running RCs or betas compared to the number who use Wikipedia, so we'll get vastly fewer bug reports and thus ship a much buggier release if we don't scap the code well before we release it. It's also kind of sketchy to say that trunk is good enough for release when it hasn't been vetted as suitable for Wikimedia deployment. This seems like a fine line of reasoning, though not one that I had thought was set in stone. For earlier releases, the MediaWiki releases benefited from deployment being pretty close to trunk, but presumably the reason why that drifted was because it became progressively harder for us to use our production environment as the de facto MediaWiki testbed. So, 1.16wmf4 and 1.16 shared the same branch point, which was perhaps the start of a tradition. Is this the new rule? I don't have a strong opinion about whether that should be the case, but it does change how I think about 1.17 planning. My understanding is that we will probably want a new deployment branch soon because of ResourceLoader (at least). So whatever the timetable is, we need to have scap placed somewhere significantly before branch for release. If we say a month before, then that would be five days ago according to your timetable, so I don't think that's a good idea. I'm not sure what you mean by this. October 15 would be the branch point, not the release date. Are you saying that we have to release to production one month before even branching off of trunk? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
Rob Lanphier wrote: On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote: Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year. I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Thank you for this. I'm sure a lot of people will be watching the root page with a lot of interest. I agree with a lot of the other posters in this thread that publicly posting notes like this is a really good step in the right direction. :-) Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. I think there's a much greater desire for the live Wikimedia sites to be updated more regularly, far more than MediaWiki being released more regularly. Not that they're mutually exclusive, though with the current branch system, I suppose they could be, which raises further questions. The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. Personally, I see a rough parallel between the concept of FlaggedRevs on a wiki and the current code development cycle. Nobody wants to make a contribution if it's going to sit in a queue indefinitely. It's much more satisfying to see your work (bug fix, article fix, whatever) go live in a relatively short amount of time. Has there been any discussion about killing the branch system altogether? From my perspective, the initiation of branching has slowed down code pushes dramatically. This may be a false correlation I'm drawing, but I don't think so. There isn't nearly as much incentive to fix trunk when the branches are stable. But with that stability comes very little code development, aside from high priority Wikimedia Foundation projects being pushed into the branches directly by a few people. It also creates a lot more work (and commit noise) to merge from trunk rather than keeping trunk up and relatively stable (or stable enough to run the live sites). Has it been raised that going back to how things used to be might be better? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
