
<html><head></head><body>I think it will be quite fast.<br><br>I could write a shell script automatically identifying packages with python2 and python3 packages and adding standard python3 handling in the base SlackBuild, in one hour or two.<br><br>Then we'll have to test them all, but obviously we'll have to test most SlackBuilds at that time.<br><br>But as I remember the window is not too small, as it starts with first RC, and Pat is never in any rush to ship a new version.<br><br><div class="gmail_quote">Le February 21, 2019 10:20:04 AM UTC, David Demelier <markand@malikania.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Le 21/02/2019 à 01:32, Daniel Prosser a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I like the idea of having a single script for both Python 2 and Python 3 <br>versions of each module (or as many as possible), but I don't think a <br>lot of work should be done to enforce uniformity for 14.2. When <br>Slackware 15 comes out, Python 3 will be included and the issue of <br>dependencies will be moot for most scripts. For now, I can deal with <br>maintainers taking different approaches.<br></blockquote><br>Won't it require lot of a time to do the merge for 15.0? I mean, how <br>long are freeze times before a new Slackware version?<br><br>That's why I thought the master git branch was used to track <br>slackware-current. Now I feel like once we have a code freeze in <br>Slackware, we need to do as quick as possible the modifications in <br>master to match the new upcoming release.<br><br>Or perhaps I understood something wrong.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>