I've got that page on my watchlist and it doesn't change often. Checking it when it does is easy. The problem is finding someone who a) is willing to be that person and b) is trusted enough to make the decision to grant or not.
-Chad
On Oct 14, 2009 11:49 AM, "Aryeh Gregor" <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com> wrote:
On Wed, Oct 14, 2009 at 11:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote: > Checking some... Not if it doesn't change on most days . . . load it up with all the sites you check every day and take ten seconds to see if there are any new requests. Or subscribe to the RSS feed, or whatever you want.
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia....
Hoi, Checking something every day IS expensive. Thanks, GerardM
I have heard some people use something called watchlist to do that. Moreover, they don't need to check it. They get an email when the page changes (but should they miss a notification, they won't get more).
Chad wrote:
I've got that page on my watchlist and it doesn't change often. Checking it when it does is easy. The problem is finding someone who a) is willing to be that person and b) is trusted enough to make the decision to grant or not.
-Chad
Expand CodeReview to handle feature requests and promote when people get enough supports? That would replicate the move in which, first bureucrats, then stewards were created.
On 10/14/09 10:30 AM, Platonides wrote:
Expand CodeReview to handle feature requests and promote when people get enough supports? That would replicate the move in which, first bureucrats, then stewards were created.
Throwing in a huge number of committers at once is problematic as well since that means more time is going to be spent in post-commit review; new committers generally need some time to really ramp up.
Pre-commit review -- eg checking then committing patches -- takes longer, but is safer. It's a balance that needs to be struck and yeah, it's tricky.
Ideally we'd have a much faster, cleaner pre-commit review pipeline and keep the number of general core committers relatively small. (We wouldn't have nearly as many committers as we do -- over 100! -- if patch review were consistent.)
-- brion
On Wed, Oct 14, 2009 at 6:09 PM, Brion Vibber brion@pobox.com wrote:
Throwing in a huge number of committers at once is problematic as well since that means more time is going to be spent in post-commit review; new committers generally need some time to really ramp up.
Pre-commit review -- eg checking then committing patches -- takes longer, but is safer. It's a balance that needs to be struck and yeah, it's tricky.
Ideally we'd have a much faster, cleaner pre-commit review pipeline and keep the number of general core committers relatively small. (We wouldn't have nearly as many committers as we do -- over 100! -- if patch review were consistent.)
Given the existence of wmf-deployment and release branches, though, the distinction between pre-commit and post-commit review seems mostly academic. MediaWiki trunk is pretty much just a place where people believed to be reasonably sane can throw up code for broader review and inspection prior to actual deployment or release. Having a central trunk with lots of committers reduces problems with merge conflicts and gets patches tested earlier in the development process, compared to a pre-commit-review system.
Post-commit review is a big problem for us, but it's because nobody likes reviewing code and not many people are really qualified to, anyway. Places like Mozilla and Linux that do pre-commit review have a much larger number of developers paid to do review, as far as I can tell. From what I've seen, with Mozilla, you assign your patch to someone and they actually look at it fairly quickly. Linux is its own crazy world, which we need not even talk about as long as we're not using a DVCS, but a lot of people there (like Linus Torvalds) spend much more time reviewing than coding, as I understand it.
As long as we have only a couple of people who are a) entrusted with reviewing code for deployment/release and b) paid to do so, I imagine review will remain a problem. Shutting out new committers is one way to mitigate it, but it's not a very healthy way for MediaWiki. At this point, I'd imagine one person paid to do full-time review would be enough to get us back to a reliable weekly deployment schedule with time left over, even if we add a bunch more committers.
Then again, I say all this as someone who hasn't even had time to look at the last 1000+ commits. :(
On Wed, Oct 14, 2009 at 3:51 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Oct 14, 2009 at 6:09 PM, Brion Vibber brion@pobox.com wrote:
Throwing in a huge number of committers at once is problematic as well since that means more time is going to be spent in post-commit review; new committers generally need some time to really ramp up.
Pre-commit review -- eg checking then committing patches -- takes longer, but is safer. It's a balance that needs to be struck and yeah, it's tricky.
Ideally we'd have a much faster, cleaner pre-commit review pipeline and keep the number of general core committers relatively small. (We wouldn't have nearly as many committers as we do -- over 100! -- if patch review were consistent.)
Given the existence of wmf-deployment and release branches, though, the distinction between pre-commit and post-commit review seems mostly academic. MediaWiki trunk is pretty much just a place where people believed to be reasonably sane can throw up code for broader review and inspection prior to actual deployment or release. Having a central trunk with lots of committers reduces problems with merge conflicts and gets patches tested earlier in the development process, compared to a pre-commit-review system.
Post-commit review is a big problem for us, but it's because nobody likes reviewing code and not many people are really qualified to, anyway. Places like Mozilla and Linux that do pre-commit review have a much larger number of developers paid to do review, as far as I can tell. From what I've seen, with Mozilla, you assign your patch to someone and they actually look at it fairly quickly. Linux is its own crazy world, which we need not even talk about as long as we're not using a DVCS, but a lot of people there (like Linus Torvalds) spend much more time reviewing than coding, as I understand it.
As long as we have only a couple of people who are a) entrusted with reviewing code for deployment/release and b) paid to do so, I imagine review will remain a problem. Shutting out new committers is one way to mitigate it, but it's not a very healthy way for MediaWiki. At this point, I'd imagine one person paid to do full-time review would be enough to get us back to a reliable weekly deployment schedule with time left over, even if we add a bunch more committers.
Then again, I say all this as someone who hasn't even had time to look at the last 1000+ commits. :(
I'd agree with Aryeh. It makes sense to have most development work occur in the SVN with relatively light standards for allowing commit access. It increases the eyeballs and keeps everyone on the same page. One needs a visible and intelligible process for managing the development of new features (which has as much to do with social engineering and management as it does with technology) but much of the current development work to fix bugs and make small improvements is not really a big deal. And to be honest, there aren't that many commits per day.
However, we could greatly improve the process by having more automated tools providing developer feedback. There is no reason we couldn't check the performance and behavior of every code revision. Measuring things like execution time, memory load, SQL calls, and other variables coupled to tests looking for differences in rendered page appearance, could catch code with poor performance or unexpected behavior earlier and without requiring a manual review by the experts. Obviously expert review will always be part of the process, but a lot of things can be done to make their lives easier. And that in turn should help reduce the review bottlenecks. WMF's plans to hire someone to run the review process will also make a big difference.
-Robert Rohde
Brion Vibber wrote:
On 10/14/09 10:30 AM, Platonides wrote:
Expand CodeReview to handle feature requests and promote when people get enough supports? That would replicate the move in which, first bureucrats, then stewards were created.
Throwing in a huge number of committers at once is problematic as well since that means more time is going to be spent in post-commit review; new committers generally need some time to really ramp up.
Pre-commit review -- eg checking then committing patches -- takes longer, but is safer. It's a balance that needs to be struck and yeah, it's tricky.
Ideally we'd have a much faster, cleaner pre-commit review pipeline and keep the number of general core committers relatively small. (We wouldn't have nearly as many committers as we do -- over 100! -- if patch review were consistent.)
For contributing extensions, I think we could head towards having hundreds of committers, but I think we need to tighten up the security a bit, so that we can add lots of new committers without so much anxiety.
For instance, with a few minutes of research, I found a way that allows anyone with sillyshell access to destroy the whole repository. Seeing as we don't have any regular backup for it, that should probably be considered a bad thing.
Wikimedia has finally stopped checking out the entire extensions directory and exposing it to the web, but there might be other sites out there still doing the same insecure practice. It may make sense to split off an "extensions-contrib" directory where unreviewed extensions can be put, with less chance of jeopardising the security of servers.
Then there's the issue of commits to sensitive directories like the release branches and wmf-deployment. "Please don't" hasn't really proven to be scalable, because various people think it doesn't apply to them for various reasons, or were never told the policy in the first place. We don't have solid procedures in place that would protect us from server compromise by a disguised insecure commit to a branch.
In the short term, I propose to do the following: * Fix the login system * Implement three levels of access control using authz: * Extensions only (hundreds of users) * Core (~50 users) * Sensitive branches (~5 users)
-- Tim Starling
On Thu, Oct 15, 2009 at 1:28 PM, Tim Starling tstarling@wikimedia.org wrote:
...
How about a seperate SVN system that houses non "Offical" extenstions and then anything used on the WMF servers stay on the main one?
* "K. Peachey" p858snake@yahoo.com.au [Thu, 15 Oct 2009 14:28:18 +1000]:
On Thu, Oct 15, 2009 at 1:28 PM, Tim Starling
wrote:
...
How about a seperate SVN system that houses non "Offical" extenstions and then anything used on the WMF servers stay on the main one?
Also, what is required to make the extension "Official"? I guess that the "Official" one has to be useful and reviewed by core developer? Perhaps, there's something more to confirm?
I am hoping to commit my extension soon after cleaning of the code. I expect that translatewiki can be used to have localization, also maybe an increase of bug reports rate (I can't test the every possible case of usage personally). I am in the list, but still haven't tried whether svn+ssh will work on me, due to lack of time. Dmitriy
On Thu, Oct 15, 2009 at 3:55 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
Also, what is required to make the extension "Official"? I guess that the "Official" one has to be useful and reviewed by core developer? Perhaps, there's something more to confirm?
One that is used on a WMF wiki?
-Peachey
* "K. Peachey" p858snake@yahoo.com.au [Thu, 15 Oct 2009 18:57:23 +1000]:
On Thu, Oct 15, 2009 at 3:55 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
Also, what is required to make the extension "Official"? I guess
that
the "Official" one has to be useful and reviewed by core developer? Perhaps, there's something more to confirm?
One that is used on a WMF wiki?
Ok, I see. Dmitriy
I wrote:
In the short term, I propose to do the following:
- Fix the login system
- Implement three levels of access control using authz:
- Extensions only (hundreds of users)
- Core (~50 users)
- Sensitive branches (~5 users)
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
For the file format, see:
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
-- Tim Starling
On 15/10/2009, at 8:40 AM, Tim Starling wrote:
I wrote:
In the short term, I propose to do the following:
- Fix the login system
- Implement three levels of access control using authz:
- Extensions only (hundreds of users)
- Core (~50 users)
- Sensitive branches (~5 users)
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
You've left off a few users (such as Aaron and I) with shell access, and who should be able to deploy code revisions by copying them to the wmf-deployment branch.
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
Andrew Garrett wrote:
On 15/10/2009, at 8:40 AM, Tim Starling wrote:
I wrote:
In the short term, I propose to do the following:
- Fix the login system
- Implement three levels of access control using authz:
- Extensions only (hundreds of users)
- Core (~50 users)
- Sensitive branches (~5 users)
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
You've left off a few users (such as Aaron and I) with shell access, and who should be able to deploy code revisions by copying them to the wmf-deployment branch.
I added everyone with shell access to the release group.
-- Tim Starling
On Thu, Oct 15, 2009 at 6:41 AM, Tim Starling tstarling@wikimedia.org wrote:
Andrew Garrett wrote:
On 15/10/2009, at 8:40 AM, Tim Starling wrote:
I wrote:
In the short term, I propose to do the following:
- Fix the login system
- Implement three levels of access control using authz:
* Extensions only (hundreds of users) * Core (~50 users) * Sensitive branches (~5 users)
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
You've left off a few users (such as Aaron and I) with shell access, and who should be able to deploy code revisions by copying them to the wmf-deployment branch.
I added everyone with shell access to the release group.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Looks good to me. Core could possibly be trimmed down a bit, but certainly a good start.
-Chad
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
For the file format, see:
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbased authz.html
If we use mod_authz_svn, doesn't that mean we can't use ssh keys anymore?
We could use SSL client authentication, and require users to send their public key; however, not all clients support SSL client authentication yet. There are web server issues with SSL client auth as well.
Or are we going to switch to passwords?
V/r,
Ryan Lane
Lane, Ryan wrote:
Proposed authz file at:
http://svn.wikimedia.org/authz
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
For the file format, see:
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbased authz.html
If we use mod_authz_svn, doesn't that mean we can't use ssh keys anymore?
No, it'll still work exactly the same. SSH invokes svnserve which reads svnserve.conf which specifies the location of the authz file, which is in the same file format as the one used by mod_authz_svn. This is mentioned in the opening sentence of the manual reference I linked to.
-- Tim Starling
On Thu, Oct 15, 2009 at 3:40 AM, Tim Starling tstarling@wikimedia.org wrote:
Proposed authz file at:
This seems to say that only the release group can backport things to branches. Does it make more sense to allow core to backport to branches, but require release to tag them? I have some commits to branches that I think were legitimate, personally. :)
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
I think it's okay to keep it at that level. Narrowing it down would get rid of useful contributions, unless people are actually going to start reviewing Bugzilla patches. There's currently no way to reliably get your patches reviewed except committing it and forcing review by whoever wants to deploy. (And even that doesn't always work for large changes.)
I'm not actually sure what problem is being solved by restricting commits to core, though. If someone can commit a backdoor without anyone noticing, then they could almost as easily get one committed from a Bugzilla patch without anyone noticing. Except that no one looks at Bugzilla patches, but in that case the argument becomes "less changes means less security risk", which is throwing out the baby with the bathwater. Extensions authors might have occasion to adjust core code occasionally; that's one of the advantages of being able to commit your extension to Wikimedia SVN.
Restricting commits to wmf-deployment and tags (and maybe branches) makes sense, certainly. But I don't see the point in an enforced extensions/core distinction. Especially if extensions used on Wikimedia are counted as extensions and not core!
Aryeh Gregor wrote:
I'm not actually sure what problem is being solved by restricting commits to core, though. If someone can commit a backdoor without anyone noticing, then they could almost as easily get one committed from a Bugzilla patch without anyone noticing. Except that no one looks at Bugzilla patches, but in that case the argument becomes "less changes means less security risk", which is throwing out the baby with the bathwater. Extensions authors might have occasion to adjust core code occasionally; that's one of the advantages of being able to commit your extension to Wikimedia SVN.
I think the point is on giving write access to untrusted people that only want to mantain its insecure pet extension. A commit to core by any of them *should* raise quite more eyebrows than a commit by a core dev, getting a deeper scrutiny, but some additional layer isn't necessarily bad. It's not too friendly to take back someone with svn access to bugzilla for a tiny core edit, though. The typical case for an extension author to touch core would be adding a hook, but he may also want to start contributing at an higher level.
If a vulnerability gets committed, it would be for ignorance, not for malice. Yesterday's issue with bug 21140 cames to me, where code got via several hops until svn. OTOH if badguy tried to trick us, he would have problems to get someone for reviewing and committing it.
ialex has been doing a good work recently, and there are some periods when bugs are reviewed easier than others, but once a bug has crossed the head, the tail can be quite long (perhaps becasue they are the hardest?).
But I don't see the point in an enforced extensions/core distinction. Especially if extensions used on Wikimedia are counted as extensions and not core!
The same permissions as core should be set to them as they get enabled.
PS: I still have a number of patches awaiting on BZ in case someone feels remorses for this thread. :)
Aryeh Gregor wrote:
On Thu, Oct 15, 2009 at 3:40 AM, Tim Starling tstarling@wikimedia.org wrote:
Proposed authz file at:
This seems to say that only the release group can backport things to branches. Does it make more sense to allow core to backport to branches, but require release to tag them? I have some commits to branches that I think were legitimate, personally. :)
Yes, I know you made commits to branches, several people did.
tstarling@shimmer:~/src/mediawiki/branches/REL1_15/phase3$ svn log --stop-on-copy --xml `mi` | xmlstarlet sel -t -m //author -v . -n | sort | uniq -c | sort -rn 31 tstarling 3 siebrand 2 simetrical 2 ialex 1 shinjiman 1 demon 1 catrope 1 brion
I had to review them all to try to work out why the developer thought each patch was important enough to be backported, despite in most cases the lack of a meaningful commit message. It would have been much easier if everyone could have listed their backports on the release tracking bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18629
Or alternatively, tagged the revisions on CodeReview and added a comment.
The @core group there is just all 76 people who have committed to /trunk/phase3 in the last 12 months. It may need some refinement.
I think it's okay to keep it at that level. Narrowing it down would get rid of useful contributions, unless people are actually going to start reviewing Bugzilla patches. There's currently no way to reliably get your patches reviewed except committing it and forcing review by whoever wants to deploy. (And even that doesn't always work for large changes.)
By that logic, keeping it at that level would lose useful contributions too, since I could have used two years instead of one for the time period scanned and made a larger list.
But I don't think your logic is correct, because I think active committers are more likely to be able to interact with the core developer community, contacting someone by IRC or email to get their patch committed.
And it's not fair to say that nobody has been reviewing patches on Bugzilla. Look at the history of phase3/CREDITS. Demon especially has been doing some good work in this area.
I'm not actually sure what problem is being solved by restricting commits to core, though. If someone can commit a backdoor without anyone noticing, then they could almost as easily get one committed from a Bugzilla patch without anyone noticing. Except that no one looks at Bugzilla patches, but in that case the argument becomes "less changes means less security risk", which is throwing out the baby with the bathwater. Extensions authors might have occasion to adjust core code occasionally; that's one of the advantages of being able to commit your extension to Wikimedia SVN.
Restricting commits to wmf-deployment and tags (and maybe branches) makes sense, certainly. But I don't see the point in an enforced extensions/core distinction. Especially if extensions used on Wikimedia are counted as extensions and not core!
The point is to encourage interaction between core and extension developers and to distribute the daunting task of code review.
The problem is the difficulty of keeping the core at an appropriate level of quality for its high visibility. The proposed solution is to encourage active core developers to have a sense of responsibility for core quality, by positioning them in a role which services the wider extension developer community.
In the current structure, the risk we run when we approve commit access is that the developer will start committing lots of clueless revisions to phase3. Such people demand detailed review and mentoring. In the current structure, we can only deal with a few such people at a time, otherwise quality suffers.
The time invested by senior developers in that process is large enough that it makes sense to restrict commit access to only the people who are talented and serious enough to stick around for long enough that our investment in mentoring will pay off. By encoding the core/extensions split as an enforced policy, we can remove that requirement for extension developers, thus expediting their request for commit access.
-- Tim Starling
On Wed, Oct 14, 2009 at 8:28 PM, Tim Starling tstarling@wikimedia.org wrote: <snip>
Wikimedia has finally stopped checking out the entire extensions directory and exposing it to the web, but there might be other sites out there still doing the same insecure practice. It may make sense to split off an "extensions-contrib" directory where unreviewed extensions can be put, with less chance of jeopardising the security of servers.
<snip>
A similar approach, with slightly different nomenclature, would be to create an "extensions-approved" directory restricted to core contributors for the 60 odd extensions used by Wikimedia.
http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia
Obviously any extension used on the live site has essentially the same security implications as the core code. As there are already a few hundred extensions in SVN, I think it is fair to regard many existing extensions in SVN as contribs that have never been studied in detail.
-Robert Rohde
wikitech-l@lists.wikimedia.org