On Oct 29, 2013, at 08:26 AM, Daniel Roßberg <[email protected]> wrote:

That's not the whole truth: There is a maintainer for the Windows
runtime libraries, aka brlcad.dll.
 
I wasn't going to volunteer you for more work! :)

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.

Intentionally.  Suggestion for a change?  I think Tom's point is spot-on regarding continuous integration. With CI set up, we can add a STABLE constraint that our CI test hosts (whatever they may be at a given time) must all pass compilation.

Any dev should be able to freely perform a release.  I do not want to require anyone buy a commercial operating system that they don't use nor have a release held up because the guy that usually builds on platform X is on vacation.  If we have a dashboard, this problem obviously goes away, but is the reasoning behind the current "at least two platforms" definition for STABLE.

An aside note: the emphasis for STABLE is on behavior conformance, not compilation.  That's the release maintainer's responsibility and each dev for their respective platforms they work on.

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.

A couple promises.  
"Minimal effort" is obviously an ill-defined promise, as to some minimal means "no".  

We promise frequent release too and don't release nearly frequently enough.  I'm hesitant to put more restrictions or complexity on our process until that is in order.  Obviously, CI will help with both.
 
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.
 
Not in the least, and I realize that effort has been HUGE and sustained.  I just wasn't willing to "you are the Windows maintainer", interested in being responsible for noticing, investigating, and fixing Windows build failures; testing and fixing during release; creating and posting the binary installer; improving the installer; etc.  It's a lot of work beyond just compiling on Windows.

Someone needs to volunteer their time towards that responsibility.

However, don't let the gap for any core platform become to large.
 
Ditto.  As it is, we do a pretty bad job even on Linux because of distro variety (we test very little variety).  Every release, I hit up compiles on three or four distros and invariably one will fail.

tl;dr We need CI set up.

Cheers!
Sean

------------------------------------------------------------------------------
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

Reply via email to