DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    @FlightRisk , @Atani, would one of you two like to create this as a free/privately owned open source Github Organisation and add team members for code reviews/Pull requests? I believe that we need more than one person this time to be able to manage it so that it doesn't become orphaned again.
     
  2. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    I'm not sure it needs a registered host name unless someone wants to own/manage a site to contain stand alone documentation on it.
     
  3. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I'd gladly be part of the organization and help with code reviews etc. Having more than one person managing it will be critical to ensure long-term viability.

    Sent from my ONEPLUS A5010 using Tapatalk
     
    John W Zerbe likes this.
  4. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I will setup an "organization" and conver my repository over to it if we agree on a name. I like DCC++2020, just wondering if that dates us in 2021. I'm happy with it, but we could add "XP" or something instead ;)
     
    John W Zerbe likes this.
  5. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Atani generous of you considering all that's on your plate. We could use your experience.
     
    Atani and John W Zerbe like this.
  6. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    Frankly, I'd have preferred OpenDCC++ but it was taken.
     
  7. Mani

    Mani TrainBoard Member

    76
    15
    4
    What about DCC++ ex (ex == extension) ?

    Sent from my GM1901 using Tapatalk
     
  8. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I created a new organization on Github to move forward. The name is DCC++ EX, but because links can't have plus signs, Github named the link:

    https://github.com/DCC-EX

    Those who want to contribute to the project, please request access or PM me your Github username and/or email
     
    Atani likes this.
  9. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I would consider dropping Controller as it has been a non-stop source of confusion for many users over the years. I would instead push/recommend JMRI as it is more widely supported and can do everything that the old Controller interface can do and will allow the users a lot more flexibility in expansion as they grow their layout.
     
    vasilis likes this.
  10. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Add one more item to my previous list, LocoNet... A working implementation is available here for Throttle and Prog track usage and I know of at least a couple people who are interested in using the sensors/outputs via LocoNet but that would require a lot more work to implement since there is limited documentation on the LocoNet op-codes for this and there is limited consistency across devices for how they use it (there are a few great examples showing how to do this though so it is feasible, just a bit of work).
     
    rray likes this.
  11. Roger Beschizza

    Roger Beschizza TrainBoard Member

    58
    8
    3
    Having perused the READ.ME notes I an inclined to agree to a certain extent with you Atani. It seems that layout design and turnout ID [and who knows what else] is achieved by altering some of the code parameters. This is beyond my range of comfort especially as all that, and more, is readily and more easily sorted out via JMRI. I suppose worth doing for the DCC++ purist who knows how to code though. R-
     
  12. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    I had looked at LocoNet on Digitrax web site. It looks like they want people to purchase a commercial license for any use/implementations. Do we have permission to implement it?

    Another note on the github repository branches. I created a pull request to merge master back to development and recommend that any new features be merged there first. Only when we are ready to to release a new numbered version should updates be merged to master.
     
  13. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Yes and those who have a lot of time to spend on learning the internals of the app/code. It is not exactly beginner friendly or extendable without a lot of work.

    There is a personal use license which is what is used for the MRRWA LocoNet library which is based on the LocoNet PE documentation that DigiTrax has provided for free many years ago (and has not maintained or documented everything!)

    I saw that PR and I am not sure it is worthwhile to merge or not. It may be easier to simply delete the development branch entirely and recreate it. However, that does bring up a question on development model to follow. If you look at my ESP32 CS code I am using the development branch for major changes but I would instead recommend a different approach since there will be more people contributing to the code over time. I would suggest the "feature branch" model which basically is all work for a feature or bug fix would be done in a private branch and submitted via PR to "master" (or release branch as appropriate). The only add-on I would recommend to this would be to ensure the changeset of the PR be as small and focused as possible since larger PRs are very challenging to review accurately.

    On the GitHub side, we should also setup GitHub Actions to test build all PRs (example) and possibly integrate with Codacy (example), both of these are free options to enable on a per-repository basis.
     
  14. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Atani like this:

    https://gist.github.com/vlandham/3b2b79c40bc7353ae95a

    You can set that up if you want. We should put a read.me somewhere to provide the steps to people.

    If I already have a local clone of your master that is now in my own branch, how would I rename that and push it up to GitHub or make a pull request if that is the right way? I made changes and commits locally. Do I create a new branch locally and use pop and push? Moving from subversion and my old habits is hard. ;)
     
  15. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    The model we use at work (I work for a large bank) is "feature/ticketid" branches for new features and "bugfix/ticketid" for bugfixes. Those are codereviewed and merged to "development" branch. We then decide whether the combination of features is ready for release and only then merge to master.

    I have no problem with closing that pull request and simply deleting / recreating the development branch. I would prefer that we keep master as the current "stable" release and "development" as the branch that people can use to try out the newest features. We can use github "issues" as the ticket ids since I'm not sure its worth using a full blown Jira type system for defining/tracking the changes.

    I like your examples for build/scan automation. We use private Jenkins/Sonarqube, etc here so I'm not as familiar with what's available in this space for free tools to automate public github.
     
  16. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Pretty much yes, I didn't read through it fully but it is definitely a start towards a better development model when working with multiple people contributing.

    Probably easiest to do it directly in the GitHub UI. But before we do this we should decide on the below.

    This is close to what we use where I work as well (major tech company). We typically use "master" as "next release" with release specific branches for the actual release and any bug fixes required post-release.

    I'm fine with whatever is decided upon, it needs to be decided early and stick to it.

    Using the Issues feature is preferred as you can reference them from commits and GitHub will auto-link and close issues depending on the text of the commit message. It is also publicly accessible so anyone can contribute to the backlog.

    We also use similar systems for our builds and GitHub Actions can provide virtually all functionality required and if it doesn't provide something we have control to implement it how we need. For the example CI you can see how it is done here and here. Codacy is integrated via WebHooks on the repository.
     
  17. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    I like this approach.
     
  18. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    100% agree. If people like the controller/don't like JMRI then I think that is a separate project entirely and indeed has lots of good info out there we could link but I would avoid working the controller/UI in this repository.

    @Atani if you could add me to the github editors please use kwledbetter there.
     
    John W Zerbe likes this.
  19. John W Zerbe

    John W Zerbe TrainBoard Member

    96
    59
    7
    @Atani, @FlightRisk , @Keith Ledbetter , How about we just use the gitflow model that many people are familiar with. Feature branches named feature/git-issue-id, bugfixes as hotfix/git-issue-id, releases as release/release-number. development is where new tested features get merged together. master is next potential release.
     
    Atani likes this.
  20. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    sent...

    This would work well, just needs to be agreed upon by everyone as the model to use and we can use it.
     

Share This Page