Talking about this specific commits: commit e4e2c635cd6d2cf117385673c03e5fd41d0f1209 Author: Brian Dolbec <dolsen@gentoo.org> AuthorDate: Tue Jul 11 04:46:02 2017 Commit: Brian Dolbec <dolsen@gentoo.org> CommitDate: Sat Jul 15 04:20:06 2017 metadata/repoman: Add new linechecks.yaml file commit bd13d0b9f8f09adf099e714bf100736f28784bc2 Author: Brian Dolbec <dolsen@gentoo.org> AuthorDate: Mon Jul 10 19:54:42 2017 Commit: Brian Dolbec <dolsen@gentoo.org> CommitDate: Sat Jul 15 04:20:06 2017 metadata/repoman: Add new repository.yaml cofiguration file This file is used to enable/disable scan_modules and linechecks modules. commit dc02968f5d8fd53089cbab583f9b2eed7b895261 Author: Brian Dolbec <dolsen@gentoo.org> AuthorDate: Tue Jun 27 19:19:43 2017 Commit: Brian Dolbec <dolsen@gentoo.org> CommitDate: Sat Jul 15 04:20:06 2017 metadata/repoman: Add new qa_data.yaml file This file holds the main qa_data, defining the scope and help text of the variuos errors and warnings. This is the initial port of the data from qa_data.py. They were added to the metadata directory for the Gentoo repository with no prior announcement or review. They are specific to a development Portage branch. They are not only of no value to other package managers (partially due to lack of proper specification) but they are also closely bound to Portage/repoman design internals. I'm not saying I do mind those extra files that much, or that Portage team again unilaterally invents their own standards and requires other package managers to figure out how to reuse them. I can even live with the fact that *yet another* data format has been just added to the repository like having 5 or 6 different formats is not enough already. Even though it's been said more than once that we want to avoid adding more formats, and to specifically using YAML because it requires extremely complex parser. What I really *do* mind is that this change was done without any prior discussion on the mailing lists and with no prior review from anyone but (possibly) a small circle of Portage developers who actually worked on this. This is not how we add files with repository-wide meaning. In fact, I don't think we really want to add any new files without specifying them in the PMS or at least a GLEP. The repository metadata is not a place for stuff that has been designed on a knee, and that has no guarantees of being even remotely stable.
First let me dispel several untruths mgorny has claimed... quote: They were added to the metadata directory for the Gentoo repository with no prior announcement or review. Answer: I did start an email thread in the gentoo-dev email list [1] Where I announced my intentions and direction I wanted to take the repoman rewrite into. There were NO objections. I have even had discussions with former and current council members about it (out of list, mostly on irc). I have not had any objections raised to my plans. In that email it was announced that the in tree metadata needed to precede the code being released. While it has not been formally reviewed yet. It is in a state to get more testing, final development feedback and changes. While it is not absolutely essential that these files be in the tree for final development it is prudent for broader developer testing. It would make it much more difficult to get developers to test it since this new repoman code uses repoistory driven configuration. That means that other downstream derivitive distros and users can customize what checks are performed and add custom modules/checks to suit their needs. I have full intentions of submitting the final form of these files for review before the form is locked in with repoman releases relying on them. I also have been chatting with several current council members about my recent changes and progress. They expressed no concerns to me about the direction I was taking. While they might not have known the full extent of my changes. I was not hiding anything. I was in fact asking for some testing from a select few, including at least one current council menber. It is for that reason, that I pushed these files to the main tree. quote: They are specific to a development Portage branch. They are not only of no value to other package managers (partially due to lack of proper specification) but they are also closely bound to Portage/repoman design internals. Answer: Yes it is specific to repoman. It is my repoman rewrite driving this effort. While mgorny has been on the portage team until his opening of the bug. He did not participate in any of the rewrite discussions or coding. He should also have known very well what was planned and being worked on as part of that team. As for involving other package managers. I have had several discussions with Tim Harder [2] ([2] is one such discussion) about coming up with a common set of files that can be used. But the data being used by repoman was vastly different from what the pkgchecks code used. It should be noted that mgorny also works on pkgchecks. But he has made no effort to discuss any possible common system that can be used by both repoman and pkgchecks. But I remain still hopeful that something can be done to produce a common system that can be used. Although I am doubtful he will be participating in that as past and present experience has shown. quote: I'm not saying I do mind those extra files that much, or that Portage team again unilaterally invents their own standards and requires other package managers to figure out how to reuse them. I can even live with the fact that *yet another* data format has been just added to the repository like having 5 or 6 different formats is not enough already. Even though it's been said more than once that we want to avoid adding more formats, and to specifically using YAML because it requires extremely complex parser. Answer: In that email thread you will see that I did not come up with yaml as the format to use for these files. I asked for possible formats to use in these files [1]. And even Tim Harder (the pkgcore lead) suggested yaml as the form to use [2] in our discussion. As to using another format, you do not mention alternatives. All you are doing in fact is bitching about it... If the council or QA want them removed, then so be it. I will take my work elsewhere where it is desired. It is in fact my paid employment that has been waiting for these changes for quite some time. cc'ing coucil, comrel, portage team, drobbins [1] https://archives.gentoo.org/gentoo-dev/message/9c71cb0ecb71bc8499d3ac5b0bca959f [2] http://dev.gentoo.org/~dolsen/mgorny.evidence
Why this bug is restricted to view to others? It sounds like a bug about lack of explicit policy around metadata/.
oh, forgot to cc Tim
Based on the evidence presented above, discussion did happen with the appropriate people. As a council member, I do not support removing these files. As Brian stated above, they need to be there for testing and he is planning on updating -dev when it goes final. That's good enough for me.
If there is going to be a real RFC with *formal specification*, then I'm fine with keeping them. As long as the RFC isn't going to be 'but it's like this for 3 months already, so we will not change anything'. While specifying it, please remember to cover a few essential compatibility points, that is: 1. What will happen when you run a newer repoman with an older repository state (no files, older files)? 2. What will happen when you run an older repoman with a newer repository state (newer data files)? 3. Will stand-alone repositories have to copy all the data from Gentoo? Will repoman be even remotely usable without the data files?
(In reply to Brian Dolbec from comment #1) > As for involving other package managers. I have had several discussions > with Tim Harder [2] ([2] is one such discussion) about coming up with a > common set of files that can be used. But the data being used by repoman > was vastly different from what the pkgchecks code used. It should be noted > that mgorny also works on pkgchecks. But he has made no effort to discuss > any possible common system that can be used by both repoman and pkgchecks. > But I remain still hopeful that something can be done to produce a common > system that can be used. Although I am doubtful he will be participating in > that as past and present experience has shown. > > In that email thread you will see that I did not come up with yaml as the > format to use for these files. I asked for possible formats to use in these > files [1]. And even Tim Harder (the pkgcore lead) suggested yaml as the > form to use [2] in our discussion. For some of the data currently in those files that's relevant to pkgcheck, e.g. eclasses exporting functions, I'd rather have a specified way to pull that from the repo itself at runtime and/or generated via metadata updates otherwise it seems the data could get outdated quickly. Honestly, if it was me I would have probably tossed these files in a fork or different repo/overlay entirely to test the concept and get more exposure and comments before putting them in the tree since devs testing should be familiar enough with git to handle branches or with gentoo to use other repos. That said, I don't really have much of a place in this argument other than to note that the current data isn't really useful for other tools which doesn't appear to be the point atm.
Has absolutely nothing to do with the council.
