Hi,
in the next version of the code review system, a way to classify the type of change would be great. Maybe the trac-system would a good inspiration. i.e. a critical bug may be more important to review soon than a new feature. Furthermore running stylize.php remotely might be helpful to avoid that people waste their time with those formal aspects.
Best regards
physikerwelt
-- Mit freundlichen Grüßen Moritz Schubotz
Telefon (Büro): +49 30 314 22784 Telefon (Privat):+49 30 488 27330 E-Mail: schubotz@itp.physik.tu-berlin.de Web: http://www.physikerwelt.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
On Sun, Feb 17, 2013 at 9:22 PM, Moritz Schubotz physik@physikerwelt.de wrote:
Hi,
in the next version of the code review system, a way to classify the type of change would be great.
Well, we can use topics for this. Freeform tagging would be nice, but that's further down on the roadmap.
Maybe the trac-system would a good inspiration. i.e. a critical bug may be more important to review soon than a new feature.
I hate trac :p
Furthermore running stylize.php remotely might be helpful to avoid that people waste their time with those formal aspects.
Can't do that--for the same reason we can't do automatic whitespace fixing. Changing a commit would alter the sha1, which would mean people's clones wouldn't match up with the remote (eg: you push a change, merge it, and git pull wouldn't be able to just fast forward)
-Chad
Le 18/02/13 03:22, Moritz Schubotz wrote:
in the next version of the code review system, a way to classify the type of change would be great. Maybe the trac-system would a good inspiration. i.e. a critical bug may be more important to review soon than a new feature.
Hello,
In our homegrown system, we used to be able to add keywords on changes. That feature is more or less tracked in bugzilla:
Establish suitable short-term replacement for important code review tags https://bugzilla.wikimedia.org/show_bug.cgi?id=38239
We mostly use Gerrit has a way to attach an identifier to a change. The prioritization is handled at the bug level and hence using the fields in Bugzilla. Note that some critical bugs might be less important than a new feature :-]
Furthermore running stylize.php remotely might be helpful to avoid that people waste their time with those formal aspects.
If I remember correctly, stylize.php is mostly handling whitespaces and comments which are neither really important. We can not really alter the submitted patchset (that will change the commit sha1) which left us with running it in Jenkins after the change as merged. I believe most of stylize.php reporting capabilities are already in our PHP_CodeSniffer standard.
wikitech-l@lists.wikimedia.org