Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify testing and configuration setup #9

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
7 participants
@haarg
Copy link

commented Apr 1, 2015

Rather than generating test files at configure time and packaging a ton of unneeded code in inc/, just have the tests hard coded and pick which to run based on if XS is being used.

haarg added some commits Apr 1, 2015

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 2, 2015

Hi Graham,

how do say politely "This was exactly not the way I decided to go when designing configuration & test phase". I appreciate your patch but for the moment I'd like to let it aside until a common understanding of the motivation of the original setup has been reached.

This is not a reject of the contribution - if you're interested to improve at this point - what would help more is someone who helps discussion open issues I try to satisfy with my approach.

@haarg

This comment has been minimized.

Copy link
Author

commented Apr 2, 2015

Can you explain why you prefer your approach?

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 2, 2015

Yes, I can.

Because of the size - it'll be a longer answer.

First - see the RT's #75672, #93207 and alike. Those are symptom's I try to fix.

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

Also - like at the RT #102885 issue I experimented with checks guessing the supported sv_setsv* opportunitities before finding a suitable solution without configure time checks.

While I know the C::AC part is slightly overengineered - it starts where the proposed can_xs() ends. It allowes add more checks - eg. one for determining UV_MAX, IV_MIN and IV_MAX on testers machine and allow a rewrite of the test in https://github.com/perl5-utils/List-MoreUtils/blob/master/t/lib/LMU/Test/Functions.pm#L1312 using precomputed and surely being integer numbers. I didn't go this approach because I'm fighting with myself to create a Machine::Integer::Constants instead and recommenting that for the test (sounding board needed!).

The same arguments as for the check are for the tests. I want the tests fail when a condition in configure is detected - and not skip. The reason is (an admitted unreflected because of just a wand to discuss it with) eg. RT #85257. The idea is born from experience in dbi area (dbi, DBD::DBM, DBD::File, SQL::Statement, DBD::CSV, DBD::sys ...).

It needs the same reflection the configure stage might need - but with an open mind for the maintainer requirements who has background in deep low level code (see https://github.com/rehsack/meta-jens/blob/master/conf/machine/curie.conf or https://github.com/rehsack/meta-jens/tree/master/classes) and high level hit's him occasionally, not regulary ;)

Similar as kentl argues for Gentoo packaging - my experiences at pkgsrc packaging (which runs for 16+ platforms) is a strong lack in toolchain supporting clear customizable results. C::AC fills that gap with the same way of control to packagers as autotools do for Shell (ac_cv_* environment variables) and more in that direction. Packaging bitbake recipes for Yocto and problems with Params::Validate and Socket6 encourage me that the idea behind the approach is sane (even if the implementation is ... unreflected).

@ghost

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

Jens, in this particular case, though, it looks like Config::AutoConf::LMU and the Tumble are only generating XS/pure-perl variants. Is that correct?

Is the "design difference" that you're using the C::AC/Tumble approach because you expect more variations in the future and you want the infrastructure in place now for those future variations?

If so, then the debates about the approach should center on the cost/benefit of having it now versus the cost/benefit of holding off until it's actually needed (and the likelihood of needing such variants in the future).

Because otherwise, the generated test approach seems like complete overkill for the actual files generated currently.

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 2, 2015

@dagolden - No, it's not correct - that is what remained in public after I cleaned up. But misbehavior of EU::MM makes me torn to add some extra's soon (bikeshedding and sounding boards needed).

There is one check done in check_produce_loadable_xs_build (or better: place-holded) which is intended to be filled as soon as the technology is safely available - the one preventing tickets as #75672 (load errors). There's a little more with type definitions - but as said, I'm unsure and to many tuits.

Regarding the tests - at the very moment I agree that it's overengineered but reduce them to a static set with one check at config is "underengineered" - I wanted at Berlin discuss the ExtUtils::MakeMaker::Extensions approach or learn more about Module::Install or whatever to have a balance between dynamically add variants but ship them pregenerated.

The hint @haarg gave with dynamically fill tests list is valid and should be discussed whether there're likely (not possible) dynamic tests (RT#93207) we cannot pregenerate or not.

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 7, 2015

I added some explaning doc with dcc1a93 - I hope with the explanation above and the doc most questions are answered. If not - don't hesitate to ask or tell me what's missing or unclear.

@Leont

This comment has been minimized.

Copy link

commented Apr 8, 2015

Let me try to translate this.

I think @rehsack's point boils down to "I want this to be as close as possible to what I consider correct, at any costs", and that @haarg's and @dagolden's point is "this cost is not reasonable, isn't there a cheaper way to achieve this, and if not should we do this at all".

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 8, 2015

This to decide is to early in the distribution evolving process.

@Leont

This comment has been minimized.

Copy link

commented Apr 23, 2015

This to decide is to early in the distribution evolving process.

Can you please clarify what you mean with that? In particular, what are you referring to with "This"

@rehsack

This comment has been minimized.

Copy link
Member

commented Apr 24, 2015

It's the same this you refer to. I explained the details above - is there something particular what in unclear?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 4, 2015

When everything is said and no open questions need further discussion, I'd like to close this PR.

@Leont

This comment has been minimized.

Copy link

commented May 4, 2015

Did you mean "the test generation process is too young for such cost/benefit question"?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 4, 2015

Am 04.05.2015 um 18:02 schrieb Leon Timmermans notifications@github.com:

Did you mean "the test generation process is too young for such cost/benefit question"?

I mean, the test generation, the configure stage, the complete process.

No one invested time reflecting details in that process - I described what causes myself deciding for both solutions I currently use and where I think it's over-engineered and where I think it requires more research.
None of the referred tickets are really solved - so all need more research and infrastructure improvements.

For the time being, I think no user is harmed by the bundles. Contributors have a very rampant learning curve.
But who contributes code? David heavily contributes thoughts for algorithms, names, documentation - and didn't complain about the complexity (maybe because it doesn't matter for some shots).

