On Jul 28, 2011 6:01 PM, "MZMcBride" z@mzmcbride.com 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 to get comments/review in the CodeReview comments
area
if you haven't made the commit yet. ;-)
If you made the commit and received feedback about it in CR, continuing discussion there before making an amended commit -- especially when fixing something that was reverted -- seems a good fit.
That can save committers and reviewers alike from the pain of a second or third breakage+revert/rushed fix cycle.
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 to do ok with patches -- 20+ years of free/open source devs have reviewed, iterated, and landed or clearly rejected changes this way, including us!)
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.
I find that reverting and yelling at people for broken commits is *not* a sustainable practice, even if it's old.
We need to show that we can hold up our end of the bargain: give timely feedback, keep up with both commits already done and with patches coming in through other channels.
It's a process, and we're all still feeling our way along.
Part of that is improving reviewer responsiveness to commits after they come in. Part is improving responsiveness to uncommitted patches.
And part of it is making sure that we send people and code through the review paths that will best fit them.
-- brion
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 to do ok with patches -- 20+ years of free/open source devs have reviewed, iterated, and landed or clearly rejected changes this way, including us!)
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? This mailing list? If so, is there a concern about diffused responsibility?
I haven't seen many requests for patch review on this list in the past, as far as I remember. A separate list or a direct line to the Bugmeister might make more sense, though in an ideal world, people wouldn't need to nag at all...
The reality is that uploading a patch on Bugzilla should be sufficient to trigger review. At that point, the uploader has put in his or her share of the work. But very often uploading a patch or even prodding in bug comments leads to no response at all for months or years or ever. Sometimes you'll get lucky and someone on the CC list will be able to help you (or find someone to help you). Or you'll get lucky and someone will notice the bug in #mediawiki and take an interest. It's a crapshoot, though. And it seems to me that a lot of the people who commit patches are the same people who don't use IRC or don't know who to nag if they do.
I'm not trying to be negative here, though it may come off that way. I'm just trying to understand how people are supposed to be able to help currently and going forward.
MZMcBride
On Jul 28, 2011 7:20 PM, "MZMcBride" z@mzmcbride.com 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
the
principle is the same and we *ought* to be able to do ok with patches --
20+
years of free/open source devs have reviewed, iterated, and landed or clearly rejected changes this way, including us!)
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).
This
mailing list? If so, is there a concern about diffused responsibility?
I haven't seen many requests for patch review on this list in the past, as far as I remember. A separate list or a direct line to the Bugmeister
might
make more sense, though in an ideal world, people wouldn't need to nag at all...
The reality is that uploading a patch on Bugzilla should be sufficient to trigger review.
Exactly. If we haven't reached that point that is our failure as reviewers and maintainers of a FOSS project, and our job to do better at it.
-- brion
At that point, the uploader has put in his or her share of the work. But very often uploading a patch or even prodding in bug
comments
leads to no response at all for months or years or ever. Sometimes you'll get lucky and someone on the CC list will be able to help you (or find someone to help you). Or you'll get lucky and someone will notice the bug
in
#mediawiki and take an interest. It's a crapshoot, though. And it seems to me that a lot of the people who commit patches are the same people who
don't
use IRC or don't know who to nag if they do.
I'm not trying to be negative here, though it may come off that way. I'm just trying to understand how people are supposed to be able to help currently and going forward.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 discussed.
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).
Maybe bugzilla can send wikitech-l a list of bugs with attachments? We already have a weekly mail listing the number of bugs opened/resolved. That might attract reviewers.
----- Original Message -----
From: "Brion Vibber" brion@wikimedia.org
[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 bugzilla (and thus in their email).
I believe MZ's reply to this will parse as "that's a good goal. But it's a goal, and what we need is a *process*". And yes, I know Process is in process.
:-)
The reality is that uploading a patch on Bugzilla should be sufficient to trigger review.
Exactly. If we haven't reached that point that is our failure as reviewers and maintainers of a FOSS project, and our job to do better at it.
I want to take a moment here and applaud Brion for that response. It's far too uncommon in FOSS projects - I would never hear it from the MythTV people, I don't think, at least not in so many words.
And there's some reason to that; there is a line you cross in FOSS when you are no longer scratching just your own itch (and can't these people just go buy Lanacaine or something? :-)...but when you've crossed that line is clearly a matter of dispute between devs and users on some projects; I'm very happy to see that Mediawiki's dev team agree with we users on which side of that line they're on.
Huzzah!
Cheers, -- jra
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)
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 have seen done a couple of times in the past)
They can still commit their broken code but NOT IN TRUNK :)
On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz hashar+wmf@free.fr 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 confused as to why there would be a whole part of the repo that couldn't be changed, and that was what old revisions were for. But is there also another special place to commit testing code?
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" en.wp.st47@gmail.com wrote:
On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz hashar+wmf@free.fr
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 confused as to why there would be a whole part of the repo that couldn't be changed, and that was what old revisions were for. But is there also another special place to commit testing code?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
----- Original Message -----
From: "Dan Collins" en.wp.st47@gmail.com
On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoiz hashar+wmf@free.fr 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 confused as to why there would be a whole part of the repo that couldn't be changed, and that was what old revisions were for. But is there also another special place to commit testing code?
More pointedly, is there a really *good* "Software Development Version Management HOWTO" anywhere at all? I've looked at the git book, and it just knocked me on my ass from the first chapter. I *almost* understand BZR... but I haven't seen a good 30,000ft explanation of any of them, written for people who are good programmers, but have never worked with one before.
Cheers, -- jra
On 29/07/11 20:59, Dan Collins wrote:
On Fri, Jul 29, 2011 at 2:52 PM, Ashar Voultoizhashar+wmf@free.fr 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 confused as to why there would be a whole part of the repo that couldn't be changed, and that was what old revisions were for. But is there also another special place to commit testing code?
A branch is just a copy of a directory with all history. You can copy trunk almost where ever you want under the /branches/ directory. There is a rough guide on mw.org:
http://www.mediawiki.org/wiki/Subversion/branching_guide
I myself put my branches under /branches/hashar/ As an example have a look at:
http://svn.wikimedia.org/viewvc/mediawiki/branches/hashar/
You will find 4 sub directories there which got forked from trunk at various point in the time: - node-qunit - old_stuff - prettyURL - syslog
wikitech-l@lists.wikimedia.org