Hi Iustin,
On 18:26 Tue 12 Feb , Iustin Pop wrote:
> > Immediate steps
> > ---------------
> >
> > In light of the above, I propose the following:
> >
> > - Dismiss all unreleased work and archive the current master and
> > stable-2.17 branches under attic/ (I've already pushed a ref for
> > attic/stable-2.17).
>
> SGTM.
>
> > - Declare 2.15 EOL
>
> What does it mean EOL here? Current Debian stable still has 2.15 (+2.16
> in backports), so does this mean dropping all support?
To me this means "no more bugfixes", but if there's a critical security
flaw discovered, of course it should be patched. Unfortunately the 2.15
codebase is dated enough, in fact so dated that even on Stretch it's
heavily patched to be able to work, to the extend that it's not even
compatible with the upstream sources anymore (e.g. due to the backported
RSA key support breaking the RPC). It doesn't make sense to try to merge
these patches upstream, but of course I'll continue maintaining 2.15
downstream with my Debian hat on for as long as it's reasonable.
>
> > - git push --force origin v2.16.0:master and continue development from
> > there. I don't expect the force-push to be an issue, and it's much
> > cleaner than a `git merge -s ours' or messing up our versioning. We
> > *will* be actually throwing away that development history — at least
> > for the time being.
>
> How would it break versioning? Not sure I understand.
I was thinking (but never actually wrote it out) that 2.17.0beta1 was
released at some point, and according to the proposed plan, 2.17.0 will
lack functionality compared to the beta. To make that clear, perhaps it
would make sense to skip to 2.18 directly ("messing up our versioning"
in the process), but I don't expect anyone to have ever used 2.17.0beta1
out there, so I assume we can pretend it never existed.
>
> > - Work on stable-2.16 to release 2.16.1 with all bugfixes currently
> > available in PRs or elsewhere (e.g. Debian package patches)
>
> +1.
>
> > - Work on master to prepare 2.17.0, with the following goals:
> > + Single-source compatibility for all GHC versions >= 8 (or even 8.2)
> > + Have a working CI setup with all tests passing
> > + More TBD; we can set a Github milestone for that
>
> +1.
>
> > The goal here is to release early, and release often™.
> >
> > From there on we can start discussing about bigger things, like
> > switching to Python 3 and modernizing our hypervisor support.
>
> I would be definitely interested in the Python 3 move, but honestly on a
> theortical level - how feasible is to move a large codebase.
I did a PoC semi-automated conversion a while back and it seems to be
feasible enough. The main problems are integer division and the
string/bytes boundary (which is akin to the String/ByteString boundary
in Haskell).
> > Comments, thoughts or anything else welcome :) I think this is also the
> > best time for a show of hands from people willing to participate in any
> > way (patches, code reviews, testing, documentation etc).
>
> I'm happy to review code/designs, but with high latency (usually on the
> weekend).
Thanks!
> regards,
> iustin
Regards,
Apollon