Cheers

Jens Rehsack - rehsack@gmail.com

@ribasushi

This comment has been minimized.

Copy link

commented May 4, 2015

For the time being, I think no user is harmed by the bundles.

This line of thinking is appealing, yet fundamentally misguided. Moreover the bundling isn't the real problem here.

The reality is you simply don't know, and more importantly have no practical way of knowing how many issues are you creating at the installation endpoints by generating 80 LoC utilising ~10,000 LoC (either bundled or installed at configure-time). This (as of yet) unjustified complexity is what the PR is about.

@shadowcat-mst

This comment has been minimized.

Copy link

commented May 4, 2015

If it's too young to be critiqued yet, then surely it's also too young to be used in an infrastructure level distribution like List::MoreUtils.

I appreciate your desire to experiment with better solutions in this space, but you shouldn't be doing that on a dist that's this heavily embedded in applications' dep chains.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 4, 2015

Am 04.05.2015 um 19:59 schrieb Peter Rabbitson notifications@github.com:

For the time being, I think no user is harmed by the bundles.

This line of thinking is appealing, yet fundamentally misguided. Moreover the bundling isn't the real problem here.

The reality is you simply don't know, and more importantly have no practical way to know how much issues you are creating at the installation endpoints by generating 80 LoC utilising ~10,000 LoC (either bundled or installed at configure-time). This (as of yet) unjustified complexity is what the PR is about.

Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).

However - the C::AC bundle is smaller that 3k LoC, T::WV+D::T is clear need being wiped out - but not in a dumb way but in a smart way.

Cheers

Jens Rehsack - rehsack@gmail.com

@ribasushi

This comment has been minimized.

Copy link

commented May 4, 2015

Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).

I never denied that I have no idea what you mean by wrong code. Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

However - the C::AC bundle is smaller that 3k LoC

Still utterly missing (or deliberately ignoring) the actual problem...

@rehsack

This comment has been minimized.

Copy link
Member

commented May 4, 2015

Am 04.05.2015 um 20:19 schrieb shadowcat-mst notifications@github.com:

If it's too young to be critiqued yet, then surely it's also too young to be used in an infrastructure level distribution like List::MoreUtils.

Sounds to me like you want to misunderstand what I wrote.

