On Tue, Dec 29, 2015 at 06:00:50AM +0000, Dan Good wrote: > Thank you for the feedback. I have a practical question - what is the > workflow for making changes to this module, now that it's been merged? Do > I clone, then branch, edit, commit, push, merge, and finally mail a patch > to the list?
That's one option. You can certainly continue to send patches to the mailing list for your own module as you could for any other module, or patches adding a new module. That's a good idea if you want some review on the patches, are looking for a second opinion or whatever. However, having been added to gitolite you're now also able to push commits directly to the master ccan repo - as long as they only touch files within "your" modules. To do this you need to add '[email protected]:ccan' as a remote to your git repository. If you do push commits directly, please do remain disciplined in making logically consistent commits with good commit messages (and Signed-off-by lines). The usual workflow for many contributors to many projects, including ccan, is to work in your own git tree for a while, but before pushing to the master, "polish" the commits. git rebase -i is very useful for this and allows you to adjust the history so you have a logical series of changes, with good commit messages. The idea is to have a "logical" history that would be suitable to send out as patches for review, even if you don't actually do so. > I'm still learning git. I've been on the rcs/cvs/svn > bandwagon for a long time. Yes, distributed version control and the different workflows it allows can take a while to get used to. In particular people only used to traditional vcs sometimes react in horror to "changing history" which git allows very easily and is very common in many free software projects. In practice, when it comes to the master tree of a significant project, the cleaned up "logical history" is generally more useful than incorporating all the details of experiments and since-corrected mistakes that usually happen during real development. > I'd like some clarification on the need for portability. Once I read your > comments, I came up with an ad-hoc list of platforms I felt I could > reasonably support: major Linux distros, FreeBSD, OS X, and OmniOS. I > tried the module on each successfully, though ccanlint needed changes to > build on everything but Linux, and the failtest based test went rogue on > two of the platforms. Right. So generally it's better to think in terms of specific required features, rather than supported platforms. Many of those already have #defines tested by the ccan configurator, and others can be added if necessary. I think the point here is not so much that we really expect use of common-but-not-standard features to break things in practice, but more that it's good to have reliance on these features documented in the code, to make life easier for anyone who does try to use this on some obscure compiler in the future. And yes, I'm quite sure there are many existing portability bugs in ccanlint and other parts of the existing infrastructure which would mask portability problems in your module. But that's not a great reason to increase the amount of non-portable code. > Compound literals are a feature of C99 (nice article: > http://www.drdobbs.com/the-new-c-compound-literals/184401404). Ah, yes, I'd forgotten that. I think we are generally assuming at least C99 availability in ccan, so that one's probably ok. > Intermingled declarations and code are also from C99. Half of the > platforms above use gcc and half use clang. Both gcc and clang support > statement expressions. The _XOPEN_SOURCE define in _info is there for > getline(3) on Linux which is used solely in the demo code in _info. > > Is there a set of platforms CCAN targets for support? Is there some way I > should document that the code is C99? Would the lines below be the right > way to handle the statement expression dependance? > > #if !HAVE_STATEMENT_EXPR > #error Sorry, deque requires statement expressions > #endif That's certainly the simplest way of handling this - see the 'minmax' module for an existing example which requires certain features (in particular note the Ccanlint: directive in ccan/minmax/_info). Better still would be having some fallback to avoid statement expressions, but that is often messy and occaisonally impossible. Using #error for now and adding a fallback in future if you can (or letting someone who needs it do so) is entirely reasonable. > > Thanks. -Dan > > On Sun, Dec 27, 2015 at 10:45 PM David Gibson <[email protected]> > wrote: > > > On Wed, Dec 23, 2015 at 12:11:44PM +0000, Dan Good wrote: > > > deque - type-preserving resizing circular deque > > > > Concept looks good. There are some fairly minor nits in the > > implementation that I've noted below. However, none are serious > > enough to hold up merging, so I've applied this. I did modify > > trivially to remove some trailing whitespace. > > > > It would be nice to address some of the comments in follow up > > commits, particularly some of the portability issues. > > > [...] > > > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
_______________________________________________ ccan mailing list [email protected] https://lists.ozlabs.org/listinfo/ccan
