On Sat, 22 Jun 2019 10:46:17 +0200, Simon Lees wrote:
On 22/06/2019 13:05, Andrei Borzenkov wrote:
21.06.2019 23:08, Michal Kubecek пишет:
On Fri, Jun 21, 2019 at 08:36:28PM +0200, Luca Beltrame wrote:
Il giorno Fri, 21 Jun 2019 20:29:21 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:
I mentioned that I removed the patches 01-42. The script does not understand it.
Seriously, is it this hard to list all the patch files in the changes? A simple "Dropped patches: <list of all patch files>" would have been sufficient *and* it would have taken you *less* than starting this thread.
And this is exactly what is wrong - and has been wrong for few years - with request handling in both openSUSE and SLE. For anyone except the bot, the entry saying "drop all patches" is way more useful
"All" depends on context which is not known at the time someone actually reads changelog. It is pretty easy to grep changelog for patch name to see when it has been added and removed. It requires careful reading to understand whether specific patch added years ago is covered by "all" in this case. Because there may be many "all" in different points of time.
Yeah if I need to go back in 3 years and work out the lifespan of a patch, its far easier to just search the changelog for all instances of the patch, Its something I have to do on occasion with packages i'm not necessarily the maintainer of and rules like this make it much easier.
Although seife wanted to stop discussion, I'd still like to add one point: I'd love to have a better alternative for tracking the code in rpm sources. The main problem is that we're (ab)using rpm changelog for several different purposes. That is, we mess up the rpm changelog contents with both the feature change / bug fix descriptions and the patch change tracking, a la manual VCS. The former is essential, while the latter is useless for non-developers. As many people already suggested, admittedly, this policy itself is useful and helps for development. Sometimes indicating the added patches helps, indeed. However, overall, relying only on this is definitely no best option: why can't I check the patch changes more simply like "git log some.patch"? And, why do I have to write and edit manually all patch changes in *.changes, which is very error-prone? All these pains show the lack of a proper VCS in the process. The bot, which initiated the discussion, merely surfaces such problems due to this policy enforcement. So, I hope that the discussion won't end up with "policy is policy" or "bot actually helps" type of arguments. Neither stopping bot nor stopping policy enforcement would make things better, because then we'll lose either the correctness or the trackability. OTOH, we shouldn't turn our eyes away from the unsatisfying situation, too. This might be a good opportunity to reconsider what's missing. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org