Hi Daniel, Thanks for your answer.
On Wed, Sep 29, 2021 at 12:07:33AM +0200, Daniel Stenberg wrote: > On Tue, 28 Sep 2021, Olivier Delhomme wrote: > > > I'd love to know what are your thoughts about GreenIt / low tech and the > > paths that we may need to walk through to reduce our environmental > > footprint [1] such as: > > > > * limit or (better) reduce features in programs, > > One of our best and most appreciated features in libcurl is its ABI > stability. We can't have ABI stability and reduce features at the same time. And this stability is a real plus as it may avoid a lot of changes and adaptations in softwares using libcurl. > But for those that build their own libcurls, I think we should continue to > offer build-time opt-in switches to disable features and protocols from the > build. That's at least one way of reducing features in particular builds. I didn't remember that… > > * maintain released versions for a much more longer time (such > > as 7 years [2]). > > I would love to maintain released versions a long time and I'm ready to do > this if someone pays for it. Asking an open source project to take on even > more work for free "for the good of society" is just not going to work. We > still need food on the table. It is an issue with open source projects not only maintaining them a longer time. > But also, "maintain released versions" is a very soft requirement. What does > it mean? If you talk about maintaining, you still mean shipping updates that > users can upgrade to and we are already working hard to allow users to > upgrade without roadbumps. In that aspect we already "maintain" releases for > much longer than seven years. I was speaking of maintaining already released versions with security patches. May be choosing whether to integrate a fix or upgrade to a newer version is a task that belongs to the one that distributes libcurl. Finally there is no need to distinguish between security patch upgrades and feature upgrade because the latter can be done transparently. > > > Is it conceivable to make choices of which protocols may stay > > or not in curl and keep only 32 of them ? > > That would mean to not add support for more protocols. Looking at the > history of curl and the Internet the past twenty years up until now, and > thinking about what could possible happen in the coming twenty years, it > seems like a very hard limit to say that we can't follow what happens and > what users will want. I don't see how that would be good for curl, for its > users or for the ecosystem at large. I absolutely agree with that. Regards, Olivier. -- Continuous data protection for GNU/Linux (GPL v3) Current version v0.0.12. . Download source code : http://cdpfgl.delhomme.org/download/releases/ . Contribute to project: https://github.com/dupgit/sauvegarde
signature.asc
Description: PGP signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
