On Tue, May 21, 2024 at 9:01 AM Chet Ramey <chet.ra...@case.edu> wrote: > > On 5/21/24 6:17 AM, Zachary Santer wrote: > > > I was wondering what the relationship between the devel and master > > branches was. > > No mystery: the devel branch captures ongoing development, gets the latest > bug fixes, and is where new features appear. The master branch is for > stable releases.
But the devel branch won't get changes for bash versions beyond what's in alpha right now? Do you create patches from devel and apply them to master? I guess, to be more clear, master is in the history of bash-5.3-alpha, so I assume master will just fast-forward to that point when you're happy with bash-5.3. Meanwhile, devel is completely off doing its own thing, in terms of the git commit history, Kind of have a hard time wrapping my mind around that. > > I saw that you turned MULTIPLE_COPROCS=1 on by default > > under devel, but haven't touched the somewhat more substantial changes > > that sounded forthcoming, from that whole conversation. > > Which one is that? So this email[1] was just about the config-top.h change, I guess, but in the prior one from you quoted there[2], you seemed to be referencing only removing the coproc once both file descriptors pointing to it have been closed by the user. Additionally, I was hoping the discussion of having a way to make fds not CLOEXEC without a loadable builtin[3][4] would get some more attention. I want to say I tried to do 'tee /dev/fd/A /dev/fd/B' at some point and didn't have the background knowledge to understand why it wouldn't work. > > So I take it > > MULTIPLE_COPROCS=1 will be enabled in bash-5.3 but other potential > > changes would come later? > > Probably, yes. > > > Do you keep a list of TODOs and things under consideration somewhere? > > I do, it's more of the `folder of ideas' style. Did nosub[5] get in there? Just generalize how coproc fds get handled into something that can be turned on or off for any fd. [1] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00149.html [2] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00105.html [3] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00085.html [4] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00100.html [5] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00087.html
