Transferability record: first-contact translation on non-burned estates vs the 6 burned (2026-10-22 peek, honest gaps)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 1-2 天
- 新手友好度
- 35/100
- Issue 类型
- 文档
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
调研方向
Read the issue’s recorded survey and evidence for the 2026-10-22 baseline, including the referenced #6064, #6065, and #6066. The issue reports a measurement and assessment; no files or tests are named. Done means documenting the real first-contact scan results for dsf and zopeneditor-sample, with the noted prior-peek caveat.
由索引模型根据 Issue 内容生成。
描述
What this is
An honest record of how far the translator built on the 6 burned estates carries over to code it was not built on. It records one unplanned look at non-burned code on 2026-10-22 and what it showed, so the next first-contact scan has a baseline and nobody mistakes burned-estate numbers for general capability.
Framing (owner, 2026-10-22): the first 6 estates we prepared for did not fully transfer to a 7th. That is expected and fair to say: we have depth on 6 estates and not yet the breadth. This record exists so the claim stays honest.
The peek, stated plainly
On 2026-10-22, while trying to estimate non-burned translation rates, the orchestrator:
- Ran
det_survey.py --no-compile(translation only, counts only) over the 9 census repos plus the two pinned non-burned corporadsfandzopeneditor-sample. - Grepped
dsf's PL/I files for the era tells ofera_tags.py(counts only). - Wrote two issues from what it saw: #6065 (batch file I/O + WRITE ADVANCING) and #6066 (PL/I CICS).
No cases were built and no code was changed. A decision to burn dsf was made and reversed the same evening: dsf and zopeneditor-sample stay non-burned. #6065 is parked in churn (needs owner) and #6066 stays frontier. No fixes derived from these corpora land before their real first-contact scan. We have seen their hole reasons, so that scan isn't fully blind; report it with that caveat.
Numbers (main 082aba881, 2026-10-22)
| set | programs | translated whole | statements translated |
|---|---|---|---|
| Burned, 6 estates (evidence report) | 129 | 123 (95%) | — |
| Burned, CICS programs (census baseline) | 106 | 103 (97%) | — |
| Non-burned, 9 census repos | 40 | 8 (20%) | 568 / 647 (87.8%) |
| census, translatable as supplied* | 19 | 8 (42%) | — |
zopeneditor-sample (batch COBOL) |
5 | 2 | 595 / 632 (94.1%) |
dsf COBOL (batch) |
7 | 0 | 231 / 318 (72.6%) |
dsf PL/I (1,473 files, 575 EXEC CICS) |
1,473 | 0 (COBOL-only translator) | 0 |
* Excludes 3 non-programs (ISPF screen captures, a copy member), 9 source defects (text past column 72) and 9 missing inputs (an absent user copybook; IBM's z/OS Connect BAQRINFO, never shipped).
Over time: non-burned whole-rate was 24% on 2026-10-07 (5 / 21, CICS programs only) and 20% today (8 / 40, all COBOL). In the same two weeks burned CICS went from 70% to 97%. Different denominators, but there's no sign that the burned-estate gains carried over.
Honest assessment of the gaps
- Language breadth is the biggest gap. A real production estate (NAV's DSF, 1967–2018) is ~99% PL/I. Our CICS capability today is COBOL CICS; on that estate the translator covers ~0.5% of programs. (#6066)
- Batch outside the JCL-driven shape. The generator emits the batch runtime only when an estate holds an application JCL job, so batch programs in an estate without JCL lose all file I/O. Our burned estates all ship JCL, so they never showed this. (#6065)
- Statement families the 6 estates never used:
WRITE … ADVANCING(0 burned files), JSON GENERATE/PARSE,WEB WRITE HTTPHEADER SESSTOKEN, SQL ROLLBACK inside CICS, variable-length records without RECORD VARYING. - Input completeness: about half of census refusals are missing copybooks or source defects, not the translator. Real estates arrive incomplete; we refuse correctly, but the first-contact rate pays for it.
- Era profile. The burned estates lean era 2–4 (RESP, SQL, channels, async). DSF's PL/I CICS is solidly era 1 (
HANDLE CONDITIONin 254 files, DL/I in 111,HANDLE AIDin 67,RESPin 1). Era-1 COBOL work (#5856-class) exists, but era 1 in PL/I is untouched. - What does transfer: the statement core. Where a program translates at all, 82–94% of statements come through; 8 of 19 translatable census programs translate whole on first contact, and the holes are named, not guessed.
Going forward
- #6064 makes the non-burned rate a scheduled, published number, so transfer is measured continuously, not by accident.
dsf/zopeneditor-sample: the next scan is the real first contact. Record it here, then decide on #6065/#6066.- Breadth is the fix for transfer: more estates scanned first-contact (the blind 4th-estate draw, #5865 missing systems), not more depth on the six.
- 主要语言
- Python
- 星标
- 57
- 派生
- 11
- 平均合并
- 1 小时 46 分钟
- 30 天内合并 PR
- 972
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
squid-protocol/gitgalaxy 的其他 Issue
-
documentation
难度 2/5 1-3 小时 新手友好度 68/100
squid-protocol/gitgalaxy#8002 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 78/100
squid-protocol/gitgalaxy#8000 ·
维护者通常 1 天内回复
-
documentation
难度 1/5 1 小时以内 新手友好度 82/100
squid-protocol/gitgalaxy#8001 ·
维护者通常 1 天内回复
-
documentation
难度 1/5 1-3 小时 新手友好度 84/100
squid-protocol/gitgalaxy#7998 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 78/100
squid-protocol/gitgalaxy#7999 ·
维护者通常 1 天内回复
查看 squid-protocol/gitgalaxy 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 83/100
-
难度 2/5 1-3 小时 新手友好度 87/100
维护者通常 7 天内回复
-
good first issue
难度 2/5 1-3 小时 新手友好度 78/100
MTSWebServices/RecTools#330 ·
-
area: web priority: P1 story
难度 2/5 1-3 小时 新手友好度 76/100
nfiasco/Quant-Time-Machine#151 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
autowarefoundation/autoware_carla_scenario#2019 ·
维护者通常 1 天内回复