Quoting Abou Al Montacir (2025-02-01 16:13:44) > > > > On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote: > > Quoting Simon McVittie (2025-02-01 14:21:38) > > > On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > > > > Bug- > > > > Upstream: > > > > https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 > > > > > > I believe the intended DEP-3 syntax for this is: > > > > > > Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 > > > > > > so using that instead of Bug-Upstream might help? > > > > > > My understanding is that the Bug-<vendor> convention is intended > > > for other downstreams, which might be Debian, a Debian derivative like > > > Ubuntu, or sometimes an unrelated downstream like Fedora that has provided > > > useful/relevant information in their record of the equivalent bug. > > > > Agreed that *ideally* an URI for the forwarded bug is provided. But does > > the omission *invalidate* the data points of "yes, it has been forwarded > > somewhere not mentioned, and has also been forwarded to some downstream > > confusingly labelled "Upstream"? > With regards to other possible values (No, NotNeeded), I find it a bit hacky > to > use this field to provide an upstream bug URL. > I would completely remove this practice and keep this field human readable and > understandable to be a simple tri-state field (Yes, No, Not-Needed).
If you are proposing a change to the definition of DEP-3, then do you really think that the benefit of such change outweight the burden of updating current machinery and declarations? Because I fail to see it. If not a proposal for change, then what is your point of mentioning it? > > I suggest to go ahead and file a bug against the service, suggesting to > > Sure I'll do that. > > clarify (e.g. using a hover string) what causes an invalidation, and > > also to choose a different keyword (e.g. "ambiguous" or "weak") when > > strictly speaking it is not invalid per the spec but just somehow not > > ideal. > > * Bug-<Vendor> or Bug (optional)It contains one URL pointing to the related > > bug > > (possibly fixed by the patch). The Bug field is reserved for the bug URL in > > the upstream bug tracker. Those fields can be used multiple times if several > > bugs are concerned.The vendor name is explicitely encoded in the field name > > so that vendors can share patches among them without having to update the > > meta-information in most cases. The upstream bug URL is special cased > > because > > it's the central point of cooperation and it must be easily distinguishable > > among all the bug URLs. > My understanding is that this applies to two kind of bug trackers: > 1. Upstream using Bug > 2. Downstream using Bug-<vendor> > > In my case I used Bug-Upstream because I found it on an other patch, but this > point is not very clear in the spec and I would suggest we rewrite it to make > is > more explicit. I agree that it might make sense to refine the non-formal parts of DEP-3 to avoid misunderstanding. I made same mistake when I began using DEP-3. :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
