2013/10/28 Christopher Sean Morrison <[email protected]>: > > On Oct 28, 2013, at 1:58 PM, Daniel Roßberg wrote: > >> 2013/10/28 Christopher Sean Morrison <[email protected]>: >>> I'm usually okay with a source-only releases known to not compile on one or >>> two platforms. >> >> Windows isn't only "one platform". It's widely used, even in the >> Army. Or you could look at the download statistics on sourceforge. A >> colleague has already complained to me about the bad quality of >> BRL-CAD. I said to him that he can not expect to have a compileble >> trunk every day, but a release? > > I hear your point. I didn't mean to imply an unimportance of Windows as a > distribution platform in the least. It's our dominant user platform, but > lacks a release maintainer.
That's not the whole truth: There is a maintainer for the Windows runtime libraries, aka brlcad.dll. > Until someone steps up to be a maintainer and actually be responsible for > that platform's functionality, I don't think we can make any guarantee. I > think that same holds true for all binary platforms. > > We can certainly consider changing our practice, but the current landscape is: > trunk: compiles on at least one platform, no guarantee as to which > RELEASE: no guarantee whatsoever, but is a staging ground for STABLE > STABLE: compiles on at least two distinct platforms, no guarantee as > to which > other branches: no guarantee whatsoever That's a very weak definition of stable. > Trunk and STABLE we're specifically set up that way to encourage frequent > releases (which we've not been good about). By design, that has meant source > releases will generally compile with minimal effort on any platform by > someone knowledgable of that platform. This sounds better, but this sentence contains a promise too. > Currently, posting a new source tarball only requires coordination of two > maintainers or one dev with access to two environments. ANY contributor can > initiate a source release any time so long as they follow the trunk->STABLE > release criteria. > > I can certainly appreciate the notion of the project guaranteeing compilation > on a set of "core" platforms, like we used to do, but I think that's the open > source community's collective responsibility. Forcing all core devs to > repeatedly check platforms was abandoned in order to promote a faster > development velocity many years ago, and I think this has largely been > effective and worthwhile. In general ok. But if somebody makes explicit changes to platform specific sections I personally would require to test it on these platform. I wouldn't dare to remove an "if(APPLE)" without testing it on MacOS. > To date, binary release have been delegated to platform maintainers with > myself handling Mac releases, Jordi handling Linux, Erik for FreeBSD, but > nobody for Windows. Basically, the intent is to eliminate any barriers > towards posting a release and delegate responsibility to as many people as > possible. I think what is needed is for someone to step up and say "I'm > willing to be the Windows platform maintainer", accepting responsibility to > sort out Windows build issues properly and post binary releases as needed. I am the maintainer of the Windows runtime library brlcad.dll. Since 7.8.2 for (almost?) every source release there is a brlcad.dll. No other binary has this much releases. It's only a very small library, it's size and complexity isn't comparable with a real BRL-CAD distribution. However, maintaining the DLL is mainly maintaining the MSVC build. Don't think little of it. I don't wont to receive the kudos for porting mged etc. to Windows. This wasn't me. However, don't let the gap for any core platform become to large. Daniel PS: I really haven't the time to maintain the whole distribution on Windows. But I've an eye on the build, check/debug Windows specific problems (e.g. with STEP) and try to reduce the workload for somebody who is willing to fill in as Windows maintainer. I.e. for the maintainer it should only be necessary to look at RELEASE/STABLE, MSVC should work in general. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
