improving gerrit workflow

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

improving gerrit workflow

Moritz Schubotz-2
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: [hidden email]
  Web: http://www.physikerwelt.de
  Skype: Schubi87
  ICQ: 200302764
  Msn: [hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: improving gerrit workflow

Chad
On Sun, Feb 17, 2013 at 9:22 PM, Moritz Schubotz <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: improving gerrit workflow

Antoine Musso-3
In reply to this post by Moritz Schubotz-2
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.


--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l