Doc: Delete MANUAL.pdf

[ludomal]

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

[dennisguse]

Should be coming from 'dev'.
Otherwise master and dev could diverge, or?

[ludomal]

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]

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]

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]

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 GitHub<#144?email_source=notifications&email_token=AEC4YAULWAWX6PZUHZZBMT3QVUTNZA5CNFSM4JJPPYDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFGCZHQ#issuecomment-558640286>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEC4YAVGC776HRHE6CHGGRDQVUTNZANCNFSM4JJPPYDA>.

[dennisguse]

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