search

dedis / kyber

Advanced crypto library for the Go language
Other
630 stars 170 forks source link

`experimental` tag #279

Closed ineiti closed 6 years ago

ineiti commented 6 years ago

For dedis/cothority#1056 we need experimental code. if we keep the

cothority.v2 -> onet.v2 -> kyber.v1

and

cothority.master -> onet.master -> kyber.master

then we can put the evoting code in master, but not in v2. And as such we don't need the experimental tag anymore.

kc1212 commented 6 years ago

That sounds reasonable to me.

nikkolasg commented 6 years ago

Not saying I want to keep the experimental tag but how hard would it be to just add it to the cothority testing "flow" ? Just for comparison. I'm not saying I absolutely want to keep it, but back at the time we spent quite of time working on what should be exp and what should not and how to keep it tight etc, and just getting back to the old state because "it does not work as-is" seems a little bit an abrupt approach to me. We should first check if it's feasible at all to compile with the exp flag and see what are the pros and cons of both approaches and then decide. It might turn up that indeed this flag is just stupid and encumbers everyone by adding a 200 lines to each code that uses it. But it might not and in that case, the price of the tag is still worth it.

ineiti commented 6 years ago

When we added it, the goal was to separate the experimental code from the stable code. Then Bryan came along with the idea of having a script to create a stable branch using gopkg.in. This brings us now to three levels of maturity:

  1. stable code in kyber.v1 (defined by the stable/directories)
  2. half-stable, changing code in kyber.master (things not defined in stable/directories, but not marked experimental)
  3. experimental code in kyber.master using the experimental tag

I think the following is enough:

  1. stable code in kyber.v1 (defined by the stable/directories)
  2. half-stable, changing code in kyber.master (things not defined in stable/directories)

Of course, for something like the incoming dedis/cothority#1056, it will not get into the stable/directories of cothority and as such not go into cothority.v2 as long as the corresponding libraries in kyber are not in kyber.v1.

So I vote +1 for having 2 levels of code maturity only.