Closed Bug 115514 Opened 23 years ago Closed 19 years ago

attachments should have a checked-in flag

Categories

(bugzilla.mozilla.org :: Administration, task)

task
Not set
normal

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...
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
Indeed... I would like that added to bugzilla.mozilla.org
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.
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
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 → ---
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 ago22 years ago
Resolution: --- → WONTFIX
*** Bug 136271 has been marked as a duplicate of this bug. ***
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
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
yeah, i could use a requestable flag for checkins, i think i spoke w/ asa about
that recently.
So, what's the verdict - can this flag be added? Thanks!
done
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
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"?
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'.)
whoah. reopening. flag has been disabled (at least temporarily.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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. 
asa: How do you request that a patch be checked in then?
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.
flags->asa
Assignee: ian → asa
Status: REOPENED → NEW
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.
*** Bug 198904 has been marked as a duplicate of this bug. ***
*** Bug 234500 has been marked as a duplicate of this bug. ***
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 --
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. 
(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.
(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. 
(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.
*** Bug 250427 has been marked as a duplicate of this bug. ***
At this point, I don't think we want this. Resolving.
Status: NEW → RESOLVED
Closed: 22 years ago19 years ago
Resolution: --- → WONTFIX
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.