Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 04/11/10 00:35, K. Peachey wrote: They are under a plain text RCS now which is documented on wikitech. If you are talking about [[RCS]], it is 6 years old, written by myself. http://wikitech.wikimedia.org/history/RCS Always read the Wikitech pages with a critical view! -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Ashar Voultoiz wrote: On 04/11/10 00:35, K. Peachey wrote: They are under a plain text RCS now which is documented on wikitech. If you are talking about [[RCS]], it is 6 years old, written by myself. http://wikitech.wikimedia.org/history/RCS Always read the Wikitech pages with a critical view! I think that they are in the svn-private repository. I was surprised when I knew some easy checking steps for sync-file/scapping weren't taken, though. At least now sync-file does a php lint. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
From my position of next to the mozzie bite on the backside of a common breed of antelope in a backwater of a forest obscured in the middle of the night, ie. a total nonentity in the scheme of things. AMEN! MZMcBride. Best birthday wishes for bug 7952, enjoy kindergarten. Sometimes the focus on grafting new trunks, and the experimental breeding of new varieties of trunks has allowed people to forget to water the trees that exist, especially as that is where the current fruit is located. (horrid analogy, but heck wax rhetorical) At this point of time my expectations of fixes are close to zero, and for improvements even less. Even where a developer has a fix ready to go, and the bug is causing issues with work it seems that short of being impolite or hammering down someone's door or being a massive whiney butt that nothing progresses. Example? https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 Anyway, I will crawl back to sWikisource/s my backwater and feed the mosquitoes. Regards, Andrew On 2 Nov 2010 at 19:39, MZMcBride wrote: Rob Lanphier wrote: After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue I have a few comments. You're chomping at the edges again, but not focusing on the larger issue. It's still about _WHO_ is going to be deploying these extensions (or doing general code updates). That question is still unresolved and it's at the heart of the problem. By focusing on the periphery, you're simply needlessly adding paperwork (like the new Deployment queue) without actually accomplishing anything. Read on for a specific example of why deployment is sometimes the sole issue, not review. The issue with focusing on a Review queue is that it puts the focus and emphasis in the wrong place. Nobody cares about getting their code reviewed (per se). They want their code live on the site. Most developers don't care if their code is efficient or not (Domas can speak more to this), they just want to see their hard work in production. That's why they contribute code (or contributed, as the case seems to be nowadays). So the emphasis should be on deployment, a key step of which is code review, to be sure. But putting the focus on review (as though once review is finished, something will magically change) is silly and a poor idea. Regarding extension deployment in general, one of the issues that seems to be overlooked is why it's necessary to require individual sites to request that a feature be enabled. As long as there aren't performance concerns, an extension should be enabled by default. Let's look at a specific example. Here's the current configuration for DynamicPageList: 'wmgUseDPL' = array( // controls loading of DynamicPageList extension 'default' = false, 'dewiktionary' = true, 'enwiktionary' = true, 'incubatorwiki' = true, 'metawiki' = true, 'otrs_wikiwiki' = true, 'srwiki' = true, 'strategywiki' = true, 'wikibooks' = true, 'wikimania2009wiki' = true, 'wikimania2010wiki' = true, 'wikimania2011wiki' = true, 'wikinews' = true, 'wikiquote' = true, 'wikiversity' = true, ), Inexplicably, 'wikisource' = true and 'wikitionary' = true are missing. It also sets the default to false, even though the vast majority of sites could have this extension without any issue. The consequence of this is that the following bugs are currently open asking for this extension to be enabled on a Wikimedia wiki: nlwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=6163 iswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 eswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 bswiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=8240 dewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 enwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 hewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 viwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=8886 plwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=11788 nlwikibooks | https://bugzilla.wikimedia.org/show_bug.cgi?id=15477 frwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=19810 frwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=22250 itwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=25172 This is (literally) a two-line change that would resolve a large amount of old bugs. Of course this doesn't consider that plenty of sites are simply suffering in silence, having not yet understood how to file a shell bug or, more likely, having watched the progress of the other bugs, I would imagine a good number of communities have simply decided to not waste the time filing a bug that's simply going to be ignored. I
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On Tue, Nov 2, 2010 at 7:39 PM, MZMcBride z...@mzmcbride.com wrote: Rob Lanphier wrote: After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue I have a few comments. You're chomping at the edges again, but not focusing on the larger issue. It's still about _WHO_ is going to be deploying these extensions (or doing general code updates). That question is still unresolved and it's at the heart of the problem. By focusing on the periphery, you're simply needlessly adding paperwork (like the new Deployment queue) without actually accomplishing anything. Read on for a specific example of why deployment is sometimes the sole issue, not review. +1. I feel like we're trying to change a workflow when we should be trying to get rid of a backlog. Instead of trying to discuss ways to improve the workflow, we should Just Do It. For example, I don't agree that the code review workflow is a bit awkward. However, when Tim had to leave and we needed people to step up reviewing--we just stepped up; we didn't discuss how to first improve the process. Likewise, I think we should first focus on enabling more people to do merge+scap (maybe the same group who review code?) and get it going on a more often basis. Having a good workflow is great, but I think we should look at the bigger issue first. We can design the best workflow ever, but like code review if only one person does it it all falls apart. The issue with focusing on a Review queue is that it puts the focus and emphasis in the wrong place. Nobody cares about getting their code reviewed (per se). They want their code live on the site. Most developers don't care if their code is efficient or not (Domas can speak more to this), they just want to see their hard work in production. That's why they contribute code (or contributed, as the case seems to be nowadays). So the emphasis should be on deployment, a key step of which is code review, to be sure. But putting the focus on review (as though once review is finished, something will magically change) is silly and a poor idea. IMHO: If minor** code has been reviewed and deemed fit for use, it should be merged almost immediately. Full stop. ** by minor, I mean as long as it doesn't create dependency issues, require schema changes, or are a huge refactor. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On Wed, Nov 3, 2010 at 12:14 PM, Chad innocentkil...@gmail.com wrote: Likewise, I think we should first focus on enabling more people to do merge+scap (maybe the same group who review code?) and get it going on a more often basis. Yes. There are a few people who in my opinion are very capable and in the future it is probably a good idea to give them shell access (Chad, Aryeh?) But for now this is a bit moot point. We're not even close to ready with review, let alone deployment. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
2010/11/3 Bryan Tong Minh bryan.tongm...@gmail.com: Yes. There are a few people who in my opinion are very capable and in the future it is probably a good idea to give them shell access (Chad, Aryeh?) But for now this is a bit moot point. We're not even close to ready with review, let alone deployment. Not for core no, but there are plenty of extensions that could be reviewed and deployed in a shorter period of time, and many config changes ready to go. An issue very much related to this whole extension deployment discussion is the somewhat broader issue of shell requests, which are often about the enabling of certain extensions. I'm gonna make a McBride-esque statement here and say that the sad truth is that the Foundation doesn't seem to care about shell requests at all. Officially, Rob Halsell is responsible for handling shell requests, but from what I know he's been too busy to actually do that more frequently than once in a blue moon, a situation that hasn't changed materially over the past year or so* . JeLuF (Jens) somewhat regularly clears out some of the backlog, but he's a volunteer who's not paid by WMF and has a day job. Shell requests that Rob and Jens feel uncomfortable handling typically get left to rot. I think it's fairly evident from the previous paragraph that shell requests are very low on WMF's priority list and are being neglected right now. If WMF wants to keep its wikis' communities happy (and I'm sure it does), it should dedicate more resources to handling site requests. Sure, we can and should widen the circle of people who can (both technically and socially) deploy things and change configuration settings, and I intend to help with that by documenting our scripts, procedures and pitfalls properly, but that isn't going to solve much if those people don't have time because their real responsibilities take up all their time. Roan Kattouw (Catrope) * Back in December 2009, I had to take a few weeks off for fiscal reasons and spent that time processing some of the backlog, which I remember jokingly characterizing as doing Rob's job because he doesn't have time for it ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On Wed, Nov 3, 2010 at 4:14 AM, Chad innocentkil...@gmail.com wrote: +1. I feel like we're trying to change a workflow when we should be trying to get rid of a backlog. Instead of trying to discuss ways to improve the workflow, we should Just Do It. The problem is agreeing on what it is. Every time I ask for a list of what the requests are, the list generally contains lots of things that many people agree are low priority and/or things that many would agree are too hard to tackle right now. For example, there are plenty of db cleanup exercises in the shell keyword, only some of which have cleanup scripts that would be of any use in addressing. A pared-down list of the most obvious problems to tackle stands a much better chance of actually being completed. That said, I've been looking through the list of shell requests, and it does look like there are plenty there that do just need a little TLC. I believe it's generally Mark's team that would deal with that list, but it might be something that folks on my team can help out with (I know, I'll volunteer *you* to do it) :-P Seriously though, part of the problem is that it might be falling through the cracks because Mark thinks it's my job, and I think it's his job, so I'll follow up on that. Having a good workflow is important, because it helps us see whether or not we're making progress, as opposed to relying on anecdotal evidence that we are/aren't. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Chad wrote: On Tue, Nov 2, 2010 at 7:39 PM, MZMcBride z...@mzmcbride.com wrote: Rob Lanphier wrote: After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue I have a few comments. You're chomping at the edges again, but not focusing on the larger issue. It's still about _WHO_ is going to be deploying these extensions (or doing general code updates). That question is still unresolved and it's at the heart of the problem. By focusing on the periphery, you're simply needlessly adding paperwork (like the new Deployment queue) without actually accomplishing anything. Read on for a specific example of why deployment is sometimes the sole issue, not review. +1. I feel like we're trying to change a workflow when we should be trying to get rid of a backlog. Instead of trying to discuss ways to improve the workflow, we should Just Do It. Maybe have some kind of queue so that the change is an accept click? (That could be done inside subversion or in a completely different way) Currently, there's no way to make the requests easier, even if knowing the exact line to change (eg. a wiki logo, a boolean...) We could provide a patch, but applying it is a bigger hassle than the shell user doing the change himself. Likewise, I think we should first focus on enabling more people to do merge+scap (maybe the same group who review code?) and get it going on a more often basis. Having a good workflow is great, but I think we should look at the bigger issue first. We can design the best workflow ever, but like code review if only one person does it it all falls apart. Maybe. Having more scappers in general would be good. Most configuration changes could be resolved pretty much by anyone. However note that whoever does that also needs the resources to identify when a change has produced a big load and should be reverted. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On Tue, Nov 2, 2010 at 12:51 PM, Rob Lanphier ro...@wikimedia.org wrote: One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites. Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue That page still needs some organization and a process around it to make sure that we're actually looking at the page. However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor. After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue Even then, we're still not done. We have one more step, which is launching the feature on one or more wikis. We could also create another queue page for that. However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this. Okay, maybe I'm missing something, but how about the following process: 1) Feature gets committed to trunk. 2) All commits in trunk get reviewed using Code Review, marking things deferred if they don't need review (e.g., extensions not used by Wikimedia). 3) Once all of trunk is reviewed, it's deployed, preferably at least once per week. This is what we're aiming for, right? If extensions need review, it seems like the most logical way to handle that would be to mark recent commits to the extension in trunk as new, and post a comment asking people to review the whole extension. Reviewers are already routinely looking for all commits in Code Review marked new, so this fits in nicely with the existing procedure. I get the feeling you might be talking about an entirely different problem, though -- maybe I'm confused. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 03/11/10 16:08, Roan Kattouw wrote: snip Not for core no, but there are plenty of extensions that could be reviewed and deployed in a shorter period of time, and many config changes ready to go. Hello, I used to handle a few shell requests myself. Mostly : - enabling extensions already enabled on other wikis - changing / tweaking global variables - deploying minor code changes that solves annoying bugs There is no rocket science in there, it is easy to do BUT it is very time consuming. I probably still have a shell access around but I am not going to do anything without having proper documentation about the 2010 way to handle thing. Years ago, it was: - make sure you have someone to back your *** - edit a global setting file on Zwinger - lint it - verify your change on test.wikipedia.org (or something like that) - ask all Apaches servers to copy the new file through NFS (scap?) - verify the change in production and get ready to revert - stay around in IRC, specially in channels used by the project impacted - udpate bug report - proceed with next request The two issues I had with this were: - The global setting file was not under a version control system which made it hard to track changes and revert mines - Making sure I will not produce a worldwide blank page (it happened once and I can tell you it gives you a huge boost of adrenaline). The positive point is that it was really enjoyable to receives emails from everywhere around the world with the same last word : Thanks. If the process is still roughly the same and that I am still allowed to connect to the server : I am a volunteer to help with handling the shell backlog. :-) -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
I don't think that a seperate keyword for depolyment is all that usefull (although one for security reviews might be nice so its easier to find them), infact it might end up being time consuming and pointless, once a extenstion has been reviewed it should be changed back from need-review to shell so it can be processed when ever one of the shell'ers have time. I also agree with Mz that we should try to standarize extenstions across the WMF wikis where possible and have them global unless there is a very good reason not to, such as DB load, in which case we should try to have them active on as many as possible. On Thu, Nov 4, 2010 at 7:42 AM, Ashar Voultoiz hashar+...@free.fr wrote: The two issues I had with this were: - The global setting file was not under a version control system which made it hard to track changes and revert mines Ashar Voultoiz They are under a plain text RCS now which is documented on wikitech. -Peachey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla keywords for deployment queues?
Hi everyone, One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites. Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue That page still needs some organization and a process around it to make sure that we're actually looking at the page. However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor. After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue Even then, we're still not done. We have one more step, which is launching the feature on one or more wikis. We could also create another queue page for that. However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this. My inclination at this point is to augment the list of keywords on Bugzilla, and use mediawiki.org to document the process, and as a place to stash the magical queries to pull up the right lists. We already have the need-review keyword. I suggest we add two more keywords: need-deploy and need-enabled. Then we add all three keywords to feature requests that need to go through the whole process before being deployed. For example, we'd add all three to this issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=25454 We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the need-review keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with need-deploy and need-enabled. These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with need-enabled only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 2010-11-02, Rob Lanphier wrote: We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the need-review keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with need-deploy and need-enabled. These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with need-enabled only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system. This sounds like a good idea, however I think it would be better to only use a single keyword per state - and as each state is completed it is replaced by the next keyword. Otherwise you cannot just do a keyword search for need-enabled or need-deploy and find just the ones that can actually be processed. Additionally, since this system seems to be targetted at extensions, I think it might be more intuitive to have them labelled as such, i.e.: - extension-need-review - extension-need-deploy - extension-need-enabled Currently I believe the need-review keyword is used for patches that need review aswell as extensions, so using a conflicting namespace could become confusing. Finally, some extensions have a bug report open purely for their review and several open for being enabled/deployed - so this might be a good time to consolidate extension review/enable bugs. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Robert Leverington wrote: This sounds like a good idea, however I think it would be better to only use a single keyword per state - and as each state is completed it is replaced by the next keyword. Otherwise you cannot just do a keyword search for need-enabled or need-deploy and find just the ones that can actually be processed. That's exactly what I thought on reading the proposal. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
The idea of dividing deploy and enable seems strange to me. Only in the case of a feature-flagged bit of core code or extension which has not been deployed yet would this even work, in all other cases deployment is enabling because you've just updated active code. Additionally, the idea of having a division between need-review and need-deploy is counter to the arguments made in D.C. which were that essentially review is a by-product of deployment, not the other way around. Marking something as need-deploy shows reviewers what should be reviewed and merged into the deployment branch. So essentially all we need is a single queue or tag, which indicates this is a revision that affects deployed/to-be-deployed software. An even in this case where I've reduced it to a single tag, someone has to actually mark revs with that tag, but the nature of the tag isn't really based on any single revision, it's based on a resource. Code-review needs a way to tag files and directories rather than just revisions. These resource-tags would be persistent between revisions, allowing us to say show me 'new' revisions that affect 'deployment' files and directories or some such. This would likely be core + some extensions. The more work we have to do over and over (such as adding and managing tags on revisions) the less likely we are to keep it up. - Trevor On 11/2/10 9:51 AM, Rob Lanphier wrote: Hi everyone, One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites. Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue That page still needs some organization and a process around it to make sure that we're actually looking at the page. However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor. After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue Even then, we're still not done. We have one more step, which is launching the feature on one or more wikis. We could also create another queue page for that. However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this. My inclination at this point is to augment the list of keywords on Bugzilla, and use mediawiki.org to document the process, and as a place to stash the magical queries to pull up the right lists. We already have the need-review keyword. I suggest we add two more keywords: need-deploy and need-enabled. Then we add all three keywords to feature requests that need to go through the whole process before being deployed. For example, we'd add all three to this issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=25454 We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the need-review keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with need-deploy and need-enabled. These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with need-enabled only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system. Rob ___ 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] Bugzilla keywords for deployment queues?
On 2010-11-02, Trevor Parscal wrote: The idea of dividing deploy and enable seems strange to me. Only in the case of a feature-flagged bit of core code or extension which has not been deployed yet would this even work, in all other cases deployment is enabling because you've just updated active code. Additionally, the idea of having a division between need-review and need-deploy is counter to the arguments made in D.C. which were that essentially review is a by-product of deployment, not the other way around. Marking something as need-deploy shows reviewers what should be reviewed and merged into the deployment branch. So essentially all we need is a single queue or tag, which indicates this is a revision that affects deployed/to-be-deployed software. I wasn't present in D.C. so can't comment on the arguments made there, but it is my understanding that there are people who are responsible for reviewing code who aren't able/willing to deploy it - so this isn't something that has a binary state. Also, I think it would be useful to document the movement between review, deployment, and enabling - as even if this is done by a single person they might not be able to complete it in one session, and the transparency is nice. An even in this case where I've reduced it to a single tag, someone has to actually mark revs with that tag, but the nature of the tag isn't really based on any single revision, it's based on a resource. Code-review needs a way to tag files and directories rather than just revisions. These resource-tags would be persistent between revisions, allowing us to say show me 'new' revisions that affect 'deployment' files and directories or some such. This would likely be core + some extensions. The more work we have to do over and over (such as adding and managing tags on revisions) the less likely we are to keep it up. Correct me if I'm wrong, but I believe we're talking specifically about completely unreviewed extensions that need looking at entirely - not incrementally. Certainly once an extension has been initially reviewed and deployed, the existing code review system would come in to effect - and I don't think we need to change anything with that at the moment. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Please forgive my point-by-point response. You have some excellent questions and interesting points, and I did not want to loose any context. On 11/2/10 10:46 AM, Robert Leverington wrote: I wasn't present in D.C. so can't comment on the arguments made there, but it is my understanding that there are people who are responsible for reviewing code who aren't able/willing to deploy it - so this isn't something that has a binary state. It's either going to be deployed, and thus needs to be reviewed, merged and scapped or it's not. There's no point to reviewing code that is not going to be merged and scapped, we should never be merging code that has not been reviewed, and we can't scap code that hasn't been merged - reviewed or not. Dividing these tasks is pointless, they either all need to be performed or none of them do. Also, I think it would be useful to document the movement between review, deployment, and enabling - as even if this is done by a single person they might not be able to complete it in one session, and the transparency is nice. It is, that's what the state of the revision is for, it lets us keep track of whether the revision has been reviewed, and if so whether it's a good thing to merge or not (ok vs fixme). Correct me if I'm wrong, but I believe we're talking specifically about completely unreviewed extensions that need looking at entirely - not incrementally. Certainly once an extension has been initially reviewed and deployed, the existing code review system would come in to effect - and I don't think we need to change anything with that at the moment. If that's true, then we may be over-thinking this. The deployment of new features is only a tiny fraction of the review, merge and scap workload. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
2010/11/2 Trevor Parscal tpars...@wikimedia.org: An even in this case where I've reduced it to a single tag, someone has to actually mark revs with that tag, but the nature of the tag isn't really based on any single revision, it's based on a resource. I believe this is why Rob suggested using Bugzilla rather than CodeReview for tracking this. I agree that review and deployment are two parts of a whole and that one doesn't make sense without the other, but I don't think that, of the two, deployment is necessarily the defining part. Sure, it's the ultimate goal, but the review part is where all the work is. Also, having one person review something and another deploy it (typically because the former is not a deployer) is a very small hurdle. The reviewer and primary author would be expected to be around to help put out any fires and possibly to explain how to deploy the feature, but the latter doesn't take longer than a few minutes in most cases. So in practice, I think it's more accurate to say that deployment is a by-product of review than the other way around. *Conceptually*, the latter is true, but *workload-wise*, the former is. As to Rob's suggestion of a need-enabled tag: I don't think that makes any sense. We don't deploy something, then leave it disabled on all wikis, we always enable it somewhere (granted, we sometimes do dark launches or launches on test.wp.o only, but that's always an immediate preparation for enabling it for real). Our current procedure of enabling a feature on a certain set of wikis (possibly all) upon deployment and have requests to extend that set go through the shell request procedure works just fine IMO. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Hi Trevor and Roan Comments inline (Roan, my reply to you is way below) On Tue, Nov 2, 2010 at 10:34 AM, Trevor Parscal tpars...@wikimedia.org wrote: The idea of dividing deploy and enable seems strange to me. Only in the case of a feature-flagged bit of core code or extension which has not been deployed yet would this even work, in all other cases deployment is enabling because you've just updated active code. Perhaps deploy is a little too ambiguous, so I'm open to changes there. Basically, there are three distinct stages that I'm picking out: a. The act of reviewing code for suitability for any purpose (e.g. shipping with MediaWiki tarballs) b. The act of making an extension or modification available in the production branch c. The act of adding the bits of LocalSettings.php (er...InitialiseSettings.php) for enabling on a particular wiki I've named these review, deploy and enable, but if there are better names, that's fine. These three steps all have different operational ramifications, and can exist independently of each other. While one combination doesn't make sense, most have a sensible interpretation. Let's step through the full list of combinations that can exist on an open bug (since there are only eight of them): 0. no tags - probably no code, or incomplete code. Owner: any developer who can code to completion 1. need-review - implementation exists, but probably only of interest for MediaWiki tarballs. Owner: any reviewer 2. need-deploy - reviewed implementation exists, but only in trunk. Needs to be published in deployment branch and scap'd, though there may not be a particular wiki ready for the feature yet, or there's a separate issue filed with the need-enable flag which spells out the conf for a particular wiki. Owner: WMF reviewer 3. need-review + need-deploy - implementation exists, but needs review prior to publication in the deployment branch. Owner: any reviewer 4. need-enable - reviewed implementation exists, is in deployment branch, and has already been scap'd. Just needs to a nudge in the configuration for a particular wiki. Owner: WMF Ops 5. need-enable + need-review - this is probably nonsense. Probably needs all three tags. 6. need-enable + need-deploy - Reviewed implementation exists, but it hasn't been deployed yet. Owner: WMF reviewer 7. need-enable + need-deploy + need-review - there's an unreviewed implementation for a feature which is being requested for deployment on a specific wiki. Owner: any reviewer. Additionally, the idea of having a division between need-review and need-deploy is counter to the arguments made in D.C. which were that essentially review is a by-product of deployment, not the other way around. Marking something as need-deploy shows reviewers what should be reviewed and merged into the deployment branch. Nope, not counter at all. It's very important for the sanity of those trying to keep track (e.g. me) that we distinguish between the deployment-bound stuff that hasn't been reviewed, and the deployment-bound stuff that has been reviewed. I believe the conversation in DC centered around the difference between state 1 and state 3 above, where we agreed that we shouldn't worry about optimizing the process for state 1. However, I don't think anyone can make a convincing argument that the distinction between state 2 and state 3 isn't important. Code-review needs a way to tag files and directories rather than just revisions. These resource-tags would be persistent between revisions, allowing us to say show me 'new' revisions that affect 'deployment' files and directories or some such. This would likely be core + some extensions. The more work we have to do over and over (such as adding and managing tags on revisions) the less likely we are to keep it up. I think it would be cool to have this feature, but I think we can handle this in Bugzilla without new tools. On Tue, Nov 2, 2010 at 12:40 PM, Roan Kattouw roan.katt...@gmail.com wrote: As to Rob's suggestion of a need-enabled tag: I don't think that makes any sense. We don't deploy something, then leave it disabled on all wikis, we always enable it somewhere (granted, we sometimes do dark launches or launches on test.wp.o only, but that's always an immediate preparation for enabling it for real). Our current procedure of enabling a feature on a certain set of wikis (possibly all) upon deployment and have requests to extend that set go through the shell request procedure works just fine IMO. I'll admit that part of the reason why I added need-enable is because I had forgotten about shell, so you're probably right; need-enable is probably unnecessary. However, it looks like our current workflow involves removing that keyword whenever something needs review (see https://bugzilla.wikimedia.org/show_bug.cgi?id=20246 for an example). It seems to me that it is *way* too easy for a request to drop off the radar if the person who reviews it drops the need-deploy
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Rob Lanphier wrote: After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue I have a few comments. You're chomping at the edges again, but not focusing on the larger issue. It's still about _WHO_ is going to be deploying these extensions (or doing general code updates). That question is still unresolved and it's at the heart of the problem. By focusing on the periphery, you're simply needlessly adding paperwork (like the new Deployment queue) without actually accomplishing anything. Read on for a specific example of why deployment is sometimes the sole issue, not review. The issue with focusing on a Review queue is that it puts the focus and emphasis in the wrong place. Nobody cares about getting their code reviewed (per se). They want their code live on the site. Most developers don't care if their code is efficient or not (Domas can speak more to this), they just want to see their hard work in production. That's why they contribute code (or contributed, as the case seems to be nowadays). So the emphasis should be on deployment, a key step of which is code review, to be sure. But putting the focus on review (as though once review is finished, something will magically change) is silly and a poor idea. Regarding extension deployment in general, one of the issues that seems to be overlooked is why it's necessary to require individual sites to request that a feature be enabled. As long as there aren't performance concerns, an extension should be enabled by default. Let's look at a specific example. Here's the current configuration for DynamicPageList: 'wmgUseDPL' = array( // controls loading of DynamicPageList extension 'default' = false, 'dewiktionary' = true, 'enwiktionary' = true, 'incubatorwiki' = true, 'metawiki' = true, 'otrs_wikiwiki' = true, 'srwiki' = true, 'strategywiki' = true, 'wikibooks' = true, 'wikimania2009wiki' = true, 'wikimania2010wiki' = true, 'wikimania2011wiki' = true, 'wikinews' = true, 'wikiquote' = true, 'wikiversity' = true, ), Inexplicably, 'wikisource' = true and 'wikitionary' = true are missing. It also sets the default to false, even though the vast majority of sites could have this extension without any issue. The consequence of this is that the following bugs are currently open asking for this extension to be enabled on a Wikimedia wiki: nlwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=6163 iswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 eswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 bswiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=8240 dewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 enwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 hewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 viwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=8886 plwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=11788 nlwikibooks | https://bugzilla.wikimedia.org/show_bug.cgi?id=15477 frwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=19810 frwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=22250 itwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=25172 This is (literally) a two-line change that would resolve a large amount of old bugs. Of course this doesn't consider that plenty of sites are simply suffering in silence, having not yet understood how to file a shell bug or, more likely, having watched the progress of the other bugs, I would imagine a good number of communities have simply decided to not waste the time filing a bug that's simply going to be ignored. I don't see how this acceptable or desirable, especially given that this is an example of an extension that has been reviewed, but is purely in the deployment arena now. Before someone starts shouting about not considering the performance of large sites, I'll note that according to my numbers, the largest Wiktionary by number of pages (enwiktionary) has this extension enabled.[1] Perhaps there are more complex reasons that this extension can't be enabled elsewhere; I'd certainly be interested in hearing them. I imagine the people waiting years for this extension to be enabled would be interested as well. Call me pessimistic, call me cynical, call me whatever, but take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 and tell how this is acceptable. This bug will celebrate its fourth birthday this month on November 16. Somehow I don't think the Icelandic Wiktionary with its 19,000 pages is going to crash the servers. Perhaps the addition of a Bugmeister will allow this type of problem to get more attention, though I think it's kind of ridiculous that it's going to require an additional full-time staff member to point out
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Trevor Parscal wrote: On 11/2/10 12:40 PM, Roan Kattouw wrote: I agree that review and deployment are two parts of a whole and that one doesn't make sense without the other, but I don't think that, of the two, deployment is necessarily the defining part. Do you mean that there are times we would want to review something that would not be later deployed? - Trevor Reviewing means 'the code has been looked [at some user dependant scrutiny level] by someone other than the author and deemed to be right/acceptable/bug-free'. A user provided patch in bugzilla needs reviewing before adding to trunk*, but that doesn't mean it should be deployed (trivial example: it could be a patch for an extension). A revision on a non WMF-used extension or a branch can be reviewed. If it has passed the process we defined as reviewing (and perhaps had some bugs fixed in doign that), there is no sense to mark is as not reviewed. Sure, the extension/branch may later have a full review if it is going to be deployed. But they should be marked as reviewed if they are. In a perfect world, every bit of code in trunk would be reviewed. That would make for a really sane software. For now, let's struggle for reviewing truunk phase3 and the long dreamed periodical scaps. *In fact, that would have a double review, first by the commiter and then by the revision reviewer, unless it is deferred. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
