On 17/08/10 00:23, Michael Hope wrote:
Thoughts?
This isn't what we discussed at all ????
Yes, keeping a bug open to track work begun upstream is probably a good policy, but it's not at all what we were discussing.
The patch tracker should ensure that all revisions in the bzr branch are submitted to upstream, or if not, ensure they are not lost in a rebase. Nothing more, nothing less.
This really wasn't supposed to be something complicated. I knocked together the first version in a matter of a few hours. Yes, looking back, I should have had a column that indicated which upstream version the patch was in, to help with the rebase, and yes, of course using a wiki page wouldn't scale as well as using a bug tracker, or provide as much room for notes and such, but it did what was required.
Here is the original spec we agreed to in Prague:
* Each bzr revision has a tracking ticket. * The tickets should be *created* automatically. - people cannot be relied upon to do it. - people cannot be relied upon to get it right. * The developer then edits the ticket manually.
The user then has to do something to make the ticket go away, but nothing at all to ensure that the patch is tracked.
We discussed reusing bug tickets for tracking patches, but since then I thought we'd agreed that overloading the tickets this way was fraught with trouble, and not necessary.
Can we please stick to this simple plan?
I really wanted this done weeks ago (when I originally implemented it), so I'm now getting frustrated that every time it looks like we're getting somewhere, it seems to have gone off on a tangent and lost sight of all the original requirements. :(
I'm going to write a "method 2" to explain what I need/want.
Andrew