I appreciate your desire to experiment with better solutions in this space, but you shouldn't be doing that on a dist that's this heavily embedded in applications' dep chains.

I'm sorry when I reply to an unreflected answer to my explanations always the same way: Please dig deeper into the problems I'm trying to solve and discuss on that level. Whenever the shot is a one- or two-sentence platitude, what kind of answer is expected?

C::AC is not young. T::WV/D::T is - and I'm happy to discuss ways to eliminate it. Discussing means speaking about design before implementation, having a strategy and listening to all open issues need to be resolved when touching the stuff.

IIRC we negotiated to have an hour during FOSDEM developing some strategy how to get rid of T::WV in LMU - but unfortunately we didn't manage it.

Cheers

Jens Rehsack - rehsack@gmail.com

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Am 04.05.2015 um 20:35 schrieb Peter Rabbitson notifications@github.com:

Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).

I never denied that I have no idea what you mean by wrong code.

So when - after several explanations - (vou) don't understand what I mean by /wrong code/ - and no questions rwrt. the explanation is coming back but rhetoric claims wrt. overly-complex starting again and again, what conclusion is the one I have to extract?

Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

Can you provide the calculation for the 99.9%?

However - the C::AC bundle is smaller that 3k LoC

Still utterly missing (or deliberately ignoring) the actual problem...

Reviewing the patch, it's a big part of the original problem and I've not seen before this reply a reduction to user-side test generation (which is wrong, it doesn't generate test, it generate test endpoints). Please explain the actual problem.

So - beside the offending rhetoric - what's (with https://rt.cpan.org/Public/Bug/Display.html?id=102885, distribution splitting and test sharing without manual copy of code!) a reasonable way to have the test endpoints generated in deployed tarball? With the picture I have of the final result of rework, there is no generated test endpoint at all.

However - respecting the "form follows function" guideline - I intend to postpone the infrastructural cleanup after discussing lacking features and requirements. While this step in in progress, explain why reducing infrastructure capabilities before knowing about all requirements of the distribution is reasonable.

@ribasushi

This comment has been minimized.

Copy link

commented May 5, 2015

@rehsack Please concentrate on the proposed PR (which is merely 214 lines to review):

So far you have not addresses either of these questions.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

I commented that very long in #9 (comment).

@ribasushi

This comment has been minimized.

Copy link

commented May 5, 2015

I reread the entire comment just now. From that comment the only currently relevant part is this:

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).

As far as I can see the rest of your comment no longer applies (there are no further configure-time checks the module requires). This the question - if the PR is amended with use of EU::HasCompiler - does it address all the practical issues (leaving the political aside)?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Am 05.05.2015 um 09:41 schrieb Peter Rabbitson notifications@github.com:

I reread the entire comment just now. From that comment the only currently relevant part is this:

That was much to fast with checking the cited PR's and the follow-up's, but ...

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).

As far as I can see the rest of your comment no longer applies (there are no further configure-time checks the module requires). This the question - if the PR is amended with use of EU::HasCompiler - does it address all the practical issues (leaving the political aside)?

$Config::Config{cc} is not political wrong, it's technical wrong. can_xs() will succeed even with completely different(*) header files than the running configure stage, will succeed without proving linking or loading, ignores cross-compiling and is completely manual code copying in case of fixes and enhancements.

*) different in "belongs to another perl"

@ribasushi

This comment has been minimized.

Copy link

commented May 5, 2015

That was much to fast with checking the cited PR's and the follow-up's, but ...

I was already re-reading the PRs to make sure I am not missing anything before your "look here".

...can_xs() will succeed...

I wasn't talking about can_xs(), I was asking you about can_compile_loadable_object()

Can we focus on that please?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Am 05.05.2015 um 09:54 schrieb Peter Rabbitson notifications@github.com:

That was much to fast with checking the cited PR's and the follow-up's, but ...

I was already re-reading the PRs to make sure I am not missing anything before your "look here".

...can_xs() will succeed...

I wasn't talking about can_xs(), I was asking you about can_compile_loadable_object()

Can we focus on that please?

Sure, I misunderstood it. I had several discusses with @Leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.

