Web lists-archives.com

Re: duprkit User Repository

On Mon, Apr 08, 2019 at 12:57:56PM +0000, Mo Zhou wrote:
> On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 11:02:35AM +0000, Mo Zhou wrote:
> > In such a large community of volunteers it may not be enough to propose
> > something that is only marginally better because the cost (even just in
> > cognitive terms) and effort required for so many individuals to overcome
> > inertia is relatively high.
> Linus said that "Talk is cheap, show me the code."
> Now I have shown the code and nobody read that.
> The single-file format is not mandatory, and two convertion tools
> enables zero-cost convertion:
> https://github.com/dupr/duprkit/blob/master/bin/fold
> https://github.com/dupr/duprkit/blob/master/bin/unfold
> And the prototype implementation is compatible to the traditional debian/
> directory. See https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
> for the example.
> BOTH single-file format and traditional format are supported. People
> could choose and use what they like.
> I admit that I'm quite fond of the proposed single-file format, and
> hence didn't mention and compatiblity with traditional format in design.
> > I am not trying to discourage you from your effort, but rather advising
> > you that the chances of success would improve if you address the
> > principal obstacles to adoption in a holistic way.  (As I already
> > pointed out, your current approach misses a great deal.)
> What else can I do? Both traditional and single-file formats  are
> explicitly supported now.

Two suggestions:

- Stop claiming that what you propose is "zero-cost", "only 1 second of
  work", etc.*
- Find the individuals who currently experience the greatest pain
  associated with the problem you are trying to solve and whose pain is
  relieved by your solution.  Get them to adopt it.  If it works as well
  as you say it does, they will be enthusiastic adopters and will have
  no problem telling others, in concrete terms, how much better your
  solution is than whatever the current situation is.

* Even in a perfect world, nothing is "zero-cost."  To a community of
  contributors whose purpose it is to build an operating system
  distribution a deep understanding of the components that compose the
  system and the components used to build the system are effectively a
  requirement.  Thus, if I came along and said, "here, I have a drop-in
  replacement for utility 'foo', and I call the replacement 'bar', and
  it supports all the same options as 'foo' so that you can use it
  without having to think about any differences" I would still expect
  that there would be a need for me to convince potential adopters that
  things really work that way.  Experience tells us that even "drop in"
  replacements for things are seldom that "perfect" when it comes to
  compatibility with whatever they are replacing.


Roberto C. Sánchez