On Saturday 13 February 2010, Øyvind Harboe wrote:
> Post 0.4 release, I'd like to see patches being merged
> in ascending order of disruptiveness.
>
> Of course it isn't possible to measure disruptiveness, but
> I think about two things: cherry pickability and impact on
> design and direction of openocd.
Hmm, I tend to think of two aspects:
- How much a set of patches conflicts with other patches,
in terms of ability-to-apply.
- How much behaviour they change, including interface
changes.
The latter is more related to that "impact" concern I think.
Interface changes tend to work a bit more smoothly if they
get in *early* rather than late, in my experience, but that's
not a hard'n'fast rule.
> This makes patches more cherry pickable(create some private
> 0.4 + specific bugfixes branch) and reduces mering work...
That type of backportability concern isn't really easy
to work with or evaluate.
I'd suggest instead doing what we did for 0.4 ... just
having folk with major updates coordinate with each other
to avoid creating needless merge hassles.
Related: that means letting folk know about such merges
in advance.
> Also, it gives us the most amount of time to discuss any
> new directions that openocd will move in.
Hmm ...
The only stuff of that type I have pending is SWD related,
which basically boils down to:
ADIv5 cleanups ... it's quite messy
ADIv5 transport abstraction ... JTAG vs SWD
SWD adapter support (FT2232 only at first)
SWD transport support ... ADIv5-only
The intrusive bit there would be the need for a new init
model, coupled with JTAG adapter modes: gotta be able
to say "init in SWD mode, not JTAG mode".
I've posted bits of that. The cleanups and new transport
only affect two ARM cores. The rest will need discussion
and input from other developers/users. (Relative to the
previous SWD patches, the technical content of mine seems
closes to what Simon Qian posted, except that it'll be
factored more cleanly.)
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
