Re: [sage-devel] Packaging rant
2015-06-12 6:18 GMT-03:00 Jeroen Demeyer : > On 2015-06-11 10:31, Julien Puydt wrote: >> >> Open software is about cooperation. > > Of course. The question is: what should we do if upstream does not want to > cooperate? I don't want to call names in this thread, but I have proposed > patches to many upstream projects which are part of Sage (usually they are > small bugfixes). The chances of actually getting a patch accepted by > upstream are unfortunately much smaller than I would wish. I understand your frustration. I understand that sage needs to bundle all it needs because otherwise it would be pretty much impossible to install sage on old, or too new systems. But keeping as close as possible to upstream is really desirable. For example, I have some patches in a few packages in Fedora, to satisfy sage, but for others it is not easy... Right now, Fedora has sagemath 6.5 packaged, and I need to find some time to see if reasonable, and how I would patch sage to use a non released and patched pari, to update to 6.7 (skipping 6.6). > Some people think that Sage should only add patches to upstream packages if > they are accepted by upstream. This is frustrating, because it really slows > down Sage development. > > Jeroen. Thaks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
On 2015-06-12 14:32, Julien Puydt wrote: Nothing will slow development down like dozens of forked packages to maintain, especially if upstreams consider you hostile. If you mean "forking" in the serious sense, you're probably right. If you mean "forking" as in "add a few patches", then you're surely wrong: Sage has always added many patches to various upstream project and that was never a burden to development. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
Hi, Le 12/06/2015 11:18, Jeroen Demeyer a écrit : On 2015-06-11 10:31, Julien Puydt wrote: Open software is about cooperation. Of course. The question is: what should we do if upstream does not want to cooperate? I don't want to call names in this thread, but I have proposed patches to many upstream projects which are part of Sage (usually they are small bugfixes). The chances of actually getting a patch accepted by upstream are unfortunately much smaller than I would wish. Some people think that Sage should only add patches to upstream packages if they are accepted by upstream. This is frustrating, because it really slows down Sage development. Nothing will slow development down like dozens of forked packages to maintain, especially if upstreams consider you hostile. There's a joke around here which one could translate as "The fastest and shortest way down is off the cliff -- I prefer hiking!" Snark on #sagemath -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
> On 12/06/2015, at 21:18, Jeroen Demeyer wrote: > > On 2015-06-11 10:31, Julien Puydt wrote: >> Open software is about cooperation. > Of course. The question is: what should we do if upstream does not want to > cooperate? I don't want to call names in this thread, but I have proposed > patches to many upstream projects which are part of Sage (usually they are > small bugfixes). The chances of actually getting a patch accepted by upstream > are unfortunately much smaller than I would wish. > That’s very unfortunate, you expect some rejections but your report of low number is still annoying. > Some people think that Sage should only add patches to upstream packages if > they are accepted by upstream. This is frustrating, because it really slows > down Sage development. > Having been around sage since 2007, I have accepted the fact that not all of the patches in sage will be upstreamed. Even at a linux distro level that’s a pipe dream - have you seen the list of patches that go into your distro? How many of these will be accepted upstream? Probably less than you would imagine. Nevertheless, it is uncomfortable, I am sure that I have been one the people that prompted that remark, it is even written somewhere on trac. There are weighted decisions and I do not want to be painted all black or white. I am the sage-on-gentoo maintainer and anything that is not accepted in the main Gentoo tree, I carry it in my tree and the maintenance is mine to do. If the package is only in my tree, I won’t be fussy adding sage patches. If the package is in the main tree and widely used, well the barrier for entry of the patch to the main tree has just dramatically increased, even more so if 1) it is not accepted upstream 2) it adds a “feature” rather than fix something that will break for many people (the line between feature and bug may sometimes be blurry). In that case, I will carry a fork of the distro package with all the burden that implies when trying to maintain coherence with the distro and steal the main tree own various fixes (it’s been a while since sage-on-gentoo has relied on maxima from the main tree…). So I am looking at sage trac and I see one of those major, widely used, package and upstream reject the patch. Do I want to review the inclusion? Well it is a bit like asking if I am a masochist (considering how long I have been doing sage-on-gentoo it is a really good question). So on that principle I won’t review it. Someone else may review it positively, I am not the only reviewer available after all, and then I’ll have to do my masochistic bit anyway. May be Jeroen is right, may be I should cut the middle man and do the review anyway. François -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
On 2015-06-11 10:31, Julien Puydt wrote: Open software is about cooperation. Of course. The question is: what should we do if upstream does not want to cooperate? I don't want to call names in this thread, but I have proposed patches to many upstream projects which are part of Sage (usually they are small bugfixes). The chances of actually getting a patch accepted by upstream are unfortunately much smaller than I would wish. Some people think that Sage should only add patches to upstream packages if they are accepted by upstream. This is frustrating, because it really slows down Sage development. Jeroen. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
Upstream being dead, the only alternative to forking is to live forever with a fixed version. That might work for the moment, but eventually we will find issues with newer compilers, or newer version of the libraries it deppends on, or the newer version of python And at that point forking will be the only way to go on. So, from my point of view, the question is if we should fork polybory, but if we are going to do so now or later. Unless of course in the meantime we find an alternative to polybory, but i wouldn't count on that. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
I am only proposing to fork a package with a dead upstream. I wouldn’t do it with a live one. Nevertheless I understand that it makes me look like I am saying two contradictory things at the same time. To be clear with a rant of my own. If you fork a live project you’ll have to live with the divergence and have to make a choice of using one or the other. You may as well rename the thing if you are going to fork and diverge, that’s being honest. You don’t have to deal with the potential for divergence with a dead project. You are only diverging with the old dead body the same way that you may diverge from version 1 to version 2 of a software, but there will not be a competing branch for the new version you release. A name change is probably still a good idea to signal new ownership. François > On 11/06/2015, at 20:28, Jeroen Demeyer wrote: > > On 2015-06-11 03:40, François Bissey wrote: >> * fork upstream and keep it as a separate package but >> no one really wants to be the maintainer. > > If it's decided that we are allowed to fork polybori, can this be applied to > other packages too? > > I have often been frustrated in Sage by people complaining that we should > stay as close to upstream as possible, that we shouldn't patch packages in > Sage, that we should stick to release (non-development) versions of packages > in Sage. > > Most recently for example in #18450 I was forced to rewrite part of a patch > because upstream Cython didn't want to accept a patch (I still think that my > patch was reasonable and I don't understand why upstream doesn't like it). > > And every time I make a change to PARI, I feel resistance because we're > moving further away from the released PARI version. > > So I hope that you understand my frustration if other people can do with > polybori what they want but I constantly hit walls because I am not allowed > to patch other packages. > > Really, I wish we could just give up on this whole "packaging Sage for > distributions" effort. > > > Jeroen. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
Hi, Le 11/06/2015 10:28, Jeroen Demeyer a écrit : On 2015-06-11 03:40, François Bissey wrote: * fork upstream and keep it as a separate package but no one really wants to be the maintainer. If it's decided that we are allowed to fork polybori, can this be applied to other packages too? I have often been frustrated in Sage by people complaining that we should stay as close to upstream as possible, that we shouldn't patch packages in Sage, that we should stick to release (non-development) versions of packages in Sage. Most recently for example in #18450 I was forced to rewrite part of a patch because upstream Cython didn't want to accept a patch (I still think that my patch was reasonable and I don't understand why upstream doesn't like it). And every time I make a change to PARI, I feel resistance because we're moving further away from the released PARI version. So I hope that you understand my frustration if other people can do with polybori what they want but I constantly hit walls because I am not allowed to patch other packages. Really, I wish we could just give up on this whole "packaging Sage for distributions" effort. I can hardly disagree more. That basically means that instead of working on sagemath, sage devs will end up working on keeping hundreds of more or less nonsensical forks, with hundreds of hostile upstreams. Open software is about cooperation. Snark on #sagemath -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
