Hello, I am again asking if it is possible for me to gain SVN access (I know it probably wouldn't last too long, considering that SVN will be read-only in the (near?) future, but that time is still unknown to us). I frequently use the framework, and I'd like to be able to directly make commits, rather than generating patches to put on the bug tracker, when possible. This would include things such as PEP and typo fixes, as well as improving wikipedia.DataPage. Thanks.
Hazard-SJ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Can somebody with admin rights comment on this request?
IF this user has enough experience I would like to support this (but honestly I do not know... ;)
Thanks and Greetings DrTrigon
On 01.06.2013 06:52, Hazard-SJ wrote:
Hello, I am again asking if it is possible for me to gain SVN access (I know it probably wouldn't last too long, considering that SVN will be read-only in the (near?) future, but that time is still unknown to us). I frequently use the framework, and I'd like to be able to directly make commits, rather than generating patches to put on the bug tracker, when possible. This would include things such as PEP and typo fixes, as well as improving wikipedia.DataPage. Thanks.
Hazard-SJ
_______________________________________________ Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
As a PWB dev I support him (or her?) but we will migrate to gerrit in 6 July and after that (a while after) we can give +2 access to him or her
Best
On 7/4/13, Dr. Trigon dr.trigon@surfeu.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Can somebody with admin rights comment on this request?
IF this user has enough experience I would like to support this (but honestly I do not know... ;)
Thanks and Greetings DrTrigon
On 01.06.2013 06:52, Hazard-SJ wrote:
Hello, I am again asking if it is possible for me to gain SVN access (I know it probably wouldn't last too long, considering that SVN will be read-only in the (near?) future, but that time is still unknown to us). I frequently use the framework, and I'd like to be able to directly make commits, rather than generating patches to put on the bug tracker, when possible. This would include things such as PEP and typo fixes, as well as improving wikipedia.DataPage. Thanks.
Hazard-SJ
_______________________________________________ Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHVflIACgkQAXWvBxzBrDAc7wCfXrD16TgCQw0wqFYvUJnYzJaG QLEAoIbDJppvW2ljNOuRFSFsrYzExprZ =5mvW -----END PGP SIGNATURE-----
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
If you're a member of +2 group, your patches will be merged immediately and you can review others' patches (+1 people) and reject or accept them: http://www.mediawiki.org/wiki/Gerrit/Tutorial#Who_can_review.3F_Gerrit_proje...
Best
On 7/21/13, info@gno.de info@gno.de wrote:
As a PWB dev I support him (or her?) but we will migrate to gerrit in 6 July and after that (a while after) we can give +2 access to him or her
What does this mean: +2 access?
xqt
On 21 July 2013 23:36, Amir Ladsgroup ladsgroup@gmail.com wrote:
If you're a member of +2 group, your patches will be merged immediately and you can review others' patches (+1 people) and reject or accept them:
No, if you are member of the +2 group means you can accept and merge any patches. However, you should *not* merge *your own* patches (unless they are trivial updates, such as i18n or family files), so that other people can comment on it before the patch is merged.
Best, Merlijn
2013/7/22 Merlijn van Deen valhallasw@arctus.nl
No, if you are member of the +2 group means you can accept and merge any patches. However, you should *not* merge *your own* patches (unless they are trivial updates, such as i18n or family files), so that other people can comment on it before the patch is merged.
By this time, trusted committers could commit ("merge") their contributions immediately. How often did we have problems because of this? Is this limitation a solution for a real problem (if so, it's good), or just a new rule to do like MW developers once we are forced to use the same infrastructure?
On 23 July 2013 08:02, Bináris wikiposta@gmail.com wrote:
2013/7/22 Merlijn van Deen valhallasw@arctus.nl
No, if you are member of the +2 group means you can accept and merge any patches. However, you should *not* merge *your own* patches (unless they are trivial updates, such as i18n or family files), so that other people can comment on it before the patch is merged.
By this time, trusted committers could commit ("merge") their contributions immediately. How often did we have problems because of this? Is this limitation a solution for a real problem (if so, it's good), or just a new rule to do like MW developers once we are forced to use the same infrastructure?
It would reduce the number of commits that break things (e.g. the patching story, unicode output on rewrite that broke some stuff, etc). We are already doing post-commit review, but pre-commit review means we can give our users a more stable framework.
Merlijn
Dear Melijn: I think we both know that pywiki devs don't review theirs' commits you can see tons of "new" commits in code review (current system, SVN) and beside that we can have a automated pre-commit review. like a bot that checks If the code doesn't crash and after that let the patch merges and PEP8 bot sounds good to me
Best
On 7/23/13, Merlijn van Deen valhallasw@arctus.nl wrote:
On 23 July 2013 08:02, Bináris wikiposta@gmail.com wrote:
2013/7/22 Merlijn van Deen valhallasw@arctus.nl
No, if you are member of the +2 group means you can accept and merge any patches. However, you should *not* merge *your own* patches (unless they are trivial updates, such as i18n or family files), so that other people can comment on it before the patch is merged.
By this time, trusted committers could commit ("merge") their contributions immediately. How often did we have problems because of this? Is this limitation a solution for a real problem (if so, it's good), or just a new rule to do like MW developers once we are forced to use the same infrastructure?
It would reduce the number of commits that break things (e.g. the patching story, unicode output on rewrite that broke some stuff, etc). We are already doing post-commit review, but pre-commit review means we can give our users a more stable framework.
Merlijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23.07.2013 12:29, Amir Ladsgroup wrote:
Dear Melijn: I think we both know that pywiki devs don't review theirs' commits you can see tons of "new" commits in code review (current system, SVN) and beside that we can have a automated pre-commit review. like a bot that checks If the code doesn't crash and after that let the patch merges and PEP8 bot sounds good to me
Is teher already a "PEP 8 bot" out there? *wonder*
Greetings
someone told about it in here: http://www.mediawiki.org/wiki/Git/Conversion/pywikipedia#Lower_priority I'm not sure this bot really exists but It would be very cool If exists and we use it in gerrit
Best
On 7/25/13, Dr. Trigon dr.trigon@surfeu.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23.07.2013 12:29, Amir Ladsgroup wrote:
Dear Melijn: I think we both know that pywiki devs don't review theirs' commits you can see tons of "new" commits in code review (current system, SVN) and beside that we can have a automated pre-commit review. like a bot that checks If the code doesn't crash and after that let the patch merges and PEP8 bot sounds good to me
Is teher already a "PEP 8 bot" out there? *wonder*
Greetings -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHw4PEACgkQAXWvBxzBrDCgwACePbv8XV6L9XB8ZnAGQREO0t4G j5oAoMz+L2c3YF9L9ZlBkhCHK7eZ/spB =UbqV -----END PGP SIGNATURE-----
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On Jul 25, 2013 4:25 AM, "Dr. Trigon" dr.trigon@surfeu.ch wrote:
Is teher already a "PEP 8 bot" out there? *wonder*
yes, I'm sure we could arrange a Jenkins job to check pep8 compliance.
(or run a test suite or do just about anything else that can made to give standard Unix exit codes)
-Jeremy
Is it always possible to enforce PEP8 with a bot, and no human intervention? Is it always useful to strictly enforce PEP8?
I already saw cases when e.g. the rule for length of lines was broken on purpose and this helped the readability.
PEP8 is basically useful, but it's a proposal/recommendation. For instance, I don't leave a space after # in an inline comment in order to fit in 80 characters. The bot will notice this and put the space, therefore 80 chars are exceeded, and the bot will break the comment or put it into a separate line, which decreases readability. Or how does it work at all?
On 25 July 2013 16:58, Bináris wikiposta@gmail.com wrote:
For instance, I don't leave a space after # in an inline comment in order to fit in 80 characters. The bot will notice this and put the space, therefore 80 chars are exceeded, and the bot will break the comment or put it into a separate line, which decreases readability. Or how does it work at all?
The 'bot' checks the change (or rather: the code base after applying the change) by running pep8 [1], using the parameters we choose (so we can say 'ignore line length'). If this raises any errors, it will set Verified -2, which prevents the patch from being merged.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25.07.2013 16:46, Jeremy Baron wrote:
On Jul 25, 2013 4:25 AM, "Dr. Trigon" <dr.trigon@surfeu.ch mailto:dr.trigon@surfeu.ch> wrote:
Is teher already a "PEP 8 bot" out there? *wonder*
yes, I'm sure we could arrange a Jenkins job to check pep8 compliance.
+1 (for "checking" compliance but not "stricly enforcing" yet)
(or run a test suite or do just about anything else that can made to give standard Unix exit codes)
+2 (IMHO is checking whether the code crashes more important than pep8)
Greetings DrTrigon
----- Original Nachricht ---- Von: Merlijn van Deen valhallasw@arctus.nl An: Pywikipedia discussion list pywikipedia-l@lists.wikimedia.org Datum: 23.07.2013 11:03 Betreff: Re: [Pywikipedia-l] SVN access
On 23 July 2013 08:02, Bináris wikiposta@gmail.com wrote:
By this time, trusted committers could commit ("merge") their contributions immediately. How often did we have problems because of this? Is this limitation a solution for a real problem (if so, it's good), or just a new rule to do like MW developers once we are forced to use the
same
infrastructure?
It would reduce the number of commits that break things (e.g. the patching story, unicode output on rewrite that broke some stuff, etc). We are already doing post-commit review, but pre-commit review means we can give our users a more stable framework.
Merlijn
+1 xqt