[parted-devel] History patchset

[Jim Meyering]

Matt Davis <mattdavis9 at gmail.com> wrote:
> On Wed, Feb 13, 2008 at 10:01:46AM -0200, Otavio Salvador wrote:
>> Jim Meyering <jim at meyering.net> writes:
>>
>> > "Matt Davis" <mattdavis9 at gmail.com> wrote:
>> >> Here is my most recent implementation.  If this is not cool please let me know.
>> >> This is only implemented for the Linux architecture.  Adding the
>> >> initialization for the PedHistoryManager for other architectures
>> >> should be similar.  But I have not added them at this time, as I am
>> >> waiting to make sure this patchset is appropriate :-)
>> >
>> > Matt and I have been talking a little off-list.
>> > A new feature like this must not introduce incompatible API changes.
>> > Whether that's feasible, I don't know, off hand.
>>
>> How is this progress going?
>
> Otavio,
> I am done with the initial patchset.  Unfortunately I do not know if the changes
> I have made seem desirable to libparted, as Jim has pointed out.  Most of the
> work was done to benefit the library (and to give me something to do in my free
> time hehehe).
>
> I cannot see where having this history feature is a hinderance as a library
> feature.  I am out of town from Friday to Sunday.  And I have some other needs
> to attened to in the next upcoming days.  I can take a closer look to see if
> it's a feasible addition to roll all of this into parted core and not touch the
> library, but I am not sure how much change would be needed for that at the
> moment.  But I do not want to take that route if for some reason we can leave it
> in the library?  Either way, I am glad to be constructively utilizing my free
> time on this project, and I respect the words of both Jim and yourself for even
> considering my patchset.  Thanks!

It's a judgement call.
How valuable is the new feature?  Is any project other than parted
planning to use it?  Try to compare that with the cost a library-
spanning API-change would incur for each project that uses libparted.

It seems to me that while this would be "nice to have", it's not worth
the disruption and risk that would result in changing key interfaces of
the code that operates on raw partitions.

However, if you talk to the people developing for enough of the projects
that depend on libparted, and the majority are enthusiastic (or at least
accept the risk) then maybe it's worth the added work and risk after all.

This is why I asked if you'd contacted any of the people
behind any other libparted-using projects, e.g.,

  fatresize
  gnu-fdisk
  gparted
  qtparted
  libvirt

The trouble with an API change like this is that it imposes a hard
requirement.  A package can no longer simply require "libparted".
Rather, it then must specify pre- or "post-version-x.y libparted",
and probably (if it is properly distro-agnostic) choosing via autoconf
feature-detection tests.  So any API change had better be for a very good
reason, since it ends up affecting everyone from developers of dependent
applications to integrators and packagers for every distribution.