Even if there is another external module proving a better "HasCompiler" - it doesn't answer the can_xs (which is one of the goals of C::AC). Due TIMTOWTDI ....

There are likely several configure time checks remaining (needs research):

  • PadWalking
  • MAX/MIN Integer values

and maybe more (we're currently discussing harmonizing iterator- and partitioning functions).

As far as I can currently see, with some extra effort it will be possible to move all test endpoint generation to author side (this is one of the major results from using D::T/T::WV in LMU I discussed with Tim - but there were no tuits meanwhile ...). Anyway - concentrating on features before will make us sure and not best-guessing.

Cheers

Jens Rehsack - rehsack@gmail.com

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Am 05.05.2015 um 09:41 schrieb Peter Rabbitson notifications@github.com:

I reread the entire comment just now. From that comment the only currently relevant part is this:

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).

Where is this $config coming from: https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L118 ?
ExtUtils::Config looks like a wrapper around Config.pm ...

If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity. Maybe it's more a question of control?

The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...

@Leont

This comment has been minimized.

Copy link

commented May 5, 2015

I had several discusses with @Leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.

I was unexpectedly busy before Berlin, and then suddenly you weren't there, hence that kind of fell through.

If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity.

It's meant to allow one to override Config values, as the real thing is read-only.

The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...

If something about it is broken in some circumstance please file an issue, I'm sure it can easily be solved.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Am 05.05.2015 um 13:49 schrieb Leon Timmermans notifications@github.com:

I had several discusses with @Leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.

I was unexpectedly busy before Berlin, and then suddenly you weren't there, hence that kind of fell through.

The entire PR and the discussion about it and the russian front against it are much older than qah2015 ...
It started before qah2014 - and the personal level it reaches again and again ...

If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity.

It's meant to allow one to override Config values, as the real thing is read-only.

Than it's not enough for being a probe result backend (cc, cflags, includes, ... are probe results - similar to HAVE_STDINT_H, or which limits.h to include (sys/limits.h, limits.h, etc.) ...)

The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...

It's young, if something about it is broken in some circumstance please file an issue, I'm sure it can easily be solved.

None of that was meant as an affront - I know these. It was meant to enlighten Peter, because he asked.
Very likely over summer we find some tuits to improve. When you're not that busy anymore - we could start the discussions about probes and portability issues we talked about on FOSDEM. Maybe hangout or so - just to avoid new flame wars while working ...

@ap

This comment has been minimized.

Copy link

commented May 5, 2015

Von @shadowcat-mst:

Also gut, noch mal von vorn.

Mir ist es lieber, etwas weithin verwendetes zu nehmen, das dadurch in genau der gleichen Art defekt ist wie der Rest meiner low-level-Abhängigkeiten, als etwas brandneues und unzureichend getestetes mit vollständig unbekanntem Ausfallverhalten.

[Das lasse ich mal Englisch, da schwer zu übersetzen.]
[I’ll leave this in English because it’s hard to translate.]
This is systems level work. The principle of least surprise is important.

Wenn du denkst, dass dein Ansatz, sobald er tatsächlich ausreichend getestet ist um als stabil zu gelten, besser sein wird, so stellt das einen guten Grund dar, die Arbeit daran weiterzuverfolgen.

Aber nicht innerhalb von List::MoreUtils. Mit List::MoreUtils müssen wir konservativ umgehen, oder du musst eine grosse Warnung ins POD schreiben die sagt “instabil, auf diesen Code sollte man sich nicht verlassen wenn man Stabilitätsanforderung auf Unternehmensebene hat” und ich muss dann meine Distributionen umschreiben um ihre Abhängigkeiten auf etwas umzustellen, was entsprechend konservativ gepflegt wird.

Wenn ich meinen Krempel im Wochentakt durch neue nicht getestete Ideen ersetzt haben wollte, könnte ich meinen Lebensunterhalt auch mit node.js bestreiten.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 5, 2015

Mir ist es lieber, etwas weithin verwendetes zu nehmen, das dadurch in genau der gleichen Art defekt ist wie der Rest meiner low-level-Abhängigkeiten, als etwas brandneues und unzureichend getestetes mit vollständig unbekanntem Ausfallverhalten.

