Re: [gentoo-dev] Uncoordinated changes
On Fri, 12 Feb 2016 10:07:10 +0100 Patrick Lauer 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 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 'expect
Re: [gentoo-dev] Uncoordinated changes
On 02/11/2016 07:34 PM, Rich Freeman wrote: > Ultimately, the only way anybody can be assured that their favorite > Gentoo tool will work in a year is if they're maintaining it. It > sounds like nobody was really paying attention to it, which is why > nobody noticed that it was going to break. Not completely true in this case. Gentoolkit is maintained, just slowly due to lack of time. For this migration, there is a bug for it (Bug 573030) that was filed by me before the migration was complete. The problem here is that there are two devs that primarily work on the package and both of us currently are busy with other things in our work/life balance. With that said, Patrick has attached a patch to the bug and I will take a look at it and if it works, put it in and generate a release. As a side note, any Gentoo developer is authorized to work on Gentoolkit, the restrictions are don't make a new release without asking, and fix any accidental breakage. With regards to releases, it is fine to release a rev-bumped ebuild with patches as long as the patch is in the git repository and you follow the second rule of fixing accidental breakage. Regards, Paul
Re: [gentoo-dev] Re: "Lazy" use flags?
On Fri, Feb 12, 2016 at 5:26 AM, Rich Freeman wrote: > On Fri, Feb 12, 2016 at 1:36 AM, Kent Fredric > wrote: > > On 12 February 2016 at 18:56, Duncan <1i5t5.dun...@cox.net> wrote: > >> So my USE="-* ..." (without letting portage do autounmasking) would > >> continue to work just like it does now, correct? > > > > I would hope so. > > That would be my proposal. > > I think it would make more sense in general for this to be the default > and to have a flag to disable it, in part for this reason. It > wouldn't affect people running -* and such anyway, so this is targeted > mostly at users who don't care a great deal about micromanaging their > USE flags. > I use -* exactly because I /don't/ want to micromanage, and there are far too many packages whose maintainers have decided to stick + in IUSE for random crap. To wishlist a different feature, it'd be nice to have a profile or something that made portage ignore IUSE="+maintainers-favorite-flag" so we wouldn't have to use -*... I'll happily let portage semi-manage USE for me by auto-enabling USE in dependencies if I can set the base USE in the first place without having to start off with global negation.
Re: [gentoo-dev] Re: "Lazy" use flags?
On Fri, Feb 12, 2016 at 1:36 AM, Kent Fredric wrote: > On 12 February 2016 at 18:56, Duncan <1i5t5.dun...@cox.net> wrote: >> So my USE="-* ..." (without letting portage do autounmasking) would >> continue to work just like it does now, correct? > > I would hope so. That would be my proposal. > And obviously, this feature would be potentially > tenous, and might be wise to only > activate its mechanics with a parameter to emerge. >,,, > That way, people who do want the new behaviour can stick it in the > default emerge options and \o/ Whether you call it a FEATURE or an option it would almost certainly have to be defaulted. If you run with that option for six months and then run emerge without that option while using something like --newuse, it will immediately detect a bazillion dependency conflicts and if using autounmask it will want to add 1000 lines to your package.use - which would be the same 1000 lines that many are running with today. I think it would make more sense in general for this to be the default and to have a flag to disable it, in part for this reason. It wouldn't affect people running -* and such anyway, so this is targeted mostly at users who don't care a great deal about micromanaging their USE flags. -- Rich
Re: [gentoo-dev] Uncoordinated changes
On Fri, Feb 12, 2016 at 4:07 AM, Patrick Lauer wrote: > > 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. > https://wiki.gentoo.org/wiki/GLEP:67#Issues_with_the_current_system It is OK to disagree with the decision, but having gone through the GLEP process this is about as deliberative and formal as it gets around here. It is pretty rare for the council to be asked to approve a change that isn't controversial. For the most part devs are fairly free to just implement non-controversial changes by announcing them on -dev and proceeding if there seems to be consensus. We're a community-based distro. We're all here because we care a lot - not for the paycheck. I think feeling passionate about changes/issues/etc is pretty normal. -- Rich
Re: [gentoo-dev] Uncoordinated changes
On 02/12/2016 08:48 AM, Michał Górny wrote: > Dear Ignorant Patrick, Hello human! Your politeness module seems to have crashed. And thanks for making me do a quintuple facepalm with backflip. I think that's a new record. So anyway ... > On Thu, 11 Feb 2016 21:15:34 +0100 > Patrick Lauer 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. > >> 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. And I can't even find projects in the soup of maintainers. ... and metadata is now partially broken. *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. > >> 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 ... 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 ;) > > 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. So now I know that in the future I will (1) categorically deny any change requests coming from you and
