> > 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? > we push this information > from the build system into dist-git Yes, after you pull it from build system. > giving dist-git enough information to be > self-sufficient. It's not self-sufficient because it will need new and new info from new and new builds and only build system can provide that info in your approach. You are using words like "self-sufficient", "locally-reproducible", "predictable" in such contexts that they completely lose meaning. > Could the build system not push that information? Yes, we're currently flagging > commits in dist-git upon successful build. We could use another tool to add the > tags then instead of doing it from koji but it would introduce more delays. > But could we not use the build history of the package? Not with the approach we > chose. Which is not the approach that formed the "consensus" you mentioned (according to my understanding of what the "consensus" was). > > Now, using the number of commit made since the last version bump would be one > way to generate the release value which would be entirely contained within > dist-git, but it isn't without drawbacks (the upgrade path can very easily be > broken with this approach, it also does not allow to rebuild a package without > doing a new commit to its git repo). We have considered those and chose not to > pursue that idea. Yes, because that idea is not finished. You should have arrived to annotated tags created by users. > Adding a build number in the release field, would require even more involvement > of the build system than our approach and would break the "contained within > dist-git" idea. You are adding build number to release field through insane machinery. It's, by the way, not what I was suggesting. Not sure if you read what I was saying. I was saying a new field should be allocated for that and that it should be applied to rpm builds only (not srpm ones). "contained within dist-git" is not something that can be associated with your solution because you heavily employ koji/build-system. > There are really multiple ways to solve these questions, we looked at a number > of them including yours I don't think you looked very well. In fact, what I saw was mainly: "Ye, we will let you speak but, in the end, we are the bosses here and we know what to do." You are employing the same approach I have seen here before e.g. from modularity guys and guess what...that approach does not work (I really wanted to say something else than "does not work"). It's an approach of arrogance and ignorance and it leads to bad results because people are just afraid to say: "Hey, you have a point, here." or "Right, I haven't thought of that". So then people keep pushing their massive trains with lots of passengers and they are all sweaty and tired but what they do not know is that 10 meters ahead the railway ends. Still, it will take a long time to arrive at that conclusion. If you enjoy this, ok. > and made a choice that does not align with your idea, I don't think you considered my idea seriously. I haven't seen enough argumentation or enough explanation. In fact, I gave you plenty of reasons not to do what you wanted to do and feedback was zero. > but the approach and POC we're proposing does fit the set of requirements, the > UX we wanted to have and is working. Ok, but I wonder whether your requirements were very well defined then. They should have included "local-reproducibility" and "predictability". These are not satisfied. You wanted to "help with mass rebuilds". Well, what you did will work only for packages that use your black-magic macros which look like rpm macros but they have completely different behavior. E.g. that they will cause insertion of a code snippet into the spec file... Imagine you have a programming language where if you name a variable with a certain name, then it will make some text transformation on the rest of your code. Such language would be immediately considered esoteric. And that's what you have now, magical, esoteric, hardly predictable solution that requires people to know tons of intricacies of how it works. That's really not great for new-comers. And it is also not good for production use because when you start to depend on too many "sources of truth", ongoing processes (running builds), and black-magic, it just immediately starts to break down. > I am not saying your approach could not work either. We just picked two > different approaches, both of which are potentially valid. I don't think you really hear what I am saying. I am saying that your solution has lots of fundamental problems and it will not address the needs of users sufficiently well (e.g. the need for auto-rebuilds). Also that these problems are not fixable unless you change the whole design. You are responding with some generic "sweetening" phrases that do not really have much content in terms of explaining why your solution is actually the right way. I don't see any rationality and any reasonable technical argumentation from your side, which is quite sad. You seem to have some view and you are just blindly sticking to it. Okay. I will, meanwhile, try to actually bring to the Fedora the solutions that it really deserves and that will actually work reasonably well (it's a pity that I have another employment so I don't have that much time as I wish to have). clime > > > Pierre > _______________________________________________ > 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