Und das steht Dir natürlich frei. Da für mich eine Architektur aus den 1990'er Jahren, eine erste Perl-Implementierung von 2005 und die aktuelle Lösung von 2012 nicht wirklich brandneu ist, bin ich da etwas befremded bezüglich der beweisfreien Aburteilung. Aber da ist scheinbar jeder anders - es sei Dir unbenommen, Deine Distributionen mit bekannten Fehlern in der Infrastruktur auszustatten.

Es ist nicht wahr, das auf System-Ebene das Prinzip der geringesten Überraschung an erster Stelle steht, an erster Stelle steht insbesondere auf der System-Ebene die (Daten-)Integrität und Zuverlässigkeit. Es scheint mir, Du interpretierst Zuverlässigkeit in der Art "Ich kann mich darauf verlassen, das ein Prozess immer auf die gleiche Art und Weise fehlschlägt" anstatt "Ich kann mich darauf verlassen, das ein Prozess funktioniert". Ich halte diese Interpretation für fahrlässig.

Ich denke nicht nur, das mein Ansatz irgendwann einmal ausreichend getestet sein wird, ich denke, das er das ist.

Die Konfigurationsphase hat keinen Einfluss auf die Stabilität des Codes an sich - aber auch am Code behalte ich mir Optimierungen und Fehlerbehebungen vor - selbstverständlich nicht ohne dev-releases. Wir reden aber über Infrastruktur, und zwar auf der Ebene Konfigurationsphase. Bitte hör auf, hier Ebenen zu vermischen!

Wenn Du mit meiner Art der Distributionspflege nicht einverstanden bist, darfst Du gern wirklich Zeit investieren und wir diskutieren viele Details aus.

Wenn ich meinen Krempel im Wochentakt durch neue nicht getestete Ideen ersetzt haben wollte, könnte ich meinen Lebensunterhalt auch mit node.js bestreiten.

Der ganze Thread ist voll von diesen Provokationen. Bitte bleib sachlich.

@Leont

This comment has been minimized.

Copy link

commented May 5, 2015

