[Pkg-electronics-devel] Bug#852856: collaborate

[Jonathan McDowell]

On Mon, Mar 12, 2018 at 11:13:10PM +0100, Geert Stappers wrote:
> > I'm not sure that's entirely appropriate. You can perfectly easily add
> > some udev rules to urjtag, rather than expecting openocd to solve the
> > problem for you. It can even be done in a way that means the 2 packages
> > can co-exist. #852856 is a wishlist bug that essentially says "we do the
> > same thing, I'd like to take advantage of the work you've already done
> > rather than maintaining a similar list myself".
> 
> In my words:
> 
> Avoiding duplicate work.
> 
> My plan:
> 
> Applying the patches, become stakeholder of openocd package.
> Working together.

If you want to work together you have to have a discussion. I appreciate
the bug has been languishing without a response but it pre-dates my
involvement with the OpenOCD package and it's not been as high priority
as getting the package up to date with upstream or dealing with security
issues.

On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote:
> On Mon, Mar 12, 2018 at 09:39:29AM +0000, Jonathan McDowell wrote:
> > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag
> > support, or is one a subset of the other?
> 
> Seen the question, but I don't see where it fits in the discussion
> about a openocd file moving into seperate package.

If one program is a strict subset of the other in terms of supported
adaptors then it may make sense for the program with the larger support
matrix to split a file out so that the other can take advantage of it.
If the 2 programs support different adaptors then I'm not sure of the
benefit; it becomes extra work on both parts to maintain the overlapping
list?

J.

-- 
Avoid GOTOs completely if you can keep the program readable.
This .sig brought to you by the letter L and the number 49
Product of the Republic of HuggieTag