On Fri, 12 Feb 2016 10:07:10 +0100 Patrick Lauer <patr...@gentoo.org> wrote:
> On 02/12/2016 08:48 AM, Michał Górny wrote: > > Dear Ignorant Patrick, > Hello human! Your politeness module seems to have crashed. Please do not expect politeness when you insult someone. > > On Thu, 11 Feb 2016 21:15:34 +0100 > > Patrick Lauer <patr...@gentoo.org> wrote: > > > >> ... or why just changing stuff is not enough: > >> > >> A few days ago I was told that > >> http://euscan.gentooexperimental.org/herds/ was displaying an empty > >> list. Which is annoying because people sometimes want to see what > >> upstream updates are available for their herd. > >> > >> Well, we renamed herd to project. Because reasons. > > No, we didn't. Herd was collection a packages. Project is a collection > > of developers. Project coexisted with herds for a long time. As it was > > explained already in length. Multiple times. > So you just pivoted the organization from A->B to B->A. > > I still don't see the advantage in that. Maybe I should have expressed > my concerns more vocally, but in general I don't have time to worry > about all the little things. You still have trouble understanding who did what. I'm tired of being blamed for something that wasn't my idea. > >> I don't care how it is named, but this change broke euscan in a > >> user-visible way. Now I could just try to rename things there too, but > >> that won't work: > >> > >> euscan uses gentoolkit for parsing metadata.xml and herds.xml > >> (Since herds.xml is basically unmaintained cruft at this point this will > >> break soon anyway ... but ...) > >> Changing gentoolkit to use projects.xml instead of herds.xml won't be a > >> simple migration since the data organization changed. > >> > >> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml] > >> -> email it goes backwards: > >> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml] > >> -> Project name > >> > >> Since this involves XML and python's ElementTree library it's a > >> nontrivial change that also removes a few now useless helpers > >> (_get_herd_email has no reason to be, but we'd need a _get_herd_name > >> helper instead. Err, get_proj ... ah well, whatever name works) > >> > >> And all that just so (1) gentoolkit output works and (2) euscan updates > >> properly. Both of which I don't really care about much, but now that > >> I've invested ~4h into debugging and trying to fix it I'm a tiny bit > >> IRRITATED. > > You are completely incorrect, as you have been told already multiple > > times. People would really appreciate if you spent at least a little > > part of the time you spend complaining, inventing issues and insulting > > others listening to what they're telling you. > > > > So let me repeat, again. euscan works. Want packages from Python > > project? Then select the appropriate maintainer from the 'maintainers' > > section: > So you're saying I have no way to search by herd, err, project now. Yes, you have. You can use project's e-mail address to find the project. And as I proved below, it works. > ... and metadata is now partially broken. Another of your unclear generic statements that mean nothing. > *ahem* This not of good idea sounding. > > > > http://euscan.gentooexperimental.org/maintainers/pyt...@gentoo.org/ > > > > Done. Was it that hard? Now the big surprise: you didn't have to create > > some convoluted logic to get that! You don't need projects.xml to get > > that! Of course, you'd know that if you would listen for a single > > minute instead of throwing insults at others. > If you had actually understood my criticism you would understand why I > might be a tiny bit irritated. > > Some functionality is now actively *gone*, and that's not a feature. Yes, it's gone. However, it's relatively easy to bring it back. All you have to do is enable filtering by type="". Which is definitely simpler than having to process two disjoint data structures, one of them requiring parsing additional XML file. But well, unnecessary complexity was always considered a feature in Gentoo. > >> Please, next time someone has the brilliant idea of changing stuff just > >> to change it (I still don't see a reason why we had to change > >> metadata.xml?), it should be required that support tools are fixed > >> *before* the change, and working versions released. This avoids grumpy > >> people and makes it harder for those that change things to head-in-sand > >> and claim everything works as expected when it obviously doesn't. > > The fact is: things *work as expected*. If you have problem accepting > > reality as it is, then it's your fault, not ours. Herds no longer > > exist. Everything is based on *maintainers* now. Tools are not supposed > > to magically turn project information back into herd-oriented design. > Right, so gentoolkit returning bad info is a good thing. I find that > hard to integrate into my understanding of the world ... Again. > Please don't redefine what 'expected' means to suit your limited > usecases. It just causes friction and unhappy response from people that > now have to spend lots of time figuring out how things diverge from > their 'expected', which usually ends in *facepalm* omg how did that happen. > > Plus the usual sequence of strongly-worded letters to the UN ;) I can't redefine it to suit unlimited usecases. I presume you're capable of doing that. That's good news. I wonder why you haven't used that ability to do something good. > > As I said before, please direct any further complaints directly to > > the Council, and stop insulting the messenger. The Council has banned > > herds explicitly before I even started working on GLEP 67. It was > > the guideline I had to follow. > > > Hey thanks for publically demonstrating your unwillingness to cooperate > with others. That's your opinion. Please do not expect people to be willing and happy to work with toxic personalities like yours. So far you have put a lot of effort on spreading confusion, making noise and doing no good. I'd rather focus on doing something useful. > So now I know that in the future I will > > (1) categorically deny any change requests coming from you and > (2) block/revert any changes that I don't like or understand. > > Nothing personal, just basic sanity. If you want to leave Gentoo, please do that without unnecessary drama. That will reduce the load on ComRel and/or QA resulting from your CoC violations and childish behavior, and reduce the discouragement you're causing to other developers. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpi3JOXMe_fZ.pgp
Description: OpenPGP digital signature
