Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
Erik Moeller wrote: What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. It would increase code complexity a lot, and it would make debugging more difficult. Don't forget that the desktop execution environment (front back) is much more heterogenous -- you have gadgets, substantial interface customization via the MediaWiki NS, multiple skins, legacy interfaces, and a much wider set of extensions, all of which conspire to make bugs much harder to reproduce. I'm inclined to think that we already get most of the benefits this approach purports to confer from the general MediaWiki release cycle. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Is there something like a gerrit/git download statistics overview page?
Hi, perhaps I am too naive that it could be implemented with a git-based repo, but is there a kind of download, clone, or access statistics available for core and extensions ? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
On Mon, 2013-05-06 at 12:52 -0700, Greg Grossmeier wrote:
Also, the majority of bugs that
are in the Highest/Immediate priority level (from my gut assessment, I
don't have the data here) are found after a deploy to non-WP projects.
I agree with that impression: We don't get many (manually found)
highest/immediate prio bug reports after the first deployment phase,
most of them after phase 2, and a few after phase 3 (e.g. when we failed
to understand the explosive force of an issue).
Backing that impression up with Bugzilla data:
tl;dr: That's hard.
Long version:
I tried a Bugzilla query for tickets created in the last four months,
that at some point in their lifetime had Priority = {Highest |
Immediate}, restricted it to the products {MediaWiki, MediaWiki
extensions, Wikimedia}, made buglist.cgi display the Opened column
(via Change columns at the bottom); dropped the last 9 characters of
the Opened column (to get rid of the time and only have the date,
though that's UTC so does not perfectly fit our deployment *time*),
imported the resulting CSV into OOCalc, cumulated a bit, and summed up
all those tickets that got filed in a certain deployment phase at
*some* point became highest/immediate. See attachment.
The results don't back up my impression.
One potential reason: Development teams file tickets *at some point* and
don't see priority immediately, and when tickets get triaged they get
higher priority at some point later on. Maybe results would look
different if I the query excluded reporters that are employees?
Don't want to spend too much time trying though.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
inline: tickets.png___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On 05/07/2013 08:47 AM, Andre Klapper wrote:
On Mon, 2013-05-06 at 12:52 -0700, Greg Grossmeier wrote:
Also, the majority of bugs that
are in the Highest/Immediate priority level (from my gut assessment, I
don't have the data here) are found after a deploy to non-WP projects.
I agree with that impression: We don't get many (manually found)
highest/immediate prio bug reports after the first deployment phase,
most of them after phase 2, and a few after phase 3 (e.g. when we failed
to understand the explosive force of an issue).
Backing that impression up with Bugzilla data:
tl;dr: That's hard.
Long version:
I tried a Bugzilla query for tickets created in the last four months,
that at some point in their lifetime had Priority = {Highest |
Immediate}, restricted it to the products {MediaWiki, MediaWiki
extensions, Wikimedia}, made buglist.cgi display the Opened column
(via Change columns at the bottom); dropped the last 9 characters of
the Opened column (to get rid of the time and only have the date,
though that's UTC so does not perfectly fit our deployment *time*),
imported the resulting CSV into OOCalc, cumulated a bit, and summed up
all those tickets that got filed in a certain deployment phase at
*some* point became highest/immediate. See attachment.
The results don't back up my impression.
One potential reason: Development teams file tickets *at some point* and
don't see priority immediately, and when tickets get triaged they get
higher priority at some point later on. Maybe results would look
different if I the query excluded reporters that are employees?
Don't want to spend too much time trying though.
andre
Andre, thanks for trying to run the query on this. Yeah, we split,
rename, reprioritize, and otherwise mess with our Bugzilla tickets so
often that it'd probably be a huge travail to thoroughly research the
question I asked, and that would delay this decision beyond this week.
So I'm fine with going on people's rough estimates and impressions
instead of going the ALL DATA ALL THE TIME route.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is there something like a gerrit/git download statistics overview page?
I can't speak for gerrit but it seems to me github tried, failed, and abandoned capturing these statistics: http://stackoverflow.com/questions/6198194/how-to-see-count-of-project-downloads-on-github On Tue, May 7, 2013 at 3:29 AM, Thomas Gries m...@tgries.de wrote: Hi, perhaps I am too naive that it could be implemented with a git-based repo, but is there a kind of download, clone, or access statistics available for core and extensions ? ___ 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] Is there something like a gerrit/git download statistics overview page?
On Tue, May 7, 2013 at 10:23 AM, Dan Andreescu dandree...@wikimedia.org wrote: I can't speak for gerrit but it seems to me github tried, failed, and abandoned capturing these statistics: http://stackoverflow.com/questions/6198194/how-to-see-count-of-project-downloads-on-github On Tue, May 7, 2013 at 3:29 AM, Thomas Gries m...@tgries.de wrote: Hi, perhaps I am too naive that it could be implemented with a git-based repo, but is there a kind of download, clone, or access statistics available for core and extensions ? There's no way in Gerrit either. I imagine like most hit counters (eg: MediaWiki), it'd be a huge drain on performance and caches mostly throw it off. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On Mon, May 6, 2013 at 10:09 PM, Krinkle krinklem...@gmail.com wrote: On May 3, 2013, at 9:33 PM, Anomie wrote: Taking a recent example[1], please tell me how to compress the following into 62 characters: (in the New features section) * (bug 45535) introduced the new 'LanguageLinks' hook for manipulating the language links associated with a page before display. (in the API section) * BREAKING CHANGE: action=parse no longer returns all langlinks for the page with prop=langlinks by default. The new effectivelanglinks parameter will request that the LanguageLinks hook be called to determine the effective language links. * BREAKING CHANGE: list=allpages, list=langbacklinks, and prop=langlinks do not apply the new LanguageLinks hook, and thus only consider language links stored in the database. I don't think Add LanguageLinks hook with breaking changes to 4 API modules is detailed enough for release notes. And before you try to cheat and split it into multiple commits, note that the new hook and what it means for how langlinks are stored in the database is what is the breaking change in those API modules; the actual changes to the API modules are just mitigating or noting it. The summary actually used for that revision, BTW, was (bug 45535) Hook for changing language links. [1]: https://gerrit.wikimedia.org/r/#/c/59997/ Though this is not a typical type of change and I think you already know the answer, I'll give you my take on this one. As commit subject (and thus release notes change log entry) I'd use: Add hook LanguageLinks for changing langlinks before display Oh, so not mentioning the breaking API change at all? Definitely not good. 2) I'm not sure why you'd make ApiParse not call the hook by default. An option to get the raw langlinks may be useful (I'd be curious as to the use cases, but I can imagine), but doing so by default seems odd. I suggested that too. The Wikidata people disagreed, and I didn't feel like arguing over it. This change is a typical case where extra-awareness notes are in order. I personally wouldn't consider these breaking changes, but anyway, they are certainly important. So these are are the kind of changes for which you'd include notes in a separate section. How do these extra notes get noted wherever you intend for them to be noted? That seems to be missing from the proposal. And this brings me back to my concern that others will incorrectly think they know what is considered a breaking change in the API. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On 7 May 2013 08:52, Brad Jorsch bjor...@wikimedia.org wrote: Oh, so not mentioning the breaking API change at all? Definitely not good. I think you're missing the bit of Timo's proposal where all breaking changes have to *additionally* have a Breaking change: Foo bar baz in the Breaking changes section of the release notes, like they do already. How do these extra notes get noted wherever you intend for them to be noted? That seems to be missing from the proposal. Well, they're currentlyhttps://www.mediawiki.org/wiki/MediaWiki_1.21/wmf10#Breaking_changes documentedhttps://www.mediawiki.org/wiki/MediaWiki_1.21/wmf11#Breaking_changes withinhttps://www.mediawiki.org/wiki/MediaWiki_1.21/wmf12#Breaking_changes the https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf1#Breaking_changes releasehttps://www.mediawiki.org/wiki/MediaWiki_1.22/wmf2#Breaking_changes processhttps://www.mediawiki.org/wiki/MediaWiki_1.22/wmf3#Breaking_changes. I don't think Timo's suggesting changing this part of the process at all, just dumping the attempts to have the RELEASE-NOTES-1.XX file written through commits (which is often full of fail and people too often forget) and replacing it with commit logs. It doesn't remove the obligation on people making breaking changes to note this in the top-level notes. And this brings me back to my concern that others will incorrectly think they know what is considered a breaking change in the API. Yes, what constitutes a breaking change is in the eye of the beholder, but that's a distinct argument that we clearly have an operating definition for, because, umm, people are writing or not writing such notes right now. :-) J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
quote name=Sumana Harihareswara date=2013-05-07 time=10:20:05 -0400 Backing that impression up with Bugzilla data: tl;dr: That's hard. snip The results don't back up my impression. One potential reason: Development teams file tickets *at some point* and don't see priority immediately, and when tickets get triaged they get higher priority at some point later on. Maybe results would look different if I the query excluded reporters that are employees? Don't want to spend too much time trying though. Andre, thanks for trying to run the query on this. Yeah, we split, rename, reprioritize, and otherwise mess with our Bugzilla tickets so often that it'd probably be a huge travail to thoroughly research the question I asked, and that would delay this decision beyond this week. So I'm fine with going on people's rough estimates and impressions instead of going the ALL DATA ALL THE TIME route. Yeah, there isn't any pattern in that graph as is and it would need some more intense work to get right. Thanks for trying, Andre! Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 7:43 PM, Erik Moeller e...@wikimedia.org wrote: We may want to consider at least putting some such scaffolding for beta-prod desktop modes into place before shifting to weekly deployments, although if that holds up this change significantly, I'd be in favor of making the shift first and then iterating. Right now we have lots of individual experimental prefs, some dark launch URL parameters (useNew=1 for the account creation forms etc.), some changes that are announced widely but then rolled out immediately (section edit link change), etc. What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. And we'd need to consider more carefully if/when to make the beta/prod switch -- not necessarily a bad thing. ;-) Have there been any negative experiences with this model on the mobile sites? For the most part, this model has been awesome for mobile. It allows us to iterate on feature ideas quickly, try a lot of different things, and focus on the things that really work. Getting a partially-polished feature in front of a group of users who expect to have things not always work 100% is incredibly valuable - and takes off the pressure of having to get something totally right. If it turns out the feature idea was a bust, it's generally no big deal for us (the mobile team or the users) to either can it or tweak it to make it better. Having an 'alpha' that is essentially a developer sandobx (little to no productization happens for our alpha) and some of the best mobile features have grown from here. We've had occasional issues with beta or alpha features bleeding into a mode they weren't supposed to - though this is generally quick to fix. Ultimately, the issues we've had with the approach have been minor. If this were something adopted by Mediawiki more generally, I would want to see it carefully built into core. Ori brings up a good point about increased code complexity, which is a guarantee with this kind of approach but could certainly be mitigated if the plumbing were well architected. I think thoughtful development of something like this into core would be awesome and would allow us to collectively build better, more useful features, faster. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: next steps
Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 7:43 PM, Erik Moeller e...@wikimedia.org wrote: On Mon, May 6, 2013 at 7:20 PM, MZMcBride z...@mzmcbride.com wrote: The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions. A lot of this could potentially be addressed in a consistent manner across wikis if we applied the alpha-beta-prod (or just beta-prod for starters) channel model that's used on the Wikimedia mobile sites. Then features (whether in core or extensions) could be flagged for alpha or beta readiness, and users would only get them if they've decided to opt into either of those channels. We could still flip the switch from beta-prod, but that decision could be decoupled from the weekly deployment cycle. This would likely be done for features changes which have significant user-facing impact, and where segregation into on and off modes is possible (not always the case). I think this is awesome for features ... but if we're putting work into this, I would love even more to have a clustered a+b production environment, such that 10% of folks are put on the new release (cluster a) and then it gets pushed over to cluster b. Then we can also test performance in a real world environment, and breakages only happen for 10% (PS the 10% number was pulled out of thin air). The opt-in beta is much too limited, as well as being inapplicable to the vast majority of our traffic (logged in users are such a small percentage) to make proper comparisons. You could also see the impact of features on usage for average users. We may want to consider at least putting some such scaffolding for beta-prod desktop modes into place before shifting to weekly deployments, although if that holds up this change significantly, I'd be in favor of making the shift first and then iterating. Right now we have lots of individual experimental prefs, some dark launch URL parameters (useNew=1 for the account creation forms etc.), some changes that are announced widely but then rolled out immediately (section edit link change), etc. What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. And we'd need to consider more carefully if/when to make the beta/prod switch -- not necessarily a bad thing. ;-) Have there been any negative experiences with this model on the mobile sites? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: next steps
That's awesome, Quim. Thanks for all your efforts, support, encouragement and guidance so far. The best is yet to come! May you enjoy many more alcohol-free drinks in celebration of future milestones passed. Cheers! Siebrand On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org wrote: Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On May 7, 2013, at 5:52 PM, Brad Jorsch bjor...@wikimedia.org wrote: On Mon, May 6, 2013 at 10:09 PM, Krinkle krinklem...@gmail.com wrote: On May 3, 2013, at 9:33 PM, Anomie wrote: Taking a recent example[1], please tell me how to compress the following into 62 characters: (in the New features section) * (bug 45535) introduced the new 'LanguageLinks' hook for manipulating the language links associated with a page before display. (in the API section) * BREAKING CHANGE: action=parse no longer returns all langlinks for the page with prop=langlinks by default. The new effectivelanglinks parameter will request that the LanguageLinks hook be called to determine the effective language links. * BREAKING CHANGE: list=allpages, list=langbacklinks, and prop=langlinks do not apply the new LanguageLinks hook, and thus only consider language links stored in the database. I don't think Add LanguageLinks hook with breaking changes to 4 API modules is detailed enough for release notes. And before you try to cheat and split it into multiple commits, note that the new hook and what it means for how langlinks are stored in the database is what is the breaking change in those API modules; the actual changes to the API modules are just mitigating or noting it. The summary actually used for that revision, BTW, was (bug 45535) Hook for changing language links. [1]: https://gerrit.wikimedia.org/r/#/c/59997/ Though this is not a typical type of change and I think you already know the answer, I'll give you my take on this one. As commit subject (and thus release notes change log entry) I'd use: Add hook LanguageLinks for changing langlinks before display Oh, so not mentioning the breaking API change at all? Definitely not good. 2) I'm not sure why you'd make ApiParse not call the hook by default. An option to get the raw langlinks may be useful (I'd be curious as to the use cases, but I can imagine), but doing so by default seems odd. I suggested that too. The Wikidata people disagreed, and I didn't feel like arguing over it. This change is a typical case where extra-awareness notes are in order. I personally wouldn't consider these breaking changes, but anyway, they are certainly important. So these are are the kind of changes for which you'd include notes in a separate section. How do these extra notes get noted wherever you intend for them to be noted? That seems to be missing from the proposal. And this brings me back to my concern that others will incorrectly think they know what is considered a breaking change in the API. Extra notes are added like usual, except now on the release notes wiki page instead of the file in version control. Now I hear you thinking, does that mean every patch contributor now needs to know about this wiki page and wait for the change to be approved and then edit the page to add notes? No. It is the duty of repository co-owners to make wise decisions beyond just code quality. About what changes go in what release (if at all), whether the introduced features are in the best interest of the users and that we can maintain them and are willing to support them. And to be aware of whether a change is breaking or not, and if so if whether the change should still go in the current release or a the next (e.g. don't remove/break without deprecation first, if possible). As such the co-owners of a repository (not per se the patch contributor) will know these things and should take care (or delegate) the addition of proper release notes as you deem appropriate for the users of the component(s) you maintain. This also means that there's no uncomfortable waiting time between submission and (if needed for this particular change) the editing of the wiki page. Because can write them right after you approve a change (or do it later). -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@gmail.com wrote: It is the duty of repository co-owners to make wise decisions beyond just code quality. About what changes go in what release (if at all), whether the introduced features are in the best interest of the users and that we can maintain them and are willing to support them. And to be aware of whether a change is breaking or not, and if so if whether the change should still go in the current release or a the next (e.g. don't remove/break without deprecation first, if possible). So in other words, this puts more burden on reviewers, making it harder to get changes merged, especially for new users? Because that's what this sounds like. Changes are already rotting in gerrit for a year (see the recent watchlist thread), and this certainly will not help. The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On Tue, May 7, 2013 at 2:56 PM, Bartosz Dziewoński matma@gmail.com wrote: On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@gmail.com wrote: It is the duty of repository co-owners to make wise decisions beyond just code quality. About what changes go in what release (if at all), whether the introduced features are in the best interest of the users and that we can maintain them and are willing to support them. And to be aware of whether a change is breaking or not, and if so if whether the change should still go in the current release or a the next (e.g. don't remove/break without deprecation first, if possible). So in other words, this puts more burden on reviewers, making it harder to get changes merged, especially for new users? Because that's what this sounds like. Changes are already rotting in gerrit for a year (see the recent watchlist thread), and this certainly will not help. The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one. As I said many times before, this isn't really necessary since JGit now supports recursive merges, it's just experimental so I hadn't turned it on. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
quote name=Leslie Carr date=2013-05-07 time=11:43:47 -0700 I think this is awesome for features ... but if we're putting work into this, I would love even more to have a clustered a+b production environment, such that 10% of folks are put on the new release (cluster a) and then it gets pushed over to cluster b. Then we can also test performance in a real world environment, and breakages only happen for 10% (PS the 10% number was pulled out of thin air). I really like this idea, I think. So bringing various concurrent (email) threads together; long term we could have something that looks like this (roughly): 1) Change proposed - Jenkins runs tests on a throw away labs instance 2) Change merged to master - Jenkins/etc runs tests on betalabs 3) New wmfXX released to 10% of cluster - 10% being something like: test, test2, mediawiki.org, and some of the non-'pedia project sites - Our users do the testing ;-) 4) That wmfXX goes to the rest of the cluster - Hopefully all is good. Is that kind of what you had in mind, Leslie? Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On Tue, 07 May 2013 21:00:05 +0200, Chad innocentkil...@gmail.com wrote: The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one. As I said many times before, this isn't really necessary since JGit now supports recursive merges, it's just experimental so I hadn't turned it on. How catastrophic could turning it on be? Because if not very much, then this would greatly improve everyone's workflows. Just count the manual rebase patchsets on anything involving release notes... -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On Tue, May 7, 2013 at 3:07 PM, Bartosz Dziewoński matma@gmail.com wrote: On Tue, 07 May 2013 21:00:05 +0200, Chad innocentkil...@gmail.com wrote: The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one. As I said many times before, this isn't really necessary since JGit now supports recursive merges, it's just experimental so I hadn't turned it on. How catastrophic could turning it on be? Because if not very much, then this would greatly improve everyone's workflows. Just count the manual rebase patchsets on anything involving release notes... I haven't tried, so who knows. We could turn it on for a test repo (it's configured like normal merge strategies, just no UI for it) and give it a whirl. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] create bugzilla project for PageSchemas, Lingo and Semantic Glossary
Hi everyone! How is it possible to create a project in Bugzilla for the extensions we're developing? Cheers, - Yury Katkov, WikiVote ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] create bugzilla project for PageSchemas, Lingo and Semantic Glossary
Hey Yury, This should be what you're looking for: https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers#To_add_a_project_or_component -Valerie On Tue, May 7, 2013 at 2:11 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! How is it possible to create a project in Bugzilla for the extensions we're developing? Cheers, - Yury Katkov, WikiVote ___ 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] create bugzilla project for PageSchemas, Lingo and Semantic Glossary
Thanks! - Yury Katkov, WikiVote On Tue, May 7, 2013 at 11:18 PM, Valerie Juarez valerie.m.jua...@gmail.comwrote: Hey Yury, This should be what you're looking for: https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers#To_add_a_project_or_component -Valerie On Tue, May 7, 2013 at 2:11 PM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! How is it possible to create a project in Bugzilla for the extensions we're developing? Cheers, - Yury Katkov, WikiVote ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC mentors: selection process
Hi, a little detail I just learned. On 05/06/2013 11:42 AM, Quim Gil wrote: * But you do need to specify which student you select for the 1-2 projects you are co-mentoring. Agree the names with your co-mentors. You can't be in more than 2 projects, and ideally in just one. Google's Melange only allows to define one mentor per project (even if their docs recommend to have two...) This means that for the formal Melange part there will be one mentor appointed, but for all the rest we will consider both co-mentors officially. In any case it is good to make clear who is the primary mentor and this will be the way to reflect it. I will assign mentors in Melange accordingly, asking when it isn't clear who is the primary mentor. Sorry for the glitch, out of our control. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Submit OKCon talks by 24 May - travel subsidies available
http://blog.okfn.org/2013/05/07/okcon-2013-call-for-proposals-out-now/ OKCon is the annual conference for Open Knowledge (Foundation), 17th-18th September 2013, Geneva, Switzerland. It was called OKFest last year. It's a well-attended and well-organized conference for anyone interested in open knowledge, sharing, open hacking, etc. Opportunities for Wikimedia lighting talks, workshops, etc.: - Wikipedia Zero (see Open Development Sustainability track) - Analytics and open data (see Technology, Tools Business) (UserMetrics API? privacy? Limn?) - SOPA/PIPA and related activities (see Evidence Stories) - Hack events: use their hackspace. Teach folks to make bots, gadgets, apps, and Lua templates. Get user testing from other open culture advocates and learn what tools they need. This conference is eligible for subsidy of travel costs -- see Participation Support https://meta.wikimedia.org/wiki/Participation:Support to put in your request. Thanks to Sarah Stierch for the heads-up. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WikiSym + OpenSym 2013: Less than 2 weeks for Community Track Submissions
Call for Submissions: Community Track at WikSym + OpenSym 2013, the Joint International Symposium on Open Collaboration WikiSym, the 9th International Symposium on Wikis and Open Collaboration OpenSym, the 2013 International Symposium on Open Collaboration August 5-7, 2013 | Hong Kong, China http://opensym.org/wsos2013 In-cooperation with ACM SIGWEB and ACM SIGSOFT. Archived in the ACM Digital Library. Community track submission deadlines: * Regular deadline: May 17, 2013 The 2013 Joint International Symposium on Open Collaboration (WikiSym + OpenSym 2013) is the premier conference on open collaboration research and practice, including wikis and social media, Wikipedia, free, libre, and open source software, open access, open data and open government research. WikiSym is in its 9th year and will be complemented by OpenSym, a new conference on open collaboration research and practice and an adjunct to the successful WikiSym conference series. WikiSym + OpenSym 2013 is the first conference to bring together the different strands of open collaboration research and practice, seeking to create synergies and inspire new collaborations between computer scientists, social scientists, legal scholars, and everyone interested in understanding open collaboration and how it is changing the world. Read more about the conference at http://opensym.org/wsos2013/about CALL FOR SUBMISSIONS: COMMUNITY TRACK The following types of papers can be submitted to the community track: * Experience report long and short: A regular presentation slot (30min) will be provided * Workshop proposals: A workshop slot (half-day or full-day) is provided at the conference * Panel proposals: A session (90min) discussion slot for the panel will be provided * Demo proposals: Space and time is provided during the demo session (90min) * Tutorial proposals: A tutorial slot (90min) is provided at the conference Submissions are reviewed by the community track committee for their interest to the WikiSym + OpenSym community in general. For questions about community track submissions, please dont hesitate to get in touch with us: http://opensym.org/wsos2013/about Experience Reports Experience reports are an integral part of the conference program. These are opportunities to discuss how ideas that sound good on paper (and at conferences!) work in real life projects and deployments. Many attendees want to learn from people on the front lines what it is like to do things like start a company wiki, use open collaboration tools in a classroom, or build a political campaign around open collaboration systems. Experience reports are not research papers; their goal is to present experience and reflections on a particular case, and they are reviewed for usefulness, clarity and reflection. Strong experience reports discuss both benefits and drawbacks of the approaches used and clearly call out lessons learned. Reports may focus on a particular aspect of technology usage and practice, or describe broad project experiences. Experience reports can be long (up to 10 pages) or short (up to 4 pages). A long experience report will receive a regular 30 minute presentation slot, a short experience report will receive a shorter presentation slot. Workshops Workshops provide an opportunity for researchers and practitioners to discuss and learn about topics that require in-depth, extended engagement such as new systems, research methods, standards, and formats. Workshop proposals should describe what you intend to do and how your session will meet the criteria described above. It should include a concise abstract, proposed time frame (half-day or full-day), what you plan to do during the workshop, and one-paragraph biographies of all organizers. Workshop proposals will be reviewed and selected for their interest to the community. Each accepted workshop will be provided with a meeting room for either a half or full day. Organizers may also request technology and materials (projector, flip pads, etc). Panels Panels provide an interactive forum for bringing together people with interesting points of view to discuss compelling issues around open collaboration. Panels involve participation from both the panelists and audience members in a lively discussion. Proposals for panels should describe the topics and goals and explain how the panel will be organized and how the Wikisym + OpenSym community will benefit. It should include a concise abstract and one-paragraph biographies of panelists and moderators. Panel submissions will be reviewed and selected for their interest to the community. Each panel will be given a 90-minute time slot. Demos No format is better suited for demonstrating the utility of new collaboration technologies than showing and using them. Demonstrations give presenters an opportunity to show running systems and gather feedback. Demo submissions should provide a setup for
Re: [Wikitech-l] GSoC: next steps
Hi Quim Great News, Youve struck Gold. Cheers to WMF :) On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari harshkothari...@gmail.comwrote: Hi Quim This is fantastic news. Your efforts paid off. Congrats to all. :) Cheers Harsh On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani pragu...@gmail.com wrote: That's really good news! Thanks for sharing, Quim. I'm looking forward to the next steps now. :) Cheers everybody! On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: That's awesome, Quim. Thanks for all your efforts, support, encouragement and guidance so far. The best is yet to come! May you enjoy many more alcohol-free drinks in celebration of future milestones passed. Cheers! Siebrand On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org wrote: Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Harsh Kothari Engineering Trainee, Physical Research Laboratory. Follow Me : harshkothari410 https://twitter.com/harshkothari410/ ___ 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] GSoC: next steps
Hi Quim Great news, Congrats to the entire team On Wed, May 8, 2013 at 2:03 AM, Rahul Maliakkal rahul14...@gmail.comwrote: Hi Quim Great News, Youve struck Gold. Cheers to WMF :) On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi Quim This is fantastic news. Your efforts paid off. Congrats to all. :) Cheers Harsh On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani pragu...@gmail.com wrote: That's really good news! Thanks for sharing, Quim. I'm looking forward to the next steps now. :) Cheers everybody! On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: That's awesome, Quim. Thanks for all your efforts, support, encouragement and guidance so far. The best is yet to come! May you enjoy many more alcohol-free drinks in celebration of future milestones passed. Cheers! Siebrand On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org wrote: Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Harsh Kothari Engineering Trainee, Physical Research Laboratory. Follow Me : harshkothari410 https://twitter.com/harshkothari410/ ___ 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 -- Regards Parth Srivastav ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On 05/07/2013 03:02 PM, Greg Grossmeier wrote: 3) New wmfXX released to 10% of cluster - 10% being something like: test, test2, mediawiki.org, and some of the non-'pedia project sites - Our users do the testing ;-) I was interpreting Leslie as saying 10% cross-cut throughout. I.E. 10% of German Wiktionary, 10% of Japanese Wikinews, 10% of English Wikipedia, 10% of everything. That would mean we would really get wide testing before it rolled out to the 90%. But I don't know which she meant. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On 05/07/2013 04:46 PM, Matthew Flaschen wrote: I was interpreting Leslie as saying 10% cross-cut throughout. I.E. 10% of German Wiktionary, 10% of Japanese Wikinews, 10% of English Wikipedia, 10% of everything. That would mean we would really get wide testing before it rolled out to the 90%. For this to work for user-facing changes, though, there would have to be a clear indicator of which you're on (maybe even an automatic bug report tool), or reports would be confusing. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: next steps
Excellent news! Congratulations to everyone involved! Cheers, David On Tue, May 7, 2013 at 4:36 PM, Parth Srivastav srivastav.pa...@gmail.comwrote: Hi Quim Great news, Congrats to the entire team On Wed, May 8, 2013 at 2:03 AM, Rahul Maliakkal rahul14...@gmail.com wrote: Hi Quim Great News, Youve struck Gold. Cheers to WMF :) On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi Quim This is fantastic news. Your efforts paid off. Congrats to all. :) Cheers Harsh On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani pragu...@gmail.com wrote: That's really good news! Thanks for sharing, Quim. I'm looking forward to the next steps now. :) Cheers everybody! On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: That's awesome, Quim. Thanks for all your efforts, support, encouragement and guidance so far. The best is yet to come! May you enjoy many more alcohol-free drinks in celebration of future milestones passed. Cheers! Siebrand On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org wrote: Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Harsh Kothari Engineering Trainee, Physical Research Laboratory. Follow Me : harshkothari410 https://twitter.com/harshkothari410/ ___ 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 -- Regards Parth Srivastav ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Etiamsi omnes, ego non ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
quote name=Matthew Flaschen date=2013-05-07 time=16:47:32 -0400 On 05/07/2013 04:46 PM, Matthew Flaschen wrote: I was interpreting Leslie as saying 10% cross-cut throughout. I.E. 10% of German Wiktionary, 10% of Japanese Wikinews, 10% of English Wikipedia, 10% of everything. That would mean we would really get wide testing before it rolled out to the 90%. For this to work for user-facing changes, though, there would have to be a clear indicator of which you're on (maybe even an automatic bug report tool), or reports would be confusing. Yeah, that was my first interpretation, but I wasn't sure how it'd work in our situation, so I internally modified and then wrote out the steps I did :-). Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: next steps
Congratulations! Peter. On Tue, May 7, 2013 at 2:01 PM, David Cuenca dacu...@gmail.com wrote: Excellent news! Congratulations to everyone involved! Cheers, David On Tue, May 7, 2013 at 4:36 PM, Parth Srivastav srivastav.pa...@gmail.comwrote: Hi Quim Great news, Congrats to the entire team On Wed, May 8, 2013 at 2:03 AM, Rahul Maliakkal rahul14...@gmail.com wrote: Hi Quim Great News, Youve struck Gold. Cheers to WMF :) On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi Quim This is fantastic news. Your efforts paid off. Congrats to all. :) Cheers Harsh On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani pragu...@gmail.com wrote: That's really good news! Thanks for sharing, Quim. I'm looking forward to the next steps now. :) Cheers everybody! On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: That's awesome, Quim. Thanks for all your efforts, support, encouragement and guidance so far. The best is yet to come! May you enjoy many more alcohol-free drinks in celebration of future milestones passed. Cheers! Siebrand On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org wrote: Google just allocated slots and... On 05/05/2013 09:23 PM, Quim Gil wrote: Based on the feedback received from the mentors we are requesting 11 min 21 max ... WE HAVE GOT 21 SLOTS ALLOWED First: congratulations to everybody involved: mentors AND students. This number reflects succinctly how much someone like Google trusts you. Second: this relaxes a lot our selection process. Between this and OPW we can accommodate many good proposals. Third: still, we will keep standards high as we have done so far. Having 21 slots doesn't mean that we will take them blindly. We will continue asking questions to mentors and students about the feasibility of each proposal and we will consider accepted only those that have all the foundations in place. Last but not least: remember the important point about confidentiality. Now several projects might look pretty obvious candidates but this doesn't authorize anybody to leak / pre-announce our decisions made. Google is still the one that must announce all accepted GSoC projects first. PS: and now, if you don't mind, I'll go get some sophisticated alcohol-free drink to celebrate. Salut! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Harsh Kothari Engineering Trainee, Physical Research Laboratory. Follow Me : harshkothari410 https://twitter.com/harshkothari410/ ___ 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 -- Regards Parth Srivastav ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Etiamsi omnes, ego non ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing
[Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25
A friend of mine is co-organizing a conference about APIs. She asked me if there is someone from Wikimedia or the community who would be interested in participating. It will take place in Parc 55 Hotel in San Francisco on October 23, 24, 25. A bit of information about the conference: APIStrat is a vendor neutral conference, and we are committed to promote API usage/knowledge, and specifically with the event, to build a great program with interesting content and actually create something that is useful for the community. People behind it are Kin Lane (@apievangelist) and 3Scale. Here you can see speakers from the previous event: http://apistrategyconference.com/2013NYC/speakers.php, where they brought together over 350 people. Videos of the previous event can be found here: http://www.infoq.com/api-strategy-practice/ This time we are expecting between 500-600 attendees, and it will be both service providers and API consumers (developers). The previous edition was mostly addressed to providers, but we will have an exclusive track addressed to developers in this edition. They'd like us to: - talk about how much traffic we deal with, how do we do it, who uses our API (or something similar that we think would be of general interest), - participate in the APIs in Government - Towards a Data Commons panel giving the perspective of a non-profit (they aim to have federal, state, education, international, and non-profit representation in this panel). Seems interesting. Is there anyone who'd be interested in giving a talk or participating in a panel there? -- Juliusz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Replacement for tagging in Gerrit
On 06/05/13 18:12, Guillaume Paumier wrote: Hi, On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier ro...@wikimedia.org wrote: Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags. I was wondering: has a decision been made regarding this? I'm resuming work on (notably) identifying/marking noteworthy changes, and I'm interested to know if the tagging system is something that we could possibly take advantage of for this (and if so, what a rough timeline would be :). -- Guillaume Paumier IMHO we should go the git notes route, and at the same time pushing that format upstream, so that when it does get integrated into gerrit, it saves the data in the same way (they are also trying to move to store as many things as possible in git, so it's just a matter of agreeing in the notes format). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC mentors: selection process
On 05/06/2013 01:12 PM, Siebrand Mazeland (WMF) wrote: I would like to provide some feedback, too: The whole process of GSoC was very confusing to me. Students communicated on melange, mediawiki.org http://mediawiki.org, and mailing lists. Some also emailed me and others privately. This scattered communication made me feel I was not able to properly inform myself of the feedback cycles a proposal went through. Melange not having any capabilities to show differences between versions of proposals, does not help - that's unfortunately not something we can directly information. I hope that the number of communication platforms for GSoC communication and documentation can be reduced in the next iteration, to make the process easier to follow to those that are supposed to comment on, evaluate and rank the proposals. You may be interested in this script http://people.freedesktop.org/~cbosdo/melange-mails-to-git It converts melange emails to git, so that should be able to give you a history of the proposal (I haven't tried it). If you miss something on it, try dropping a line to Cedric. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
Leslie Carr wrote: I think this is awesome for features ... but if we're putting work into this, I would love even more to have a clustered a+b production environment, such that 10% of folks are put on the new release (cluster a) and then it gets pushed over to cluster b. Then we can also test performance in a real world environment, and breakages only happen for 10% (PS the 10% number was pulled out of thin air). The opt-in beta is much too limited, as well as being inapplicable to the vast majority of our traffic (logged in users are such a small percentage) to make proper comparisons. You could also see the impact of features on usage for average users. I thought the idea was to not annoy users with unpolished/beta features, unless they've opted in. This seems to be the rationale for mobile. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
