search

openitu / STL

The ITU-T Software Tool Library (G.191)
https://www.itu.int/rec/T-REC-G.191/en
Other
82 stars 26 forks source link

Doc: Delete MANUAL.pdf #144

Closed ludomal closed 2 years ago

ludomal commented 4 years ago

This is the 2009 manual. It is no longer necessary, especially because the manual is now automatically generated.

ludomal commented 4 years ago

Or maybe we should do it the other way round? Apply it to Master then merge it to dev? Master should be considered as frozen for the 2019 release (except for this deletion), and it will most likely always be behind dev.

dennisguse commented 4 years ago

I just always assumed that Dev would always be ahead of master and all accepted changes are merged into master from Dev rather than the other way around. Are there more changes on Dev that should not yet be merged into master?

ludomal commented 4 years ago

Sorry I have missed your last comment. On this occasion, the source code does not differ between the dev and the master branch. The only difference is on .gitignore and .travis.yml that were updated recently.

However maybe we should settle and write down the procedure, as it is possible that we have differences in the future.

When a new version of the code is submitted to ITU-T, the dev branch will be forked to keep track of the code submitted for standardization (the submission branch) . It usually takes several months for the standard to be ratified, and the documentation and code of that submission may be updated to accommodate requests from ITU-T. In the mean time, activities on the dev branch may carry on and from that point the code may differ.

Once the new recommendation is approved, the master branch should reflect the code from the submission branch, not the one from the dev branch. Changes from the submission branch should also be incorporated into the dev branch.

What should be the procedure?

simaocampos commented 4 years ago

Maybe a workflow diagram would make it easier to understand? S.

From: Ludovic Malfait notifications@github.com Sent: Tuesday, 26 November, 2019 14:58 To: openitu/STL STL@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [openitu/STL] Doc: Delete MANUAL.pdf (#144)

Sorry I have missed your last comment. On this occasion, the source code does not differ between the dev and the master branch. The only difference is on .gitignore and .travis.yml that were updated recently.

However maybe we should settle and write down the procedure, as it is possible that we have differences in the future.

When a new version of the code is submitted to ITU-T, the dev branch will be forked to keep track of the code submitted for standardization (the submission branch) . It usually takes several months for the standard to be ratified, and the documentation and code of that submission may be updated to accommodate requests from ITU-T. In the mean time, activities on the dev branch may carry on and from that point the code may differ.

Once the new recommendation is approved, the master branch should reflect the code from the submission branch, not the one from the dev branch. Changes from the submission branch should also be incorporated into the dev branch.

What should be the procedure?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/openitu/STL/pull/144?email_source=notifications&email_token=AEC4YAULWAWX6PZUHZZBMT3QVUTNZA5CNFSM4JJPPYDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFGCZHQ#issuecomment-558640286, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEC4YAVGC776HRHE6CHGGRDQVUTNZANCNFSM4JJPPYDA.

dennisguse commented 4 years ago

I created an (long) issue for the discussion: #146