On 2014-09-22 15:17+0100 Phil Rosenberg wrote: > However the cost [of this change] is that arrays in the plstream will all become structs so will need accessing by somearray.mem[index] or maybe somearray.getMem()[index] rather than somearray[index]. This has the potential to break some or all the drivers. Although the fixes might be trivial, I don't have easy access to all the drivers on my windows machine.
> I'm therefore looking for a suggestion of how to proceed. I can transfer stuff to my Linux machine, but I'm not sure how best to do that with git. I could create a fork on github so other developers can contribute, but if I create a public fork then we should merge that into the master branch rather than rebase it which I think is not compliant with our current workflow. Hi Phil: Publishing your experimental development branch using github or our SF repository might be a tempting way to share it for evaluation, but the rebase steps of just keeping up with master or rebasing before you merge with master become problematic since all the commits on your branch get changed into new commits by that rebase. The result is the old set of commits for you branch eventually get garbage collected, leaving users of that old set of public commits high and dry which, of course, is a situation to be avoided. >From what I have seen as a result of lurking on several development lists where git is being used, it is quite common to communicate experimental branches using patches between core developers rather than by making the branch available via public git access. That is, they use "git format-patch" to create a series of patches of their work which they attach to development-list e-mails, and others on the list apply those patches to some experimental unpublished branch of their own using the "git am" commmand. They then test that experimental branch all they like and even make changes to it which they share back with the original branch developer via "git format-patch", etc. Given our rebase workflow constraints, that is the way I suggest you share your experimental branch work with the rest of the core developers here with the further understanding that nobody pushes that work to any publicly accessible git repository for the above reason. Once the branch matures (with hopefully more than one developer testing it), then your final job for that experimental branch would be to rebase your private version of that branch and merge it to master. Note that once the core developers here with a lot of C experience agree that your experimental idea is a good one, then I would encourage you to go ahead and quickly rebase your changes and then push them to origin master. This "quick-push to master" philosophy is possible with PLplot because of its nice architecture that keeps driver changes largely isolated from each other and also from core library changes. That is, as long as your approved changes don't interfere with building PLplot, and run-time tests for at least some of the drivers work, then we can figure out the rest using fixes to the master branch version. Note when your experimental series of patches is published to this list, I would leave to others with more C experience the judgement call about whether your changes are the right way for us to go, but I would certainly be happy to give you feedback based on how well the result builds and runs on Linux for each device driver there. Of course, to answer your last question, you can proceed on Linux by simply cloning the official SF repo, followed by using git am to apply your experimental branch patches to an experimental branch of that local repo. followed by build and run testing on Linux. In fact, it sounds like you would want to do that test before publishing your experimental patch series here. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
