Ashar Voultoiz wrote:
> On 29/07/11 02:05, MZMcBride wrote:
>
>> Sometimes the only way people can get their code reviewed is to commit it.
>
> In a BRANCH! :-)
>
> Although, you will have to find out someone to review your changes, but
> at least it saves you the hassle of being reverted on sight
Peter Kaminski writes:
> Great reminder, Brion.
>
> Do any devs have suggestions of what to do instead of checking in broken
> code? Or even code you're not sure about? Tips, reminders, places/ways
> to ask for help?
Last year, I was a new committer and was getting some of the same
complaints
On 29/07/11 20:59, Dan Collins wrote:
> On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz wrote:
>> They can still commit their broken code but NOT IN TRUNK :)
>
> Many developers (me) don't understand what there is other than trunk.
> I'm aware of tags and branches, and vaguely recall someone being
- Original Message -
> From: "Dan Collins"
> On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz
> wrote:
> > They can still commit their broken code but NOT IN TRUNK :)
>
> Many developers (me) don't understand what there is other than trunk.
> I'm aware of tags and branches, and vaguely r
You're correct that Mediawiki tags and release branches (REL1_xx) shouldn't
usually be touched. However you are more than welcome to create your own
development branches.
-Chad
On Jul 29, 2011 12:00 PM, "Dan Collins" wrote:
> On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz
wrote:
>> They can sti
On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz wrote:
> They can still commit their broken code but NOT IN TRUNK :)
Many developers (me) don't understand what there is other than trunk.
I'm aware of tags and branches, and vaguely recall someone being
yelled at for changing one of those, and was
On 29/07/11 04:23, K. Peachey wrote:
> What about for people that want to commit some broken code to get eyes
> onto or someone else might want it finish if, how about they commit it
> and clearly mark that its broken and its so that people can look/work
> at it then immediately revert it? (Which I
- Original Message -
> From: "Brion Vibber"
> > [MZM:]
> > Someone uploads a patch to Bugzilla and doesn't use IRC (and so they
> > can't nag for review there). What's your recommendation for that scenario?
>
> Improve bug & patch review responsiveness so they get our feedback on
> bugzil
Hi!
just wanted to point out that there's open-source software for code-review that
is designed for this (code reviews before commit), it supports both SVN and Git:
http://phabricator.org/
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.o
On 29/07/11 04:57, Brion Vibber wrote:
>> Someone uploads a patch to Bugzilla and doesn't use IRC (and so they can't
>> > nag for review there). What's your recommendation for that scenario?
> Improve bug& patch review responsiveness so they get our feedback on
> bugzilla (and thus in their email
On 29/07/11 02:05, MZMcBride wrote:
> Sometimes the only way people can get their code reviewed is to commit it.
In a BRANCH! :-)
Although, you will have to find out someone to review your changes, but
at least it saves you the hassle of being reverted on sight.
If you don't have commit access
I suggest to add a new bugzilla category "Request for Comments" for
discussions of not-yet-committed-code and similar things, where label
"enhancement" or "normal" would not be suited..
Filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=30111 - where
this proposal itself can now be discusse
On Jul 28, 2011 7:20 PM, "MZMcBride" wrote:
>
> Brion Vibber wrote:
> > In many cases these are patches for a bug, in which case bugzilla is a
good
> > place to stash an updated patch version to be looked over. (In a DVCS
> > workflow this might be a branch on a fork rather than a flat patch, but
What about for people that want to commit some broken code to get eyes
onto or someone else might want it finish if, how about they commit it
and clearly mark that its broken and its so that people can look/work
at it then immediately revert it? (Which I have seen done a couple of
times in the past
Brion Vibber wrote:
> In many cases these are patches for a bug, in which case bugzilla is a good
> place to stash an updated patch version to be looked over. (In a DVCS
> workflow this might be a branch on a fork rather than a flat patch, but the
> principle is the same and we *ought* to be able t
On Jul 28, 2011 6:01 PM, "MZMcBride" wrote:
>
> Brion Vibber wrote:
> > On Thu, Jul 28, 2011 at 3:09 P
> > If you're not sure, those are *all* better places to try something out
than
> > committing directly to trunk without talking to anybody or getting any
> > feedback.
>
> It's a bit difficult t
Brion Vibber wrote:
> On Thu, Jul 28, 2011 at 3:09 PM, Peter Kaminski wrote:
>> Do any devs have suggestions of what to do instead of checking in broken
>> code? Or even code you're not sure about? Tips, reminders, places/ways
>> to ask for help?
>
> Here are a few good places to ask for assist
On Thu, Jul 28, 2011 at 2:49 PM, Brion Vibber wrote:
> Please don't commit broken code to trunk; if you think your code may be
> broken please consider asking about it first. This is especially true if
> you're committing a fix for a bug that's gone back and forth over the years
> about how it sho
On Thu, Jul 28, 2011 at 3:09 PM, Peter Kaminski wrote:
> Great reminder, Brion.
>
> Do any devs have suggestions of what to do instead of checking in broken
> code? Or even code you're not sure about? Tips, reminders, places/ways
> to ask for help?
>
Here are a few good places to ask for assis
Great reminder, Brion.
Do any devs have suggestions of what to do instead of checking in broken
code? Or even code you're not sure about? Tips, reminders, places/ways
to ask for help?
Pete
On 7/28/11 14:49 PM, Brion Vibber wrote:
> Please don't commit broken code to trunk; if you think your c
Hi all --
Please don't commit broken code to trunk; if you think your code may be
broken please consider asking about it first. This is especially true if
you're committing a fix for a bug that's gone back and forth over the years
about how it should be solved.
And it's even more true if the part
21 matches
Mail list logo
