Last modified: 2013-03-29 19:32:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 37538 - Comments on drafts should not be announced on IRC
Comments on drafts should not be announced on IRC
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Chad H.
:
: 44217 (view as bug list)
Depends on: 39589
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-13 11:48 UTC by Sam Reed (reedy)
Modified: 2013-03-29 19:32 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sam Reed (reedy) 2012-06-13 11:48:02 UTC
If you submit a comment to a draft revision, the comment is publicly displayed, which shouldn't happen
Comment 1 Chad H. 2012-06-13 15:50:51 UTC
What we'll want to do here is change the comment-added hook to not log when the refspec is refs/drafts/*.

change-merged and change-abandoned may need poking at too in a similar manner.

patchset-created isn't a problem, since it's not fired on new drafts (by design, sorta, there's debate going on here if you're interested).
Comment 2 Chad H. 2012-06-28 21:08:47 UTC
I haven't found a straightforward way to do this yet, so I've asked upstream.

If there's not an easy way to do this already, I've got a commit ready for upstream that will make it easy to fix.
Comment 3 Chad H. 2012-09-18 13:26:30 UTC
Once https://gerrit-review.googlesource.com/#/c/37901/ goes in, this will be much easier to accomplish.
Comment 4 Rob Lanphier 2012-10-23 18:56:34 UTC
Lowering priority on this one, and marking it as blocked on Gerrit 2.5. Since drafts aren't really a secure way to keep changes private, should we really worry about this one at all?  We should probably simply recommend that private changes go as patches in Bugzilla or some other place that's a bit more locked down.
Comment 5 Niklas Laxström 2012-10-23 21:05:50 UTC
Makes me wonder what is the use case of drafts feature anyway.
Comment 6 Chad H. 2012-10-23 21:15:17 UTC
To do private changesets.

The problem is they aren't private enough. IMHO, they weren't quite ready yet when released :\
Comment 7 Siebrand Mazeland 2012-10-23 21:32:30 UTC
(In reply to comment #4)
> Since
> drafts aren't really a secure way to keep changes private, should we really
> worry about this one at all?

I guess we should. AFAIK security fixes are being updated and reviewed using this feature (but I may be wrong).
Comment 8 Rob Lanphier 2012-10-23 22:19:54 UTC
(In reply to comment #7)
> I guess we should [worry about this bug]. AFAIK security fixes are being
> updated and reviewed using this feature (but I may be wrong).

We stopped because it isn't private enough (and fixing this bug wouldn't change that problem).
Comment 9 Chad H. 2013-01-21 20:11:40 UTC
*** Bug 44217 has been marked as a duplicate of this bug. ***
Comment 10 Chad H. 2013-03-14 16:04:44 UTC
This was done for new patchsets awhile ago, but we never handled the original request for comments.

Our patch: Gerrit change #53759
Upstream patch: https://gerrit-review.googlesource.com/43490
Comment 11 Chad H. 2013-03-29 19:32:16 UTC
This should now be fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links