On Sunday, 17 November 2024 22:17:08 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2024-11-17T20:35:34+0000, Deri wrote: > > On Sunday, 17 November 2024 04:42:47 GMT G. Branden Robinson wrote: > > > I have added 3 tickets to the release goals. > > > > > > https://savannah.gnu.org/bugs/?64484 > > > https://savannah.gnu.org/bugs/?66452 > > > https://savannah.gnu.org/bugs/?66453 > > > > > > I withdraw my plans to make a groff 1.24.0 release candidate until > > > your expectations of our PDF support are met, and I ask you to name > > > people from the groff development team that you regard as competent > > > to address these issues. > > > > I have dealt with this elsewhere, > > You have not. Your recapitulation of comment #31 to bug #64484 implies > no answer to either question implied above. > > 1. What are your acceptance criteria for a 1.24.0 release candidate? > 2. Who do you trust besides yourself to address any of the 3 bugs > listed above? > > How do you answer these?
Hi Branden, It looks like comprehension may be an issue here. I understood you were asking who I trusted to make a good job of documenting the information contained in pdfmark.pdf as it pertained to creating pdfs with groff, as I had already answered that as PART of my response elsewhere, I copied just the relevent portion, which included:- > I have no doubt you would make a great job replacing pdfmark.ms, combining stuff from gropdf.1 and comments in pdf.tmac. In fact I know you are so thorough it is likely you are likely to find plenty of bugs around the seldom used edges of pdf.tmac. Which to my mind is an effusive endorsement of your ability, and a clear answer to the question of who do I trust to do a good job. If you are unable to do the job an alternative expedient would be be to reinstate just pdfmark.ms with a big red notice at the top explaining that its retention is an interim measure until something more permanent can be produced. > > so I will just copy it here to save my typing. > > Since copy and pasting a URL would have been even more labor-saving, I > infer an additional goal: to air to a broader audience your low > assessment of my ability and/or my judgment. I'm afraid here my comprehension is struggling. It is not clear to me how cut and pasting a URL involves less labour than cut and pasting an adjacent block of text, which has the added advantage of being a specific answer to the question of who I trusted to do the documentation, and an answer to your assertion that I consider you of low intellect, merely pasting a URL would have required reading the entire post to find the relevent answers. I do note that you have opened more bugs on this issue, was this to reduce the visibility of our discussion? (I don't believe that but you did try and put a particular slant on my decision to include the relevent part of a bug entry to answer a question you posed here). > My response can be found at > <https://savannah.gnu.org/bugs/?64484#comment32>. > > It seems we are at an impasse. I ask other contributors to help us cut > the knot. Perhaps it would help to have the knots defined. 1) Should the release happen with a chunk of documentation on how to produce pdfs with groff missing? Sub-divided into:- A) Reinstate a version of pdfmark.pdf, or B) A new document. My preference is (A) since, as a minimum, we are back where we were before Keith's contributions were removed, at least in documenting groff's ability to produce pdfs. (B) could be a target for a later release. 2) How should "\0" be treated by \X and .device? A) Treat the same as "\ " and "\~" i.e. replace with a text space. B) Keep as current code, removal and issue a warning (for \X) or no warning and replace with "0" (for .device). My preference again is (A), but Branden is against this solution. I think these are the only things holding up Branden's RC release, (pretty simple decisions, not Gordian at all). Cheers Deri > Regards, > Branden
