fedorareview September 2012

fedorareview@lists.fedorahosted.org

2 participants
3 discussions

Automatic installation of pre-commit pylint/pep8 hook

by Stanislav Ochotnicky

Alec and me have been talking about automatic usage of pylint/pep8 in git hooks. There are 2 approaches basically: 1. let people read README or some other document and install the hook manually 2. automatically install in one way or the other Because I know people don't read and will forget, we'll check out the repo on different machine etc. So I've taken the 2nd approach in try-commit-hooks branch (last commit)[1] What it does is simple "ln -s '../../git-hooks/pre-commit' .git/hooks/pre-commit". Possible issue: I run it in try-fedora-review because I know we won't forget to run it after checking out new repo. This means automatic installation of hook on systems which don't have any pre-commit hook yet. But since we are running it at a point when someone actually tries to execute our code I don't think it's a big issue (wrt security). Any opinions either way? For the record we now have really nice pylint/pep8 clean repository but problematic commits are appearing because...well me mostly right now :-) [1] http://git.fedorahosted.org/cgit/FedoraReview.git/commit/?h=try-commit-ho... -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

11 years, 6 months

2
1
0 / 0

Release of fedora-review 0.3.0 done, 0.3.1 hotfix on the way

by Stanislav Ochotnicky

fedora-review development team proudly presents :-) Release of fedora-review 0.3.0 [1-3] Summary of changes: * Simplified the template and made it more clear * Support for EPEL-only checks has returned (see -f and -D switches) * Simplified running tests on src.rpm-s ( -rn /path/to/srpm) * Simplest shell plugins you can imagine (see [4] for examples) * Lotsabugs fixed[5] * Improved warnings and error handling * Colors! * Removed integration with bugzilla (man page has suggestion for replacement) * We received a few "complaints" that people were doing automatic reviews without any idea what they are *really* supposed to do. So we now output warning about manual review needed at the end of f-r run (in RED, see Colors!) * We added *a lot* of testing to make sure we don't break stuff accidentaly in the future * Probably a lot of other goodies, which are hard to track because we are bad at keeping nice feature-changelog :-) Why hotfix planed already? There is a small issue with placing plugins currently so it's impossible to write globally accessible shell plugins. And we also accidentaly installed stuff in wrong place..which made the first problem invisible until last moment :-) I plan to let 0.3.0 get into stable and then immediately issue update to 0.3.1 for the aforementioned bug. We'll likely work out a few more kinks along the way. We still have a lot of things planned. In the meantime feel free to drop by #fedora-review on freenode if you have problems with new release (or just file those bugs :-) ) [1] https://admin.fedoraproject.org/updates/FEDORA-2012-14702/fedora-review-0... [2] https://admin.fedoraproject.org/updates/FEDORA-2012-14722/fedora-review-0... [3] https://admin.fedoraproject.org/updates/FEDORA-2012-14663/fedora-review-0... [4] http://git.fedorahosted.org/cgit/FedoraReview.git/tree/scripts [5] https://fedorahosted.org/FedoraReview/query?group=status&milestone=0.3.0 -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

11 years, 6 months

1
0
0 / 0

Branching for release-0.3.0 approaching

by Stanislav Ochotnicky

Hi all, We are reaching a point where we have amassed enough new features and improvements that I plan to branch "release-0.3.0" branch later today when leamas merges his "flags" branch to devel. Notably we have simplified shell-plugin api, numberous check bugfixes and improvements, code cleanups(pyflakes, pylint etc), refactored test cases and returning "EPEL" support (in more generic way). When I branch, any bugfix for 0.3.0 should go into release-0.3.0 branch. Do not be afraid to commit there :-) If you commit your fix into devel, it either won't get into release-0.3.0 or the commit will be duplicated when I merge release back to devel branch. So...commit fixes to release-0.3.0 branch when it is created. Thanks for your attention :-) -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

11 years, 7 months

1
1
0 / 0

← Newer
1
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

fedorareview September 2012