Am Donnerstag, den 24.09.2009, 12:57 -0500 schrieb Jeremy Hankins: > Christopher Roy Bratusek <zanghar freenet de> writes: > > >> Improving the code does not mean the > >> code itself, it means to improve the coding-style for better > >> readabilitly (also remove all whitespace, as changes in it break patches > >> easily). > > So this means line breaks and such? Or what sort of things do you have > in mind? Exactly, linebreaks, indention & co. > I'm guessing not actual code re-orgs and renaming, since that > seems to be for team 2. > As for whitespace, do you mean removing trailing whitespace? Or > replacing tabs with spaces or spaces with tabs? Or just proper > indentation? Much of this could be done automatically (via tr/sed, > and/or emacs). both (unnecessary) trailing and leading whitespace > >> Theoretically this can be done by anyone, as it does not > >> involve real code-changes. So is there anyone willing to volounteer, > >> this is considered a long-term task beginning asap and ending with 3.0 > > > > thinking about it, it would also include something like moving from > > > > (defun foo (params)) to (define (foo params)) > > This could be done via sed too, but it'd have to be tested it to see if > it generated bugs. I don't care how, as long as done properly. > > and to add some more comments / improving docs > > This is worthwhile, but editing the comments would probably require at > least some lisp knowledge. Shouldn't that go along with changing the > docstrings? perhaps you're right. > >> While it would be nice to at least have one person in the team with good > >> lisp-knowledge, as I'm sure it may also lead to some (small) bugs beeing > >> found/squashed. > >> > >> 2. > >> *************** > >> > >> Better strings and command-names. sawfishs strings and naming scheme is > >> a mess. This teams work is split in two: > >> > >> Sawfish 1.x: only doing string changes and renaming internal variables. > >> > >> Sawfish 3.0: renaming commands & co. Ignore compatibility for 3.0 > > > > for 3.0 another possibility would be to also rename modules so that they > > have better names, too. > > Would the 3.0 stuff be done during a freeze of some kind? If lots of > little changes are made everywhere in the code it seems like it would be > a headache to merge in more substantive changes. Where's always a freeze for atleast one month (the last in the cycle (obviously)) > >> ... > >> What do you think and who would like to volounteer? > >> > >> Chris > > > > >
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil