On Mon, Jan 27, 2020 at 4:18 PM Chris Johns <chr...@rtems.org> wrote:
> On 24/1/20 9:57 pm, Jose Valdez wrote: > > In fact these tools target the pre-qualified project. > > Do you see this as different to the RTEMS project? > > > Since it was Sebastian who suggested to create this set of python tools, > > I think Sebastian is wanting a smooth path for these tools into the > project. > > > I think the idea was to standardize the use of python not only for this > project, but also for other python written code in RTEMS community. This > has the advantages that every written python code is standard, but has the > drawbacks: > > > > -> old written code would need to be adapted to the standards. > > How different to the proposed coding standard is the existing code? Why > not base > the coding standard on what exists in the code base? > This is a very important question. > > Have you evaluated the size of the task to update the existing code? How > would > get such changes for the rtems-tools and the RSB be tested and integrated > back > into the project? This apporach seems like a huge review task for me. > It could be or it may turn out that there isn't much changed. Without someone running the reformatter and reporting, we won't know. I tend to think it is worth knowing if this is a monster or a mouse before making a decision. > > > Another option could be leave it as it is and only do this for new > written code. > > It would be confusing to any new user to the code to have code written to a > standard and code that is not? If you edit the old code is it to the new > standard? If you edit an old file do you need to update the whole file? > If we accept a standard, then it is all or nothing. I'm going to sound like a cranky old man but we have said things like this before and regretted it every time. Consistency is critical. Quick run of sloccount for a baseline + rtems-tools - Totals grouped by language (dominant language first): ansic: 47237 (49.86%) cpp: 25837 (27.27%) python: 21227 (22.40%) sh: 442 (0.47%) + rtems-source-builder/source-builder - SLOC Directory SLOC-by-Language (Sorted) 14314 sb python=14169,sh=145 65 top_dir sh=65 0 config (none) 0 patches (none) So we have about 35K SLOC or Python by that. No idea how the new standard versus the old looks. I thought Python had a consistent style but I could be very wrong. :( > > > -> at some point some tools need to be upgraded (ex: python 3.7 will > become unusable in 2030 Operating systems). > > I am not sure how this relates. Yes it will need to update however we need > to > support python2 for user facing tools for a while yet. A lot of what we do > and > how we work is historically driven. > CentOS 8 was just released in October. None of the big organization users I see are using it yet. We need to make a LTS release with 5 on Python 2 as a minimum. I feel strongly about that. As long as the tools are written in a python agnostic manner, the version won't matter. We need some test cases for the tools to verify them > > > I hope soon to formalize our suggestion to you and then you may review > it (and propose changes if you find appropriate). > > I suggest working in the open and with us will be more beneficial in the > long term. > +1 I can't agree strongly enough. > Note, I am assuming the remainder of the email was Christian's. The > quoting from > your email client made it difficult to tell. > > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel