24646 - Facility to track state of fixes attached to bug reports

Status: VERIFIED DUPLICATE of bug 84338

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Michael Lowe]

I don't know of the best way to handle this, bug bugzilla needs a way to track 
the state of fixes attached to bug reports.   Too many times have patches been 
attached to bug reports only to be lost or delayed for long periods of time.   
Staff at mozilla.org need to be able to find patches that haven't been given 
appropriate attention and provide assistance in getting things moving.

Maybe each bug attachment needs to have an extra state and a date attached.  For 
example:
-------------------------------
* Attachments for bug 12345:

[1] Screenshot of problem; [Checkin State: N/A:^]
[2] Patch file to fix bug ; [Checkin State: Rejected:^], Since: 1999/12/01
[3] Revised patch file to fix bug ; [Checkin State: Checked in:^], Since: 
2000/01/01
[4] Additional .gif file for bug fix ; [Checkin State: Waiting checkin:^], 
Since: 2000/01/01
[5] Patch file for additional improvement ; [Checkin State: Waiting review:^], 
Since: 2000/02/01

Each attachment checkin state field is a combo-box with options {N/A, Waiting 
Review, Rejected, Waiting Checkin, Checked in}.   Any change to this field 
updates the attachment "Since" field.

You can then provide whatever facilities on the search form are necessary for 
[e-mail] to track attached bug fixes to ensure they are given prompt 
attention.

Comment 1

[Terry Weissman]

I understand the problem you're trying to solve, but the solution outlined here
seems far too clumsy and elaborate.  Anyone else have any inspiration?

Comment 2

[Matthew Tuck [:CodeMachine]]

Yes, bug #11328 style querying facilities on attachments.

Comment 3

[Michael Lowe]

> Yes, bug #11328 style querying facilities on attachments.

But it still doesn't solve the problem.   Not all attachements are patches for 
the tree - many are testcases or whatever.   Not all patches for the tree are 
diff files - some might be gifs or something else.   

Presently, bugzilla does not store enough information about attachments to know 
what needs to be reviewed and checked into the tree and what doesn't.   Until 
that is fixed, adding additional search facilities will not solve the problem.

Comment 4

[Dawn Endico]

actually, bugzilla does know which attachments are patches (assuming
the person sets the correct mime type). If ispatch were added to the 
list of fields then you could search for bugs with patches added since
a certain date (since attachments don't change). If you could do this 
sort of a query then the checkin states could just be registered as 
normal comments.

Or maybe this won't work because ispatch is a field in the attachments 
table, not the bug table.

Comment 5

[Terry Weissman]

No, you're right, you can definitely do that kind of search.  It's not
completely straightforward, but it's very similar to lots of other searches that
are already handled.

The problem is UI.  The query page is a mess, and I keep adding to it, and keep
making more of a mess ... where do we cram this stuff in?  (And would it be
enough, or do we really need a complicated scheme as originally proposed in this
bug report?)

Comment 6

[Dawn Endico]

Can you add it as another item in the "where the fields" list?
Then you could query for bugs open bugs where the field ispatch 
changed between 01/01/1998 and 01/20/2000 and find all the open
bugs with patches.

I think being able to search for bugs with patches will be enough.
We don't need to record the state of the patches too, other than as
comments.

Comment 7

[Michael Lowe]

I think you misunderstood my comments.   Diff (patch) files are only one type of 
attachment that people will want put in the tree.   Some people will upload gif 
files or complete .cpp files and want them put in the tree.

So, even though bugzilla currently already knows about patch files, it does not 
currently know beyond this what other attachments should be reviewed and checked 
into the tree.  Not even all patch attachments will be intended for the Mozilla 
tree.

So while you could build primitive search facilities with the current data 
stored in bugzilla, it is not sufficient to be able to catch everything that 
should be checked into the tree.

I still stand by my original proposal.   I think there _at least_ needs to be a 
boolean flag for each attachment to indicate whether it is intended for review & 
checkin to the tree.   Whether you want to go further and implement a 
checkin/review state and last modified timestamp for each attachment is for you 
to consider.

Comment 8

[Terry Weissman]

You can now use boolean charts to search for things relating to attachments.

Leaving this bug OPEN as I realize the original submitter wanted much more.

Comment 9

[Terry Weissman]

[e-mail] is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Comment 10

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 11

[Asa Dotzler [:asa]]

myk, does your work cover some of this ground?

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Seems to be similar to what I am doing with the attachment/request trackers. 
Reporter, will you take a look at bug 84338 and see if it meets your needs?

Comment 13

[Dave Miller [:justdave]]

making this a dupe of a newer bug, but only because the newer one already has 
patches and everything.


*** This bug has been marked as a duplicate of 84338 ***

Comment 14

[Dave Miller [:justdave]]

moving to Bugzilla product
reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE

Comment 15

[Matt Perry]

Verified duplicate