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 particular thing you're committing has been previously committed and reverted several times due to ongoing issues.
Folks that have a history of having commits reverted for problems -- please start considering this. It's easier to fix your code before it goes in than after.
-- brion vibber (brion @ wikimedia.org)
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 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 particular thing you're committing has been previously committed and reverted several times due to ongoing issues.
Folks that have a history of having commits reverted for problems -- please start considering this. It's easier to fix your code before it goes in than after.
-- brion vibber (brion @ wikimedia.org)
On Thu, Jul 28, 2011 at 3:09 PM, Peter Kaminski kaminski@istori.com 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 assistance in:
* this mailing list * #mediawiki channel on irc.freenode.net * #wikimedia-dev channel on irc.freenode.net * Code Review comment area on mediawiki.org * bugzilla comment area on bugzilla.wikimedia.org
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.
-- brion
Brion Vibber wrote:
On Thu, Jul 28, 2011 at 3:09 PM, Peter Kaminski kaminski@istori.com 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 assistance in:
- this mailing list
- #mediawiki channel on irc.freenode.net
- #wikimedia-dev channel on irc.freenode.net
- Code Review comment area on mediawiki.org
- bugzilla comment area on bugzilla.wikimedia.org
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 to get comments/review in the CodeReview comments area if you haven't made the commit yet. ;-)
Sometimes the only way people can get their code reviewed is to commit it. This is an old practice. Not to beat a dead horse, but this is all related to the same "patches sit unreviewed" issue, etc.
MZMcBride
On 29/07/11 02:05, MZMcBride wrote: <snip>
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, use something like github.com which offers a friendly interface to comment on patch / fork etc ...
Ashar Voultoiz wrote:
On 29/07/11 02:05, MZMcBride wrote:
<snip> > 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, use something like github.com which offers a friendly interface to comment on patch / fork etc ...
I don't mind if people provides sample in github or pastebin, but don't expect me to comment and follow up there (I might do, but don't take that for granted). Those sites are designed to be the central place, but they are not for our community, so anything there will be less viewed than eg. a CR comment.
Peter Kaminski kaminski@istori.com 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 about my code over and over again. I wrote up the Pre-commit checklist (http://www.mediawiki.org/wiki/Manual:Pre-commit_checklist) to remind myself of the gotcha's that got me and how to avoid them.
And yesterday, after a coding hiatus, I made a few commits, forgot about my pre-commit checklist, and made some of those same bone-headed mistakes.
For people like me, such a list is invaluable. It is like forcing spell-check before sending an email.
Mark.
On Thu, Jul 28, 2011 at 2:49 PM, Brion Vibber brion@wikimedia.org 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 should be solved.
+100. If a bug is really old and has the back-and-forth that Brion describes, there's probably a reason it hasn't been fixed yet. So you should be extra extra careful when trying to fix it :)
And it's even more true if the particular thing you're committing has been previously committed and reverted several times due to ongoing issues.
Yes! If you (or someone) was reverted on a feature, it does not mean you should fix the one or two minor issues that were noticed and then push it right back in again. We're not on a deadline for developing MediaWiki, so I'd encourage people to take the time to do it right. Self- review your code to make sure it all works the way you think (and claim) it does. Ask questions if you're unsure. We've got a great community of really smart developers, pretty much all of whom are more than willing to answer questions in their area(s) of expertise.
-Chad
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:
Domas
wikitech-l@lists.wikimedia.org