Trial issueshttps://forge.etsi.org/rep/li/trial/-/issues2020-09-21T15:42:18Zhttps://forge.etsi.org/rep/li/trial/-/issues/8Import 101 671 history2020-09-21T15:42:18ZLuke MewburnImport 101 671 history101 671 is imported by 102 232-1. Having the asn and the history in the forge of 101 671 would be useful.101 671 is imported by 102 232-1. Having the asn and the history in the forge of 101 671 would be useful.https://forge.etsi.org/rep/li/trial/-/issues/7Last pre-5G version of 102232-1 from LI#49 Zagreb meeting has wrong line endi...2020-08-19T15:48:31ZbaxterpLast pre-5G version of 102232-1 from LI#49 Zagreb meeting has wrong line endings (as does all of 102232-2)c2ff3aee273ffbc37fe16383cecda2f1bd5701ee
Mostly 102232-1 asn1 versions are OK, except this one.
New (renamed) file is stored with old style mac line endings.
This is the last version snapshot before 5G kicks in so worth getting right?
...c2ff3aee273ffbc37fe16383cecda2f1bd5701ee
Mostly 102232-1 asn1 versions are OK, except this one.
New (renamed) file is stored with old style mac line endings.
This is the last version snapshot before 5G kicks in so worth getting right?
Also appears that most (all?) of 102232-2 checkins also suffer from this line ending problem.
Also checked other TCLI folders and these appear OK at least at head (didn't go back into histories)
Viewing in gitlab on screen looks OK until you try and copy the file then you get extra empty lines. Gitlab WebIDE view also shows the problem, as does copying of files via various mechanisms.
Gitlab has a known issue that it tracks the input EOL rather than normalising. So mac based check-ins can be problematic.
Workaround - as rewriting git history is fiddly
Checkout as is with the mixture of \r (mac) followed by \n\r (win)
Use your favourite editor to replace \r\n with \n - file will now be correct as a win file
Maybe trim trailing spaces?
Save as corrected file
https://forge.etsi.org/rep/li/trial/-/issues/6portal folder history2020-08-19T13:38:53Zbaxterpportal folder historyRationale - very difficult to compare the history of asn.1 or schema versions without a lot of different checkouts and copying
Perhaps the portal folder could contain all versions of the asn.1 and/or xsd rather than just the original na...Rationale - very difficult to compare the history of asn.1 or schema versions without a lot of different checkouts and copying
Perhaps the portal folder could contain all versions of the asn.1 and/or xsd rather than just the original names of the current version.
e.g. 102232-1 portal containing LS-PS-PDU,ver30.txt but also ...ver29.txt ...ver28.txt etc
Trickier for other multi-file/multi-folder specs. May need portal/verXXX/<multi files/folders>
Alternative solution may be to provide some scripts that automate a couple of queries:
1. Show me all the changes from a particular meeting or set of meetings
(requires a checkout per spec from meeting X tag back until hitting meeting X-1 or X-N tag)
2. Show me the change history of a particular spec between meeting X and X-N (or by date)https://forge.etsi.org/rep/li/trial/-/issues/5When are standards and meeting tags applied?2020-06-15T12:46:56ZcanterburymWhen are standards and meeting tags applied?Once the meeting has concluded? Or when the specifications have actually passed through EditHelp and are available on the portal?Once the meeting has concluded? Or when the specifications have actually passed through EditHelp and are available on the portal?https://forge.etsi.org/rep/li/trial/-/issues/4Can standards tags be applied to commits only for the standard they tag?2020-06-15T12:42:44ZcanterburymCan standards tags be applied to commits only for the standard they tag?Given the current merge process (CRs are all agreed and merged back in to a single meeting branch), is there a sane way to add the standards tags such that they actually label a commit which represents the changes to that standard (as op...Given the current merge process (CRs are all agreed and merged back in to a single meeting branch), is there a sane way to add the standards tags such that they actually label a commit which represents the changes to that standard (as opposed to the output of the meeting)?
The preload script that populated the repo is able to do this because it doesn't use the branching strategy; each new version is a single commit which can then be tagged.https://forge.etsi.org/rep/li/trial/-/issues/3Non-Members can create Issues & submit merges2020-03-03T14:15:57ZashtontNon-Members can create Issues & submit mergesPerhaps a change required to permissions or are we content?
(I am not a member of this project)Perhaps a change required to permissions or are we content?
(I am not a member of this project)https://forge.etsi.org/rep/li/trial/-/issues/2Are nerds smarter than geeks?2020-03-03T14:12:20ZBILCA!429-bilca@users.noreply.forge.etsi.orgAre nerds smarter than geeks?... or the other way around?... or the other way around?https://forge.etsi.org/rep/li/trial/-/issues/1Should we squash commits when merging?2020-03-03T14:13:31ZcanterburymShould we squash commits when merging?