For point 1. We compile code almost every day and for every commit. The commits do not go through if there are compilation failures. I haven’t heard any complaints about DKMS too.
Maybe there are issues indeed, but as of now its more likely that you are doing something different. Thanks, Anand On 5/17/17, 11:20 AM, "Dev on behalf of Valentine Sinitsyn" <[email protected] on behalf of [email protected]> wrote: >Hi, > >Those are valid points. I'd add a few more, if you don't mind: > >1. Code quality (esp. in master branch) >I've encountered undefined macros in vrouter-dpdk and shell escaping >issues in dkms scripts at the very least. Sure, this is trivial to fix, >yet it makes me think that either no one tried to compile those >components besides me (as this fails immediately) or I do something >awfully wrong. Which brings us to the second point: > >2. Public CI, maybe via Travis/Github badge >This is to make sure the code works at least in some environment, so I >can figure out what's wrong with mine. Aside issues mentioned above, BGP >stress test is failing now as well, and there is no way to figure out is >it my fault or the thing is currently broken. > >Setting clear expectations for master branch (such as: "may not even >compile", "should not break the testsuite, but may fail in corner cases >or under load", "we try to keep it as stable as possible and develop in >feature branches") would also be very helpful. > >Randy: enjoy your TBO! It was my pleasure to be at OCUG in Boston. > >Thanks, >Valentine > >On 16.05.2017 01:50, Edgar Magana wrote: >> Folks, >> >> >> >> These are all excellent points. Would it be possible to have all these >> details in github repos? >> >> That will be easy to follow up the conversations instead of using email. >> Well, just my proposal. It is working well for other open source >> communities such as OpenStack. >> >> >> >> Thanks, >> >> >> >> Edgar >> >> >> >> *From: *Dev <[email protected]> on behalf of "CARVER, >> PAUL" <[email protected]> >> *Date: *Monday, May 15, 2017 at 5:06 AM >> *To: *"[email protected]" <[email protected]>, >> "[email protected]" <[email protected]> >> *Subject: *[opencontrail-dev] Slide deck from the OCUG meeting >> >> >> >> Randy, >> >> >> >> Thanks for your presentation at the Open Contrail Users Group last week. >> Can you please post a public link to your slide deck for people who were >> unable to attend or who didn’t take phone photos of every slide. >> Especially, the link to the Google Group needs to go out so that >> everyone on the Dev mailing list can sign up. >> >> >> >> I have a list of potential topics for the first meeting of whatever >> forum you end up organizing. >> >> >> >> * Compiling Contrail from source – There has been a fair amount of >> discussion of this on the mailing list recently >> o Discussion of issues people are encountering >> o Build scripts >> o Prerequisites >> o Documentation of the build process >> * Due dates >> o An overview of current key dates in the process (blueprint, code >> complete, testing, documentation, beta, GA) >> o Discussion of any changes that might help contributors plan better >> o Dates for dates – set expectations on how and when the key dates >> for future releases will be set >> o Missed date management – discussion of how slipped dates for >> Juniper’s GA release impact community development >> * Testing procedures >> o Discussion of how third party developers should expect to >> interact with Juniper during the time period between code freeze >> and beta and GA >> o Discussion of beta vs release candidate and whether there are >> process improvements needed in order to ensure that third party >> developers are able to catch and fix bugs in the features they >> are developing >> o Overview of test framework, not just unit tests but functional >> and full stack automated tests >> * Documentation >> o How are non-Juniper developers expected to deliver documentation >> for features that they develop? >> o When is documentation due? >> * Core reviewer / TSC / meetings >> o What are the expectations for a non-Juniper developer to become >> a core reviewer? >> o Does Contrail have anything equivalent to a Technical Steering >> Committee? >> o Are there any regularly scheduled meetings (e.g. on Slack/IRC or >> teleconference) for developers to sync up on progress of their >> changes, discuss code reviews, discuss bugs, etc >> o Build system problems – How can non-Juniper contributors >> effectively troubleshoot issues like this: >> >> https://jenkins.opencontrail.org/job/ci-contrail-vrouter-systest-ubuntu14-mitaka/480/console >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jenkins.opencontrail.org_job_ci-2Dcontrail-2Dvrouter-2Dsystest-2Dubuntu14-2Dmitaka_480_console&d=DwMFAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=672AiZ61UGMFTc1WfPGBmgJYUEzVnbC9i9hqKSlloZo&s=j-50PyEc_ppikIVehQAGlLvpHxEL8q7515cEI087XEo&e=> >> >> >> >> >> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >> > >_______________________________________________ >Dev mailing list >[email protected] >http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org _______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
