On Fri, 17 Apr 2020 at 13:21, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > > > On Thu, 16 Apr 2020 at 17:28, clime <clime@xxxxxxxxxxxxxxxxx> wrote: >> >> > > and lines like this: >> > > https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 >> > > are not needed? >> > >> > This is not involved in the computation of the next release value. >> > So, do we use the build history of the package to predict the next release >> > value? Yes. >> > Do we pull this information from the build system? No, >> >> So where do you pull that information from originally? Milky way? >> > > clime, you are being needlessly antagonistic and constantly using words which come across as a personal attack. Do you want answers or do you want a fist-fight? Because the rest of this email which I cropped the previous emails come across like someone who really is looking for a fight to pass the time versus anything else. Ok, I am sorry. And thank you for telling me that. > > If that isn't what you are wanting, then please look at how you are making it so no one wants to work on your idea in the first place. Pointing out holes in differing definitions in a language as inarticulate as English does not tend to make people drop the work they have been doing for months for your idea. > > In the end there is a team of 4+ people who have been working on a different project for a while and came up with a solution to a problem you don't agree with. However they have also been working on this for months by the time you came into this and asking them to change at this point requires more work than a bunch of ill tempered emails pointing out that you both learned English differently. In the end, the problem trying to be solved is a 'business problem' versus an algorithmic problem in that there is no one true answer any more than there is one true editor that can satisfy both vi and emacs people. I don't think it is entirely true that this is only a business decision and there are many true answers here. We have certain setup (dist-git + koji + bodhi in the base) and we want to achieve certain goals (dynamic release and changelog generation, auto-rebuilds on changed dependencies). The proposed solution(s) for it should work and it should be simple to recognize that they work. I think there is always just one simplest solution for a given problem from a conceptual point of view, which is also the best one. The conceptual simplicity is important because it's then easy to make changes in the solution while being sure nothing will break. And it's easy to contribute to something which is easy to understand. > > At this point if you want a different solution, you need to write said solution at least in prototype format and show that it solves the issues better than the one that has been worked on. For dynamic release and changelog problem, it is described here: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/FSVFSQJ5R4WKLH7WIYZQ22CUXAEYZPNK/ Discussion about the mock part of implementation: https://github.com/rpm-software-management/mock/pull/526 The previous two links are about enabling the preprocessing language to allow us generate certain parts of spec file dynamically. The following link describes one possible usage of this mechanism for generating changelog and release dynamically by employing annotated tags: https://hackmd.io/kIje9yXTRdWITwP7cFK2pA Then for auto-rebuilds and mass-rebuilds, I think a different and unrelated solution is needed because the solution shouldn't depend on what macros are used in a spec file. That's because there might always be people who would like to be provided with the auto-rebuilding capability suggested in this thread while keeping their spec file maintenance (to which they are used to and which works for them) unchanged. We could also think about enabling the auto-rebuilding feature globally for all packages in rawhide. I don't think anyone would mind it. This option is not available if the feature depends on using certain macros in your spec file. For these reasons, I think we should come up with a solution that does not depend on what is in spec file. My idea how to do it (which was inspired by Neal's idea about the usage of DistTag) is: - add a new (or maybe reuse existing) field into RPM header, which would contain build_id (a number that increases with each new build of a given package) - take this new field into account in rpm version comparison as the least significant component. Default value for the field is zero, therefore if you don't put anything in, the behavior of version comparison will stay the same as today - display this new field in rpm file name just before arch (e.g. python3-colcon-ros-bundle-0.0.14-1.fc31.1.noarch.rpm) so that it is clear to user why certain package gets updated - update Koji to be able to rebuild a previously submitted srpm again on a certain trigger. With each new rebuild of a package, a new build_id is passed to rpmbuild command which puts it into the resulting rpm(s) header(s). The Koji NVR uniqueness constraint may still apply but only to submitted srpms. Srpms either do not contain the new build_id field or it is always empty/zero as generated by our tooling. Note that it makes sense that srpms are not changed in any way for auto-rebuilds because we want to keep the sources the same to do a rebuild because just a dependency of a package has changed. There isn't a reason for source modification in that case, in my opinion. - update Koji to use an extended handle for its builds, which would contain the build_id number as the last component. E.g. here https://koji.fedoraproject.org/koji/buildinfo?buildID=1495170, the title would be: "Information for build wayvnc-0.1.2-3.fc32.1" and one would use this extended handle in koji commands e.g. like this: koji tag-build f32-infra-candidate wayvnc-0.1.2-3.fc32.1 ... the dot as a separator of release and build_id number is not the best but it's not a problem as long as the suffix is always appended (even .0 if the build-id wasn't specified to rpmbuild during build). - also add the new field to the attributes listing e.g. at https://koji.fedoraproject.org/koji/buildinfo?buildID=1495170 - extend repodata format to contain this new information - adjust rest of the system if needed, e.g. Bodhi to use new build handles but if the handles are sent originally by koji, this might not be even needed) Now, I realize this is a big task and therefore people will be reluctant to do this. But I also think the change is justified by its purpose (to enable auto-rebuilds) and that this is actually needed to move us forward. Right now, it seems to me that we are trying to find workarounds to avoid the work. But do we want workarounds or proper solutions, that's my question. Also, I don't think a workaround, if any, won't be any less work, it will be much more until somebody finally decides to implement the above suggestion because nothing else proved to work. I don't know if I should compare the above suggestions with rpmautospec. I don't know how it would be perceived. I also already did it to some extent in previous emails (and also already in this one a little bit) ... and it probably wasn't perceived very well. If somebody thinks I should do it to move the discussion forward to be able to pick the right solution, I can. Again, sorry for my attitude at times clime > > -- > Stephen J Smoogen. > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
