[Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB)

[Rocky Bernstein]

Perhaps what should be done is split off libiso9660 into a separate project
which has its own release cycle?


On Sun, Jul 8, 2018 at 5:29 PM, Pete Batard <address@hidden> wrote:

> On 2018.07.08 21:30, Thomas Schmitt wrote:
>
>> What if an application is poorly maintained but still in use.
>>
>
> Well, from seeing the real-life damage this kind of reasoning actually
> incurs, I'm not going to mince my words: For the benefit of end users, and
> no matter how popular they are, applications that are not being maintained
> _must_ be weeded out.



For many projects, I can see your point. But we're talking about  a library
that originally was intended to read CD's; actually, VCD's. In fact that
specifically is where the code came from.  It so happens that VCD to use an
ISO9660 filesystem.

The reality is that the need VCD, CDDA, and CD reading in general and MMC
control has diminished. So this project is a little different than say the
next version of Python where there still is a lot of popularity. There is a
lot less incentive for developers to keep such code up to date. Yet, I
encounter a desire (by perhaps a minority but a vocal one)  to have things
still work.

To move to libcdi 1.0 and 2.0 it was a bit of a hassle to update the
libcdio Perl and Python binding. The Ruby bindings I haven't updated, and
so far no one has said anything.

And then I needed to update vcdimager which has no functional changes, just
changes for the new API. I am not looking forward to doing that again, if
it needs to be done for libiso9660. And when you think about it. I doubt
there are any VCD's in existence than need or use multiple extents. The
filessystem has to fit within the confines of a CD-ROM Disc which is
limited to less than 1GB.

So looking at it from a VCD developer's standpoint: why should I have to
rewrite code as a result decisions made about large ISO-9660 files that
have no bearing on VCDs?

For the last vcdimager update, I justified it to myself because it reduced
memory leaks, (But in truth I don't anyone cared about them.)


> And the sooner the better. If that can be hastened as a side effect of ABI
> breakage, all the better. ;)
>
> Now, because I fear that some people might be taken aback by the argument
> I am making, and may even be tempted to compare it to some kind of eugenics
> nonsense, please remember that all we are talking about here are things,
> not individuals, and things that are past due their usefulness do get
> discarded all the time, for very sensible reasons. There is a best before
> date on food, to avoid rot - why should it not be the same on software (to
> avoid bit-rot)? ;) But of course, because we're talking software, this
> "best before date" must be flexible and depend entirely on the maintenance
> effort put in by its developer.
>
> We're long past the days of "I'll put an application out there and stop
> maintaining it" as a viable software development approach, which too many
> proprietary software vendors (as well as some Open Source ones) seem to
> have. From my own experience, development of an application is only 20% of
> the work. Maintenance is the rest. If you are not prepared to put in the
> 80%, then, on behalf of all the users who are going to be very negatively
> affected by this decision _not_ to want to maintain code in the long run, I
> can only wish that some form of breakage will occur that will make these
> same users realize, sooner rather than later, that they should switch to
> using a well maintained alternative instead.
>
> This is another case where, IMO, the long term benefits for end users
> greatly outweigh any temporary inconvenience.
>
> Plus, it's another good way to push for the end of all proprietary
> software, which, as a long term FSF contributor, is something I am also
> personally very keen on...
>
> So there you have it. You see a problem, whereas I see yet another great
> opportunity to make the (software) world better for end users ;)
>
> Regards,
>
> /Pete
>
>