On Tue, May 30, 2017 at 11:05 PM, Axel Beckert <a...@debian.org> wrote: > Control: severity -1 important > Control: tag -1 confirmed > > Hi Ansgar, > > Ansgar Burchardt wrote: >> Severity: serious > > I disagree with severity. > >> SixXS will shutdown on 2017-06-06[1]. > > Yes, well-known and already discussed (on IRC IIRC) by us package > maintainers. > >> Unless there are other tunnel providers used with aiccu, it seems >> useless to include in stretch. > > Yes, but before we decide to pull the line I want to wait until _at > least_ that date (which is next week and not today) and _not_ pull the > line _before_ this date. Agreed, although the install base won't change between now and the sunset, so I'm not too fussed about in-or-out at this point. See below though. > Pim van Pelt wrote: >> It may be in our future to opensource the server implementation > > Any reason why you can't publish it as is? https://sixxs.net/sunset describes this, here's the pertinent language:
| Will you open source SixXS code? | | We do not currently have plans to open source any code that is not already publicly available. | Although our provisioning servers and routing daemon (sixxsd) are very well thought out, they | do have some intricate dependencies on how we built SixXS. As such, offering the code base | will not be necessarily useful for others. Over time, given effort on Jeroen’s part, this may | change. We cannot make any promises at this point. Additional thought -- I do not look forward to explaining to several integrators how to use the server code, although it's reasonably standalone, the SixXS server works in conjunction with our automation bits on the provisioning server side. Also worth pointing out, if you're interested, is this piece: | Will you hand over the project to other folks? | | We are fairly protective of our brand and position in the community. Due to the nature of SixXS, | which rests on an open source client (aiccu) with a closed source server (sixxsd), we are not | willing to hand over the project. However, that aside, the main justification for our decision as | outlined in this document, is that we are of the belief that IPv6 Tunnel Brokers are no longer | facilitating access providers moving to IPv6, and as such do not wish for the project to be | continued. Handing it over to other folks will not allow us to satisfy our concerns. If my mission is to stop tunnelbrokers, opensourcing the code is not productive. However, we may change our mind after a certain cool-down period. Time will tell, which is why I was opting for a resubmission iff we decide to go that route. >> but at that point we can stand up a repo for ourselves. > > This comment by Pim makes me even think that we should keeping it in > Stretch. Because why else should upstream keep a Debian package > maintained in an external repo if a suitable server will be available > soon-ish? > >> Would you be open to resubmitting in such a scenario? > > Sure. Thanks! -- Pim van Pelt <p...@ipng.nl> PBVP1-RIPE - http://www.ipng.nl/
