And now correcting the -devel mailing list address.
On 2019-02-12 18:26:04, Iustin Pop wrote: > On 2019-02-12 17:02:35, Apollon Oikonomopoulos wrote: > > Hi everyone, > > Hi Apollon, > > > With 2.16.0 released last fall, I think it's time to discuss how we can > > kick the project back to life. I don't want to tire you with too many > > details, so I'll try to make it short. > > > > Picking a starting point > > ------------------------ > > > > As discussed in the last GanetiCon, continuing development - especially > > in face of the lack of resources - requires some hard decisions, > > namely should we scrap all unreleased work on the master and stable-2.17 > > branches (aside from bugfixes) and continue development from 2.16.0? > > > > Personally I'd answer "yes" here: I think it is vital to focus on > > modernizing the code first, and spending energy to stabilize unreleased > > work acts against this. We can still save important features (e.g. > > maintd/harepd) and try to merge them at some point in the future once > > we're running smoothly again. > > +1. > > > Simplifying the workflow > > ------------------------ > > > > Given the currently available resources, I think we need to simplify the > > workflow to the extent possible. It doesn't make sense to support 5 > > different > > release branches, nor do we have the energy to develop 2 future releases > > and a > > master branch simultaneously. > > I can only speak to my time in Ganeti, but not even with a full team it > didn't make sense to support 5 release braches, nor 2 future releases. > > > I feel we need a simpler approach, with all development happening on > > master and maintenance branches being created for each minor version > > released from master. As always, maintenance branches will receive only > > bug and compatibility fixes, which will be upmerged. On the course we'll > > also get to decide how many stable releases we are going to be > > supporting. > > > > 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? > > > - 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. > > > - 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. > > > 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). > > regards, > iustin
