I've had my mind on this for a while too. I think it's wise to not sweat the features for VyOS-NG (vyconfd) and instead focus on getting some maintenance releases out the door to keep VyOS moving along enough. I think that putting vyconfd on hold until we have a Jessie-based release out the door is a sensible idea.
Or potentially, I'd suggest that we should appoint an alternate maintainer for Lithium (1.2) and for a Jessie-based release (is this beryllium <http://vyos.net/wiki/Beryllium>? Shall we call that 2.0? Or 1.3?) Daniil I suspect a lot of your energy on VyOS comes from working on vyconfd? What if someone else picked up Lithium entirely, and Beryllium (Jessie) once we make an initial release. With the idea of just doing maintenance releases. The maintainer's job would be just to build releases, not spend too much time fixing bugs themselves. I could build & pull packages & push ISOs. If the process is heavy, maybe I can do something about that, so we can get regular maintenance releases of a Jessie based VyOS 1.x with upstream security patches. You can then freely experiment with VyOS NG without worrying about the legacy system and keeping people interested. I agree that it's not sensible to try and support Squeeze beyond Feb. (Unless someone wants to raise their hand and own it.) Release early, release often. Ship Lithium 1.2.0 now. Then lets get together a task force for the Jessie port so we can safely hold VyOS 1.x together with regular upstream maintenance. Any developers in the London area up for a weekend hackathon on the port to Jessie? I think an interactive session would be a good way to help people focus and also be a good way to collectively up our education level on how to port different modules without everyone relearning it the hard way. Now that I live on this side of the world I suspect there's a few people in the area, and I'd be happy to arrange something and provide ample pizza & beer and some space to work in. If not a hackathon, I think we need a task list for what to do for the Jessie port (I'm thinking a google sheet with a list of modules, the hacker who wants to work on it, and a status red/yellow/green light). Maybe some coordinated IRC or Hangouts meetings as well. Cheers Patrick On 21 Jan 2016 8:14 am, "Daniil Baturin" <dan...@baturin.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > That's a valid concern indeed, and this decision does feel bad. > > However, between leaving people with 1.1.6 and these possible problems > and without the fixes and additions from lithium, and leaving them with > lithium and the same problem, the latter probably looks better. > > At least it will give us motivation to work on jessie port faster. ;) > > Possible options for security updates include pulling patches from > CentOS, as RHEL people keep backporing stuff for a long while, and our > packages are not much older than those of EL6. Still can be a > maintenance nightmare, but at least should be possible. > > Sadly at the moment we have to choose between bad options as we don't > have a good one yet. > > > > On 01/21/2016 01:49 PM, Thomas Jepp wrote: > > On 21/01/2016 07:38, Daniil Baturin wrote: > >> Hi Kim, > >> > >> It's in the "current" branch now. If some submodules lack it, please > >> create it there! > >> > >> It would be awesome if you re-applied the vyatta patches to the most > >> recent kernel as you did for lithium. I started looking, but you > >> probably remember the procedure better than me. > >> This is what is blocking Tom from full live testing of his changes. > >> Since overlayfs is now in the kernel, once patches are there, we can > >> probably keep pulling updates directly from the kernel, with some > >> checking if they don't overwrite those patches. > > There are a few other ongoing issues - I need to re-do the PAM > configuration for granting the appropriate caps to administrators for > example. > > > > My work-in-progress isn't in the official repositories at the moment - > it's in my forks. > > > > I don't have the original message for this thread (I forgot to > subscribe) so I'll add this here too: > > > > I'm unsure as to the wisdom of releasing Lithium where we know that > exactly the same issue is going to affect us there - and a new major > release does imply some sort of security coverage. > > > > It's going to be hard to provide that given the age of Squeeze's > packages if we have to backport a major security fix. > > > > -- > > Thomas Jepp > > Email: t...@tomjepp.co.uk Phone: +441788 471234 / +1-217-635-6076 > > > > > > _______________________________________________ > > Vyos-developers mailing list > > Vyos-developers@lists.tuxis.nl > > https://lists.tuxis.nl/listinfo/vyos-developers > > > - -- > #!/usr/bin/env perl > @a=split(//, "daniil @ baturin . org" );# Daniil Baturin > @b=split(//,q/Px%!+o0Q6lh*7dp$.@8#%|y{/);while($i<24){$_.= > chr((ord(@b[$i])-ord(@a[$i])+62)%94+32);$i++};print"$_\n"# > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWoJM4AAoJEEcm35UR4K8fc6YP/3AQyeICh9iUs0mKKYfwM5l+ > 6PkFj1cb6SU4OdNVFccOdy9o8TPbezU87kC8RIfQv4dkR/HqB6Q5kprhsEUlo8L1 > uUbU7SQMz6RBTM8tvK4aBckEvo7CGTzn9YKRLJMW955Z3jX6ZIueFAp0+40WXCKg > zyKoX81ysQyc0KsTQW7wBkj4Bpcuw7CH9wpVYzoXab0XaPcw12/CNFuDdQlbOwea > dxWJn7qi7PfbEdTdGOpodldvdCtLnAR2q/eMD3McFZg1Xqqvn5FkTw/MVz28JFWa > cV18/JTfAJf7AnrGI5lzdikQUqxA7DHLbETxJFtjcqFCMREj2smThl7GNGwz+YLv > NMZfk0RRp/W0iJQntp86tYFSDVyzqrUebnQj+33bSAbeYxIqWKT37ykvi6WRl//X > /erfSi2alkJGmLIXXyxjV+hTXETh9wTblvb39YCBpvTNEiQ4z3ZC6j7OIak1FYRM > x7KuRySD/w+kqMzx7lz43p6HyVVqkWGRD4WdC8Nqr/R1OSVr4drEks1FgA1xPzeR > oSuah8V+sZRuoEvCsXv0CcXZaIar/mVqv9rFvOhfXk83rJxuHbQfKGj28vI6107m > 92yoGq/MxHr/t9TtnRqmP37f+fGR344+W1LEhIh7V7Wx1jYQWTKyRa9Lj1hwG7cj > 2rvFf39gyyq43nFfv+Un > =szv8 > -----END PGP SIGNATURE----- > > > > _______________________________________________ > Vyos-developers mailing list > Vyos-developers@lists.tuxis.nl > https://lists.tuxis.nl/listinfo/vyos-developers >
_______________________________________________ Vyos-developers mailing list Vyos-developers@lists.tuxis.nl https://lists.tuxis.nl/listinfo/vyos-developers