I looked at it and it didn’t take me half an hour (see #9 (comment)) to point out several problems. In a closer circle I have criticised those snippets before.

You keep saying there are issues with other solutions, but does your solution really fix it? Today? Config::AutoConf is based on ExtUtils::CBuilder, which IME isn't more likely to do something sensible than what @haarg proposed. AFAICT, nothing takes things like cross-compilation much into account today. Or am I mistaken?

@ap

This comment has been minimized.

Copy link

commented May 5, 2015

From @rehsack:

I would rather use something widely used that means that it will be broken in the exact same way as most of the rest of my low level dependencies in the case that it is broken, than something completely new and under-tested with completely unknown failure modes.

And of course you are free to do that. To me, a design from the ’90s with a first implementation in Perl in 2005 and the current solution from 2012 is not in fact completely new, therefore I am a little taken aback by the proofless dismissal. But apparently everyone is different in that respect – of course you ought to be at liberty to equip your distributions with known flaws in their infrastructure.

It’s not true that the principle of least surprise has primacy in systems level work, what comes first is (data) integrity and reliability. It seems to me that you interpret reliability as in “I can rely on a process always failing in the same way” rather than “I can rely on a process working”. I consider this interpretation negligent.

I do not merely think that my approach will eventually be sufficiently tested, I think that it is.

The configuration phase has no influence on the stability of the code itself – though I reserve the right to fix or optimise the code too – naturally not without dev releases. But we are talking about infrastructure, and specifically at the level of the configuration phase. Please stop mixing up the levels!

If you do not agree with my way of distribution maintainership, you are welcome to invest time properly and we can thrash out the details.

If I wanted things replaced every other week with untested new ideas, I could go write node.js for a living.

The entire thread is full of these provocations. Please stay objective.

@ap

This comment has been minimized.

Copy link

commented May 5, 2015

Von @Leont:

Ich habe mir das angesehen und brauche keine halbe Stunde (siehe #9 (comment)) um mehere Problempunkte aufzuzeigen. Ich habe in kleiner Runde diese Codeschnippsel bereits kritisiert.

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich? Hier und heute? Config::AutoConfig basiert auf ExtUtils::CBuilder, welches meiner Erfahrung nach keine höhere Wahrscheinlichkeit zeigt, etwas Sinnvolles zu tun als der Vorschlag von @haarg. Soweit ich beurteilen kann werden Dinge wie Cross-Kompilierung von nichts Verfügbarem grossartig berücksichtigt.
Liege ich da falsch?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 6, 2015

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Die meisten, jedoch nicht alle.

Soweit ich beurteilen kann werden Dinge wie Cross-Kompilierung von nichts Verfügbarem grossartig berücksichtigt.
Liege ich da falsch?

Ja. Siehe https://metacpan.org/source/REHSACK/Unix-Statgrab-0.107/inc/Config/AutoConf/SG.pm und https://github.com/rehsack/meta-cpan/tree/master/recipes-sysutils/unix-statgrab-perl.

Um das alles mal zu zeigen, wollte ich ja mit meiner Build-Workstation zum QAH kommen - mir ist durchaus bewusst, das die meisten TPG Hacker eher im Rechenzentrums-Umfeld arbeiten.

@ap

This comment has been minimized.

Copy link

commented May 6, 2015

From @rehsack:

You keep saying there are issues with other solutions, but does your solution really fix it?

Most of those, though not all.

AFAICT, nothing takes things like cross-compilation much into account today. Or am I mistaken?

You are. See https://metacpan.org/source/REHSACK/Unix-Statgrab-0.107/inc/Config/AutoConf/SG.pm and https://github.com/rehsack/meta-cpan/tree/master/recipes-sysutils/unix-statgrab-perl.

Showing all of this stuff was the reason I wanted to bring along my build workstation to the QAH – I am well aware that most TPG hackers work in more of a data center environment.

@shadowcat-mst

This comment has been minimized.

Copy link

commented May 7, 2015

You keep saying there are issues with other solutions, but does your solution really fix it?

That's exactly the question we've been asking of you all along, and 'really fix it' won't be proven until you use it for a year or two in a non-critical distribution (as it wouldn't if said fix was my idea too).

In the meantime, how about letting LMU be stable while you prove that your solution really does fix it?

@ap

This comment has been minimized.

Copy link

commented May 7, 2015

From @shadowcat-mst:

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Das ist genau die Frage die wir dir die ganze Zeit gestellt haben, und »wirklich korrigieren« wird sich nicht erweisen ehe du sie für ein Jahr oder ein paar in einer unkritischen Distribution eingesetzt hast (genauso wie es sich auch nicht anders erweisen würde, wenn die Idee von mir käme).

Wie wäre es für die Zwischenzeit damit, LMU stabil sein zu lassen, während du den Praxisbeweis deiner Lösung erbringst?

@rehsack

This comment has been minimized.

Copy link
Member

commented May 7, 2015

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Das ist genau die Frage die wir dir die ganze Zeit gestellt haben, und »wirklich korrigieren« wird sich nicht erweisen ehe du sie für ein Jahr oder ein paar in einer unkritischen Distribution eingesetzt hast (genauso wie es sich auch nicht anders erweisen würde, wenn die Idee von mir käme).

Ich habe diese Frage bereits beantwortet. Und die Lösung ist seit wesentlich mehr als einem Jahr in unkritscheren Distributionen im Einsatz, um sich zu beweisen. Und zwar nicht nur in Distributionen von mir, eine Suche im Herbst ergab 28 Benutzer, die C::AC aktiv verwenden.

Wie wäre es für die Zwischenzeit damit, LMU stabil sein zu lassen, während du den Praxisbeweis deiner Lösung erbringst?

Hier vermischt Du C::AC und D::T - das erstere ist stabil, das letztere hat sich noch nicht bestätigt.
Das ist - so wie ich das jedenfalls sehe - auch meine Haltung den ganzen Thread über.

Ich bin im übrigen auch gern bereit, ein bis zwei Einführungs-Workshops zu C::AC zu geben. Ich kann durchaus verstehen, das sich Hirnknoten bilden, wenn man das reviewed.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 7, 2015

Ich würde gern noch etwas hinzufügen (@ap: Kann eingefügt werden, ich wollte nur einer etwaigen laufenden Übersetzung nicht reinschießen).

Für den Fall, das Du meinst, die Lösung sollte für mehr als ein Jahr von der TPG beobachtet werden, bevor ... - ich habe in Kiew dazu einen Vortrag gehalten, das ist auch etwas her. Die Aufmerksamkeit auf etwas ungewolltes zu lenken, ist bei sturen Genies unglaublich schwer - und ggf. müssen diese dann mit anderen Formen der Beweisführung leben. Das fällt momentan auch bei ShareDir & Co. auf.

Auch wenn es irgendwo Arschloch ist - wenn sich bzgl. solcher Themen für mehr als ein halbes Jahr auf mehrere Anfragen hin nichts tut, ist das Feedback-Fenster einfach zu.

Bzgl. »wirklich korrigieren« - wir nehmen nur für die Betrachtung mal an, meine Lösung wäre nicht weiter als die breit eingesetzte Lösung. Selbst dann verfügt meine Lösung über einen nicht zu unterschätzenden Vorteil: jede Probe wird mit Ergebnis geloggt. Wenn also Makefile.PL aussteigt, bekommen wir ein log, in dem drin steht, was und in >90% der Fälle auch warum etwas fehlschlug. Und da wir nun doch etwas vor der aktuell massenhaft eingesetzten Lösung sind - sind das gleich zwei Vorteile.

@ap

This comment has been minimized.

Copy link

commented May 7, 2015

From @rehsack:

You keep saying there are issues with other solutions, but does your solution really fix it?

That's exactly the question we've been asking of you all along, and 'really fix it' won't be proven until you use it for a year or two in a non-critical distribution (as it wouldn't if said fix was my idea too).

