On Sat, Apr 16, 2016 at 1:49 AM, mmarco <mma...@unizar.es> wrote: > That is a question that we have to address: if we allow this kind of > external packages (or furthermore, move the devlopments of parts of sage to > a different workflow)... what kind of control will we do about them? Will we > make no promises about them at all? Have some kind of revision process > before accepting them? If so, what exactly do we check? > > The fact that all Sage code goes through a peer review process is an > important point. So, if we split the development process in different > modules... should we enforce such a review process in all the modules?
Should we enforce such a review process? I say no--many such external packages would be developed by individual researchers or small teams of researchers. Really the amount of support that can be given a particular package varies widely depending on who's working on it, and we don't want them to be a burden to the developers of the core package. But there should definitely be some standards for acceptance as an "official" external package. I don't know exactly what those standards should be since I'm new to this community, though I could make a few (incomplete) suggestions. If we want to incorporate patchbot testing against external packages I think that's good, but if some particular external package is not being maintained anymore it should have an explicit cap placed on its max supported version of sage (assuming it breaks with some newer version of sage) and should be dropped from testing. In the chance someone finds such an unmaintained package useful to them they would still have options such as: * Take over maintenance of the package, even if only just long enough to update it to work with newer versions of sage * Run it with an older version of sage--this will be easier as sage packaging improves. This will also be made easier by our efforts to provide docker containers for sage. Although the process isn't as formalized and automated as I want yet, the plan is to eventually provide docker containers for most individual versions of sage. * ...others...? > El viernes, 15 de abril de 2016, 23:40:05 (UTC+2), Dima Pasechnik escribió: >> >> >> >> On Friday, April 15, 2016 at 10:13:22 PM UTC+1, Simon King wrote: >>> >>> On 2016-04-15, Vincent Delecroix <20100.d...@gmail.com> wrote: >>> > +1. The need of modifying Sage source code to have an external package >>> > is very bad. >>> >>> I miss old-style packages, too. >> >> >> we didn't get to see an spkg with a virus or with `rm -rf /`, but surely >> it was just a question of time... >> > > -- > 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 https://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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
