Closed
Bug 115514
Opened 23 years ago
Closed 19 years ago
attachments should have a checked-in flag
Categories
(bugzilla.mozilla.org :: Administration, task)
bugzilla.mozilla.org
Administration
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Morten, Assigned: asa)
References
Details
So that a particular attachment of a bug could be flagged as having been checked in, and to allow finer granularity to the fixing of a bug...
Comment 1•23 years ago
|
||
Attachment statuses are completely configurable by the admin on a per-product basis. I'm assuming you want them to add this at bugzilla.mozilla.org. If not, close this out and ask your local Bugzilla admin. :-)
Assignee: justdave → asa
Component: Bugzilla-General → Bugzilla: Keyword & Component Changes
Product: Bugzilla → mozilla.org
QA Contact: matty → timeless
Version: 2.10 → other
Reporter | ||
Comment 2•23 years ago
|
||
Indeed... I would like that added to bugzilla.mozilla.org
Comment 3•23 years ago
|
||
I've been thinking this. When a bug is reopened it looks like the patch is pending. There may be Bugzilla functionality that should be added to support this usage. In particular: - Checked in patches should have their summary crossed out, in italics or distinguished in some other way. - Need some way to get people to actually add this status. Currently this would be cumbersome. Maybe it isn't required to add it if you're just closing the bug, instead keep the feature for partial checkins and reopens.
Assignee | ||
Comment 4•23 years ago
|
||
I don't think that we're going to convince developers to do the extra 4 clicks to resolve the patch as well as the bug. tenative wontfix.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
i've used obsolete. it works just as well as checked in. a checked in patch is obsoleted by the cvs rev it caused. vrfy wontfix. cvszilla/bonsai/bugzilla integration might be able to help, but i agree w/ asa there's no way to convince developers to take this step. it's hard enough to get them to resolve bugs at all (speaking as one who resolves only half the bugs that should be...)
Status: RESOLVED → VERIFIED
Comment 6•22 years ago
|
||
Reopening. dbaron points out that the obsolete resolution can be harmful, as it's useful to discriminate between obsolete patches and those that were actually finalized and checked in. Given that people normally add "patch checked in" comments, they can now add those comments as they mark the patch as checked-in, without significant additional effort.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Assignee | ||
Comment 7•22 years ago
|
||
wrong. people have to resolve a bug as fixed. That makes resolving the patch and the bug a two step process. That's not gonna happen. You gotta get through me to have this created and that ain't happenin'. wontfix.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
Comment 8•22 years ago
|
||
*** Bug 136271 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
I would like to ask for this to be revisited. This RFE may have additional new value with the new "flags" and "requests" functionality. In particular, as a person who occationally submits patches, but does not have (nor want) CVS access, I would really appreciate being able to submit "checked-in?" requests for patches. I would imagine that such "checked-in?" requests could also be useful in other cases as well... P.S. CCing current owners of b.m.o components.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: attachments should have a checked-in tag → attachments should have a checked-in flag
Comment 10•22 years ago
|
||
This seems reasonable -- not expected to be used commonly, but for requesting that a patch be checked in. as in, "check-in?". Anyone against?
Assignee: asa → ian
Status: REOPENED → NEW
Comment 11•22 years ago
|
||
yeah, i could use a requestable flag for checkins, i think i spoke w/ asa about that recently.
Comment 12•22 years ago
|
||
So, what's the verdict - can this flag be added? Thanks!
Comment 13•22 years ago
|
||
done
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 14•22 years ago
|
||
Thanks!
P.S. It appears that there may be some minor problems with having spaces in the
flag name. For example, an e-mail that I've got after requesting it was:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #70338 [details] [diff]| |checked, in?
Flag| |
Note the coma after "checked". Would it be better to call it "checked-in"?
Comment 15•22 years ago
|
||
That's a bug in Bugzilla, not in the configuration, and should be treated as such. (For other reasons, though, the flag was renamed 'checkin'.)
Assignee | ||
Comment 16•22 years ago
|
||
whoah. reopening. flag has been disabled (at least temporarily.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 17•22 years ago
|
||
We're still introducing flags and how they're to be used. This one is not generally applicable and I don't think it should happen now. It will probably lead to confusion on the 95% case where the flag isn't needed. So until I've got a better idea how the "required" flags are working out I'm not going to add this. See comment 7. Sorry I didn't respond sooner, busy with releases and vacations and all that.
Comment 18•22 years ago
|
||
asa: How do you request that a patch be checked in then?
Comment 19•22 years ago
|
||
asa: and, to be fair, your answer "mark the bug fixed" just doesn't reflect the reality of how bugs are fixed. Many bugs require multiple patches to be fixed completely, and this will be getting more common as bigger architectural fixes are undertaken.
Comment 21•21 years ago
|
||
Case in point to comment #3 & comment #9, I broke the mingw mega patch into 9 separate patches for ease of review. Of course, not all of those patches are going to land at the same time and it would be nice to have some sort of indication of which patch landed and which ones didn't until all of the necessary patches have been checked in. That is, nice for both myself and the people trying to use the patches while they're sitting in the review queue. Per comment #7, you're treating the checked-in flag as a mandatory step that must be taken to resolve a bug. That would be great for consistency but it's hardly a necessity. If people want to keep their old behavior of assuming a 1:1 relationship between a bug and a non-obsolete patch or simply assume that all non-obsolete patches were checked in, they can do that. I can't see any developer balking at having finer granularity when resolving a bug though.
Comment 22•21 years ago
|
||
*** Bug 198904 has been marked as a duplicate of this bug. ***
Comment 23•20 years ago
|
||
*** Bug 234500 has been marked as a duplicate of this bug. ***
Comment 24•20 years ago
|
||
Some additional ideas (from DUPlicate bug 234500): -- snip -- RFE: Patches/attachments should have a boolean patch field "checked-in" to indicate which patch has been checked-in. Optionally there should be a text input field (one per attachment) which can store any additional comments such as CVS commit messages, branch name and/or comments. And finally it should be possible to drop a comment to the main bug messages and mark the bug as FIXED from the same HTML form (to allow stuff like "attackment #xyz checked-in to branch FOOBAR_2, marking bug as FIXED"). -- snip --
Assignee | ||
Comment 25•20 years ago
|
||
I don't think a flag is appropriate. A flag is designed for making and fulfilling requests. Rather than be a flag, I think this should be a status for attachments like is patch and is obsolete. I'm probably not going to create a flag for this and so if folks want something to track checked in status, this bug should be morphed and moved to the Bugzilla product or closed and a new RFE filed on Bugzilla.
Comment 26•20 years ago
|
||
(In reply to comment #25) > I don't think a flag is appropriate. A flag is designed for making and > fulfilling requests. Rather than be a flag, I think this should be a status > for attachments like is patch and is obsolete. Actually both things have been requested and make sense IMHO. I have been in the situation of having a bug sitting in bugzilla that already got r/sr and then i had to request it being checked in via email and/or a comment. Now that we have a system for reviews it would be nice to extend this to checkin as well. Often the people who give reviews do not have CVS access, so this is not redundant. > I'm probably not going to create a flag for this and so if folks want > something to track checked in status, this bug should be morphed and moved to > the Bugzilla product or closed and a new RFE filed on Bugzilla. I'm going to file a Bugzilla RFE requesting this functionality.
Assignee | ||
Comment 27•20 years ago
|
||
(In reply to comment #26) > Often the people who give reviews do not have CVS access, so this is not redundant. What?! I seriously doubt that. If you're working on Mozilla applications, f you don't have CVS access, you shouldn't be doing reviews.
Comment 28•20 years ago
|
||
(In reply to comment #27) > > Often the people who give reviews do not have CVS access, so this is not > redundant. > > What?! I seriously doubt that. If you're working on Mozilla applications, f you > don't have CVS access, you shouldn't be doing reviews. I don't have an example handy off the top of my head, but I have been in the situation of hunting for checkin on patches that had r= and sr=, so I think the basic premise is valid. I have filed RFE bug 250427 "checkin flag for attachments" to add a standard way of dealing with this to bugzilla.
Comment 29•20 years ago
|
||
*** Bug 250427 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•19 years ago
|
||
At this point, I don't think we want this. Resolving.
Status: NEW → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → WONTFIX
Updated•13 years ago
|
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•