Summary: | Unreviewed commits with no explicit specification to gentoo:metadata/repoman | ||
---|---|---|---|
Product: | Community Relations | Reporter: | Michał Górny <mgorny> |
Component: | Developer Relations | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | comrel, dev-portage, dolsen, drobbins, radhermit |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Michał Górny
2017-07-21 21:47:37 UTC
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. |