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
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