I have already answered that. And the fix has been in use in some non-critical distributions for significantly longer than a year, in order to be proven. And that’s not just in my own distributions: a search I did in autumn turned up 28 active users of C::AC.

In the meantime, how about letting LMU be stable while you prove that your solution really does fix it?

Now you are confusing C::AC with D::T – the former is stable, the latter is not yet proven.
And that has – in my own perception – been my stance for the entire duration of this thread.

Incidentally I am entirely willing to give one or two introductory workshops about C::AC. I can well understand that it’s a brain twister to review.

@ap

This comment has been minimized.

Copy link

commented May 7, 2015

More from @rehsack:

In case you mean the solution should be monitored by TPG for more than a year, before … – I gave a talk in Kiev regarding that (even that has been a while). Turning the attention to something unwanted is incredibly difficult [for/with?] stubborn geniuses – so they may have to live with other forms of proof. I am currently noticing exactly the same with ShareDir and the like, too.

Even if it’s arseholish on some level – if nothing happens in such matters for over half a year and after multiple requests, the feedback window is quite simply closed.

Re “really fix” – let’s just assume for the sake of discussion that my solution went no further than the widely used one. Even then my solution possesses an advantage that is not to be sneezed at: every probe plus result is logged. So when a Makefile.PL aborts, we get a lot that says what failed and in >90% of cases also says why. And since in fact we are ahead of the widely used solution – that actually makes two advantages.

@Leont

This comment has been minimized.

Copy link

commented May 8, 2015

IMO there are two intertwined but different issues at play here. I suspect it may be helpful to split the them.

The first is that of configure-phase test generation. I think there's broad consensus that that is better moved to the dist-building phase. I think there is less agreement on what priority this has and whose responsibility it is to do this. For some this is dangerous and needs to be fixed urgently, for Sno I think that's a "go ahead, but other requirements must be taken care of". This is the main topic in this ticket.

The second is issue is how to do the compilation checking. This got entwined because currently it is part of the configure-phase test generation, but does not necessarily have to be. I suspect this belongs in a separate ticket.

@ap

This comment has been minimized.

Copy link

commented May 8, 2015

Von @Leont:

