Re: Coding standards / spaces vs tabs
Bron Gondwana wrote: > This is the kind of thing that we really need coding > standards for. The prevailing spacing standard for > the cyrus codebase is: > Yup we do, I had looked for the doc. you mentioned Greg had made but I couldn't find it. Sorry to have jumped the gun on this! > Now I happen to think this is approximately one of the > shittiest coding standards ever - but unless we all > agree to change it, rewriting functions to use different > indentation styles is counterproductive. > Can I motion we change it up? Whether it be 4 spaces to a tab or 4 tabs to a space, I don't care, but I love it to be consistent across all files and definitely on one single line. > So please don't. > I won't do it again that's for sure. > P.S. Here's what I use in vim to make life worth living. > It makes tabs visible, and lets me indent blocks quickly > by 4 characters while creating the correct tabs. > > set tabstop=8 > set softtabstop=4 > set shiftwidth=4 > set listchars=tab:>- > set list! I think whatever coding standard we come up with can be in these little vim footers you see every once in a while, right? FWIW, I would then also like to :argdo normal gg=G over all files to correct the indentation best vim can. FWIW^2, I would then also like to remove all trailing spaces sed -r -i -e 's/\s*$//g' `find * -type f` style. FWIW^3, I would then also like to remove all CVS Id/Exp headers sed -r -i -e '/.*Id.*Exp.*\$\s*$/d' `find * -type f` style Regardless, any of such changes will have to freeze up development for just a moment, since rebasing / merging any pending changes will most likely not succeed after these changes have been pushed. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Coding standards / spaces vs tabs
On Thu, Oct 21, 2010 at 01:56:03AM -0500, Patrick Goetz wrote: > On 10/20/2010 9:05 PM, Bron Gondwana wrote: > > > >P.S. Here's what I use in vim to make life worth living. > >It makes tabs visible, and lets me indent blocks quickly > >by 4 characters while creating the correct tabs. > > > > If everyone uses vim, then this problem is easily resolved: <:) > > set tabstop=3 > set expandtab 3? Why three? Bron.
Supported Platforms (was: Re: Cyrus IMAPd 2.4.1 Released)
Matt Selsky wrote: > Can we decide on a list of supported platforms and document it, ala > http://k5wiki.kerberos.org/wiki/Supported_platforms > > Then we can at least compile-test on these platforms. And maybe even > upgrade-test these platforms before each release? > I'm working on a documentation effort beyond what would be feasible to include in imapd.conf(5), which would include such list of supported platforms. I'd think a Wiki article would serve similar purpose as well. Similarly, Bugzilla would need to be updated to reflect a final list of platforms supported. Can I get a show of hands who's platform is not listed in the following list to log a ticket in bugzilla (preferred) and/or nudge me (bugzilla will nudge me either way)? - FreeBSD - Linux - Solaris In the interest of full disclosure, my work-in-progress is currently at[1,2]. Noted that if you do add or suggest a platform to the list, we might/may/will request the reporter of such bug to provide our release engineer(s) with access to such box, or inclusion to Hudson CI when we're good and ready. Thank you in advance, Kind regards, [1] http://www.cyrusimap.org/~vanmeeuwen/cyrus-imapd-2.4- docs/Deployment_Guide/html/sect-Deployment_Guide- Supported_Platforms_and_System_Requirements.html [2] http://git.cyrusimap.org/cyrus-imapd-docs/ -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Cyrus IMAPd 2.4.1 Released
Greg Banks wrote: > Bron Gondwana wrote: > > On Tue, Oct 19, 2010 at 08:41:51AM +0100, Jeroen van Meeuwen (Kolab Systems) wrote: > >> Since we're on the subject... > >> > >> Please consider allowing me to deploy Hudson Continuous Integration. > > > > I heartily endorse this product and/or service. > > We used Hudson at my last job. Hudson rocks, assuming that the build > (including any regression tests you run) is stable and predictable. > It's very important to avoid spurious build failures, because that just > gets the Hudson emails ignored, which takes away all its value. > Like all good things in life, Hudson too requires some love and attention every once in a while ;-) > > Greg is looking into testing as well. I should put you two in contact! > > Hi Jeroen :) > Hi Greg, nice to meet you! Sorry for the late response, besides $dayjob Bron reminded me I need to not touch code in the master branch and so we worked on that a little ;-) > I've been looking at the testing angle for three reasons: > (...snip...) > In the short term I was hoping to get some point regression tests for > some of the lower-level code happening. I was thinking of using CUnit > http://cunit.sourceforge.net/ to help manage the tests. Thoughts? > I have no interest in any particular suite, and I'll probably fail in writing tests in as many miserable ways as I do committing some new code to master and breaking it. That said, I do have an interest in getting this going ;-) One thing that did come to mind was Hudson does not have a stock plugin integrating the CUnit reports with its jobs... I'm assuming such functionality is only suitable for people like me though, so this won't be a show-stopper. > After that I was hoping for some end-to-end regression tests using IMAP > and POP3 clients written in Perl, and maybe do a test coverage study. > Rob Mueller tells me there's no official Cyrus regression test suite > currently, although he did point me at a Perl script he wrote back in > 2004 that might be a good starting point. Thoughts? Doing one thing on one end of a client-server model before/after doing another thing on either end is a particularly complex scenario to automatically execute. That said, I think AutoQA (a Fedora Project development effort) is supposed to service exactly that. Mind though that'd be on the framework level, and test execution would still have to be written for any tests to happen; Existing perl scripts will certainly help! Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Coding standards / spaces vs tabs
On 10/21/2010 7:10 AM, Bron Gondwana wrote: set tabstop=3 set expandtab 3? Why three? Einstein said "make everything as simple as possible, but not too simple". I think a similar principle applies to indentation: indent as little as possible, but not too little. When I first started coding again 10 years ago because both the programmers I was working with abruptly quit for personal reasons, leaving me (and the client) in the lurch, I inherited a bunch of code where tab was used exclusively to indent. In my opinion, tab = 8 characters indentation is ridiculously unreadable. With just 3 or 4 nested blocks your lines start halfway across the page, increasing line breaks. When I discovered tabstop and expandtab in vim, I realized that I could make the indentation anything I damn well pleased and it would automatically be invoked in any file I edited. And since I was the only one working on the code at this point, my opinion was the only one that mattered. After playing around a bit, glancing at a bunch of code to make sure nested blocks "jumped out" visually, etc., I determined that -- at least for me -- 3 spaces was the optimal number; 2 wasn't enough, 4 excessive. Re: using 8 space tabs. This is the point where someone says "what are you talking about? Everyone has 24" 1900x1200 monitors these days; you can have a terminal which is 300 characters wide!" Yes, and I can also go blind staring at it 8 hours a day -- I'll pass. Re: using tabs for indentation at all: especially given the somewhat disturbing growing ubiquity of python, getting in the habit of using tabs for indentation is like giving a box of matches and a stick of dynamite to your pet monkey. It seems innocuous enough, but sooner or later a tragedy will occur. Mixing tabs and spaces;especially given that the width of tabs is user-definable? Add to the preceding showing the monkey how to light the matches and throw in a couple of liters of gasoline. And yes, I'm aware that Makefiles require tabs; this is just one more indication that make is obsolete and needs to be rewritten from scratch using modern programming paradigms. I know talking about indentation is like starting a "vi vs. emacs -- which is better?" discussion, but you asked. -- Patrick Goetz
