Schanzenbach, Martin transcribed 7.0K bytes: > Hi, > > to clarify: having a (public) git hostlist server makes little sense because > git can break compatibility at any time (better: with every commit).
Sure, I agree. > Maybe if we had a system like other projects where we branch the development > off to another branch and "freeze" the protocol in master or a release > candidate branch this would be reasonable. This sounds reasonable, and we could talk about it at the meeting. I think dvn had ideas with regards to this, or at least how CI and CD could be used in a better way. Having a protocol stable branch would be a good start. On my end, I've been interupting peoples build with some texinfo errors, I should've moved this development to a branch aswell. > But a "git head"-hostlist server is bound to advertise all kinds of > incompatible peers. Inherently. > > => Better test git head/master in a local/dedicated testbed tied to the head > revision or your respective branch or you will get undefined results. > => GNUnet has a testbed built-in (I never used it though) > > BR > > > On 27. Oct 2017, at 09:03, Julius Bünger <[email protected]> wrote: > > > > I assumed it was already the case. Just that the recen release was a > > while ago. > > > > There is v10.gnunet.org/hostlist for the last release and > > gnunet.org/hostlist for git. > > (At least that's the way I read it.) > > > > > > On Fri, Oct 27, 2017 at 06:56:44 +0000, ng0 wrote: > >> Schanzenbach, Martin transcribed 4.5K bytes: > >>> Hi, > >>> > >>> I kind of agree. > >>> > >>>> On 26. Oct 2017, at 19:51, carlo von lynX <[email protected]> > >>>> wrote: > >>>> > >>>> On Thu, Oct 26, 2017 at 05:42:45PM +0200, Christian Grothoff wrote: > >>>>> 2) Yes, running in the 'global' network with outdated peers is likely to > >>>>> cause all kinds of fun problems, as the DHT may or may not work, or in > >>>>> the worst case the DHT discovers a path which then does not work on the > >>>>> CADET layer because some hop speaks just enough of the DHT protocol but > >>>>> not enough of the CADET protocol. > >>>> > >>>> Maybe the basics of protocol design aren't as > >>>> exciting as inventing new crypto paradigms, but > >>>> could we please increment the protocol number > >>>> each time a change is introduced that will not > >>>> be compatible with the past? > >>> > >>> Oh that is a problem in general in the OSS community and the reason Linux > >>> lost the Desktop as well. > >>> > >>>> Yes, I know that > >>>> only parts are incompatible - but I don't care. > >>>> There is nobody out there that we have to be > >>>> backward compatible for. We can increment the > >>>> protocol version identifier for each edit of > >>>> any CADET file for another year before the > >>>> whole thing is stable - and then, for the next > >>>> release we can just revert it to your favorite > >>>> number. > >>> > >>> I think we should not confuse development with the current GNUnet release > >>> topology. > >>> I know that those two are unfortunately mixed right now, but this is > >>> mostly due to the lack of a recent release. > >>> > >>> I guess we need periodical releases with each release having a new > >>> hostlist server for that release under [hostlist]: > >>> Example: > >>> SERVERS = http://gnunet.org/<releasever>/hostlist > >>> > >>> , thus ensuring a "pure" bootstrap. > >>> > >>> IMO development versions (i.e. from git master) should never ever connect > >>> to the "main" network of any release version and expect it to work. > >>> You need to bootstrap our own test topology if you want to test (e.g. > >>> with docker). > >>> For "production" use you'd need to wait for the next release anyway. > >> > >> What about an addition development hostlist server, would that work? > >> For example defined via > >> > >> ~~~ > >> [hostlist] > >> SERVERS = https://gnunet.org/git/hostlist > >> ~~~ > >> > >> or instead of git "dev". To record this version string would be easy. > >> > >>>> > >>>> Also, shouldn't all those "misbehaving" old nodes > >>>> be automatically bypassed thanks to our amazing > >>>> detection of sybil attacks? > >>>> > >>> > >>> I didn't even know we had that. But such a feature makes somebody with a > >>> git version to appear like an attacker, not the other way around. > >>> > >>>> Half a year ago we had a working CADET and a > >>>> frequently working gnunet-social. Why do we have > >>>> to go three steps back? > >>> > >>> > >>> We need a release at some point soon-ish (when is that meeting planned > >>> again? ;). > >> > >> It's in December (eV) and early/middle of January. > >> > >>> But if you are still developing I strongly suggest docker/docker-compose. > >>> If people are interested how to do that I can make a quick write-up. > >>> > >>> BR > >>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> GNUnet-developers mailing list > >>>> [email protected] > >>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers > >>> > >> > >> > >> > >>> _______________________________________________ > >>> GNUnet-developers mailing list > >>> [email protected] > >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers > >> > >> > >> -- > >> ng0 > >> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > >> GnuPG: https://dist.ng0.infotropique.org/dist/keys/ > >> https://www.infotropique.org https://ng0.infotropique.org > > > > > > > >> _______________________________________________ > >> GNUnet-developers mailing list > >> [email protected] > >> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > > > > -- > > > > ------------------------------------------------------------------------ > > I prefer to communicate via GPG-encrypted email. > > Key: D4E5F972B413F3B3 Keyserver: pgp.mit.edu > > ------------------------------------------------------------------------ > > > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org
signature.asc
Description: PGP signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
