Thanks for the feedback everyone! I'll try to comment on some of the things mentioned.
Indeed. I do not know if what you have in mind about coding theory somehow > overlaps with combinatorial designs (in particular orthogonal arrays/BIBD > :-P) but it would be nice to shake those areas of Sage anyway. > What we really feel is lacking right now (with respect to our own research areas) is a structured (i.e. object oriented, modular) way to deal with families of error-correcting codes, from various angles. Thus, the main priority is to introduce such a structure, as well as expected functionality for the most familiar families of codes (e.g. those everyone meets in a graduate course on coding theory). We are not combinatorists, so we know this angle poorly. Please join the discussions about structure etc. when we do this on sage-coding-theory <https://groups.google.com/forum/#!forum/sage-coding-theory> to make sure what we come up with makes sense from that angle! > Make many small tickets. The best way to not have many dependencies is to > have your code integrated into the successive beta versions of Sage, this > way your 'current code' will never be too far from the develop version. > > Whatever happens, please, don't come some day with 3Mb of changes. Respect > our development process: write tickets, get them reviewed. Writing code > takes much longer than reviewing it, so if the three of you can work by > reviewing the code he writes everything will run smoothly. > > Also, each commit message should begin with "trac #number:", otherwise it > is a mess to know which commits belong to which ticket when you have many > dependencies. > Thanks, this is good advice. We are very aware of the threat of patch-bomb - this will not happen, I promise. However, in the very beginning (and only here) we will play around the OO-structure until we feel sure that it works as we would like. We'll discuss details on sage-coding-theory. Once we're preliminarily satisfied, we'll brake it into logical pieces and make tickets. After that, the new functionality will all be implemented as tickets directly. > Once more: please, don't try to shortcut the review process. Play it fair. > Don't develop everything in your office only to come back later expecting > us to merge everything at once without reviewing it. Please create tickets, > please discuss the implementations on the tickets, please review > everything. Sage's review process makes things slower, but if you are 3+1 > to be interested in this project you have the manpower (and the will) to do > this properly. > We were actually concerned that it would be regarded as too inbred if we review David's code? > I will be glad to help whenever I can. It sure is a a good news. > Cool :-D Working with Vincent on Combinatorial Designs (many tickets between beta > releases) taught us that it is better to 'artificially' order all tickets > linearly. Each ticket should have a successor and a predecessor, and they > should all be linearly ordered. It is tempting to let some branches be > independent, but if for some reason you find out later that they still > interact somehow it will create a *LOT* of mess if you already have tickets > based on those two branches. > Hmm, this is a very interesting idea. We'll think about doing something like this. This is great news! Is there any plan to implement semaphore codes in the > near future (see the book by Jean Berstel > <http://www.goodreads.com/author/show/399140.Jean_Berstel>, Dominique > Perrin <http://www.goodreads.com/author/show/926712.Dominique_Perrin>, > Christophe > Reutenauer > <http://www.goodreads.com/author/show/399139.Christophe_Reutenauer> on > "Codes and Automata")? This would be super useful! > Sorry, that's not in our road-map currently. The project will be centered around error-correcting codes, with a focus on algebraic coding theory. We'll also be touching upon the cryptographic applications (e.g. McEliece cryptosystem). Also important: start small, fix a few bugs just to get used to the Sage > development model. > Yes, this is important. That's on David's todo-list for next week :-) Try to make this person attend a Sage Days early on. > Good idea! We'll keep an eye out for one which fits. Also, there is the GroupeUtilisateursParis <http://wiki.sagemath.org/GroupeUtilisateursParis> which he should join. The goal should be to have code with *positive_review*, not just to have > code. There is no point in continuing to produce more code if there are 10 > needs_work tickets. > Totally agree! But there might well be 10 needing_review tickets :-) I think it would also be a good idea to get in contact with the matroids > folk who got a lot of code integrated into Sage some time ago. Or even > better with Eric Gourgoulhon whos currently writing a lot of code for his > project and getting it integrated into Sage piece by piece. On top of that > he's not so far away from Polytechnique... > Thanks, we'll look into it, but see my clarifications on the main focus above. Johan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
