[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22
> > * Can we adopt on principle removing all cpp guards on protos? > Why would this be a good idea? > What does "cpp guards" actually refer to? Upon re-reading this I *think* what they mean is stuff like #if CONFIG(SOME_OPTION) void function_prototype(void); #endif and not what I'd usually call "header guards": #ifndef THIS_FILE_H #define THIS_FILE_H ...file contents #endif /* THIS_FILE_H */ Cleaning up the former sounds reasonable to me, we already tend to avoid that for new code because it's just less clutter without really causing a problem (declaring extra prototypes don't hurt anyone), and it avoids problems with code that is unreachable but still compiled when CONFIG_SOME_OPTION is disabled. > Guys, it is a bit tricky to prevent discussions in a call when someone brings > up a topic, and I'm not sure that blocking that is useful. The meetings are > open and particularly people commenting here have been invited to the calls. > Please make use of that opportunity and join, if you think that you have a > strong opinion. I think I got a bit spooked because the minutes were hard to understand and the "no decision made for now" sounds like another big change to how we are writing code at the moment might be coming down there in the future. If it's just a cleanup to conform to what has mostly been recent practice anyway it's not that big of a deal. In general I think it's fine if you discuss things on the call as they come up, but if you notice that it's something that would interest the community at large (e.g. proposed style changes) it would be nice if you could summarize any discussion/opinions you had in an email afterwards and then continue further discussion on the mailing list. I guess that's somewhat what these minutes are, they were just a little unclear in this case (and it would probably better to have a separate topic for things of wider interest). ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22
Guys, it is a bit tricky to prevent discussions in a call when someone brings up a topic, and I'm not sure that blocking that is useful. The meetings are open and particularly people commenting here have been invited to the calls. Please make use of that opportunity and join, if you think that you have a strong opinion. In this case, I made the suggestion to look at what is located in each heater file and cone up with clear interfaces, rather than jumping into the next "let's make coreboot source more similar to go by removing headset file guards" discussion. On Thu, 23 May 2019, 16:43 Julius Werner, wrote: > > >* We should be more strict about how we define our blocks’ APIs. > > > > Ok, but.. I just don't understand this proposal? Can someone explain? > > I second this... this sounds like another code style > discussion/change. Can we please keep all code style discussions on > the mailing list? Or if there really needs to be a VC meeting for such > a discussion, can it be pre-announced so everyone interested can > participate? > smime.p7s Description: S/MIME Cryptographic Signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22
> >* We should be more strict about how we define our blocks’ APIs. > > Ok, but.. I just don't understand this proposal? Can someone explain? I second this... this sounds like another code style discussion/change. Can we please keep all code style discussions on the mailing list? Or if there really needs to be a VC meeting for such a discussion, can it be pre-announced so everyone interested can participate? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22
Martin Roth wrote: > * Can we adopt on principle removing all cpp guards on protos? Why would this be a good idea? What does "cpp guards" actually refer to? >* Add cleanup task - remove guards specifically around prototypes? >* Having the prototypes outside of guards turns a compile time > error into a linker error. Those sound like drawbacks? >* We should be more strict about how we define our blocks’ APIs. Ok, but.. I just don't understand this proposal? Can someone explain? Thanks //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
