Hi Jonas, On Sat, 2025-02-01 at 17:05 +0100, Jonas Smedegaard wrote: > 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. I would love to, but as Jeremy spotted out, I'm minority (600 vs 4000) so no. > > If not a proposal for change, then what is your point of mentioning it? That tools do not enforce practice by stating that other practices are errors (which may explain the above mentioned majority)
Tools are here to enforce rules, not to enforce a particular way to comply to them. I hope this is clear enough. > > > > 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. :-) If you made a mistake, and I made it, and many made the same, then the spec is not clear enough. But also, in this particular case, it's not the issue of the spec but of a particular tool trying to enforce the rule. I'll file a bug to fix it. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