Meiner Meinung nach sind hier zwei verflochtene aber unterschiedliche Aspekte in Spiel. Ich vermute dass es hilfreich wäre, sie getrennt zu betrachten.

Das erste Thema ist die Test-Erzeugung in der Configure-Phase. Ich denke dass weitgehender Konsens besteht, dass das in die Distributions-Bau-Phase verschoben werden sollte. Ich glaube dass es weniger Einigkeit darüber gibt, welche Priorität das hat und wessen Verantwortung es ist. Einige halten es für gefahrenträchtig und umgehend zu beheben, während Sno’s Haltung eher nach »immer zu, aber andere Anforderungen müssen erfüllt werden« neigt. Das ist das Hauptthema in diesem Ticket.

Das zweite Thema ist, wie der Compile-Test funktionieren soll. Das hat sich hier eingewoben, weil es gegenwärtig Teil der Test-Erzeugung in der Configure-Phase ist, was aber nicht notwendigerweise so sein muss. Ich vermute dass das eher in ein anderes Ticket gehört.

@ribasushi

This comment has been minimized.

Copy link

commented May 8, 2015

@ap: You've done a splendid job translating this train-wreck of a conversation. I think at this point the intents of all parties are crystal clear, and there is no room for subtlety. Hence the thread should switch to english, so that the significant effort of translation is not necessary.

Not that there is much left to say.

@rehsack

This comment has been minimized.

Copy link
Member

commented May 8, 2015

The very most important part from @ap's job was the removal of the pressure. He did it by doing an impressive job in translating - but the intents of all parties are clear as few days ago - at least to me ...

So from my perspective, the effort of @ap was the transporting my intension to everyone else.

Dunno whether you want miss that kind of support.

@Leont - generating the currently used test endpoints on developer side is more or less a no-brainer. This can easily be done (even if sane authoring implementation needs a little bit more than copy some files and never touch them again) - and I would do if one opens a ticket and explains the priority (all I read is a bad mood because of that - and I received some offers for bikeshedding which never comes - so I postponed the work because I assumed everything is ok).

My impression is still that most of the thread is more about mood than about hard facts.

@ap

This comment has been minimized.

Copy link

commented May 8, 2015

My impression from the middle was that at the time I started, there was significant miscommunication on both sides. At this point the major confusion does seem sorted out.

rehsack added a commit that referenced this pull request May 8, 2015

move generation of test endpoints to author stage
as requested issue/#9 (PR, but patch not wanted ...)
@rehsack

This comment has been minimized.

Copy link
Member

commented May 8, 2015

That's true - and I've learned a lot about how nice and beautiful english language could be. Thanks a lot for mediation and enlightening.

@rest - what about 91f51ea ? When this makes some of you happy - I'm fine with it.

@ribasushi

This comment has been minimized.

Copy link

commented May 9, 2015

Commenting on the "Sandbox" part of 91f51ea (only): it does solve the issue of user-side test generation. The only note to add is that across CPAN the generically used name for "Sandbox" is maint/ (or something equally descriptive).

I am opening a different issue for the other problem as per #9 (comment).

For anyone interested please refer to: #11

@rehsack

This comment has been minimized.

Copy link
Member

commented May 9, 2015

Well - @Tux uses sandbox and his kind of giving guidance is much more timtoady and encouraging than ignoring and forcing.

@Leont

This comment has been minimized.

Copy link

commented May 10, 2015

Looks fine to me.

@rehsack

This comment has been minimized.

Copy link
Member

commented Feb 18, 2017

I think this PR is a bit deprecated now. I processed L::MU as intended and left out weird tests.
Please feel free to optimize the recent head.

@rehsack rehsack closed this Feb 18, 2017

rehsack referenced this pull request Mar 23, 2017

POD: rectify license conditions
As pointed out by mst in issue#24 it must be clear which code is released
under which license and re-licensing old code requires permission of all
authors.

To make it clear to anyone: any code release after 0.416 (or much more
precise: code from me with begin of commit d32dfb4), code from contributors
after this commit.

Confused? Send your thanks to people bugging code should be moved to
List::Util, List::SomeUtils etc.

Signed-off-by: Jens Rehsack <sno@netbsd.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.