On Apr 16, 2011, at 11:17 AM, Per Øyvind Karlsen wrote: > 2011/4/16 Jeff Johnson <n3...@mac.com>: >> Ok enough. >> >> We _ARE_ headed for a fork between rpm5.org <-> Mandriva if these check-ins >> continue. >> >> I've asked for discussion first. Not happening. >> >> I've asked for a feature list. Not seen. >> >> I've pointed out that many of these changes are ancient hysteria being >> recycled as Newer! Better! Bestest! >> >> There is noone asking for these changes. Show me. > These are already in use on Mandriva and part of the helpers migrated > from rpm-mandriva-setup. >
For what a week? With no release cycle? And no visible discussion?
>>
>> There are no test cases. I will make that policy MANDATORY if necessary.
>>
>> There is nothing but a 1-line description, essentially
>> Add new stuff.
>> No examples, no writeup, no usage case, nothing.
> ?
> Both commit messages, entry in CHANGES and the code itself should
> generally have at least the bare minimum to provide some pointers for it..
There is insufficient info to tell anything that is intended.
>>
>> Its happening on the "production" branch (in this case) creating
>> divergence that I have to muck about with later, often breaking
>> code because I haven't any clue what is what.
> I've placed it under mandriva #ifdef, so it shouldn't break things for
> anyone else on the
> production branch..
ANd you clearly missed a spot, many in fact. I'm tired of feeping creaturism.
Last October, I expressed a desire to merge or drop _ALL_ vendor peculierities.
There is a blueprint at launchpad that was created for the sole purpose
of trying to prioritize the work.
The intent was to have per-vendor patches merged or dropped by January 1st.
Well let's move that date to May 1st, and merge/removal on June 1st.
Any per-vendor patches that aren't discussed, and with some attempt at test
cases,
will be dropped.
>>
>> None of this code is maintainable or useful imho until some of the above is
>> corrected.
> If I'm gonna be able to migrate to the internal dependency generator, I must
> add
> these to avoid ~regressions.
>
If these are short term hacks with a specific goal, then add a drop-dead
date. If you need after the drop-dead date, then move the date.
> If a discussion and test cases is required provided first, I won't be
> able to have time to
> switching to the internal dependency before after next mandriva release..
>
If you had given me the feature list, or anything else, you might find me
willing to help.
Meanwhile 24 hours ago I asked Eugeni:
Are there any MUSTHAVE features needed before Mandriva 2011?
The answewr was
No.
SO get your act together and list what is coming in priority order.
I'm way tired of having to clean up a mess after the fact simply
The dog ate my homework.
translates into developer speak as "No time, gotta hack."
> Or I can go back to maintaining patches locally in cooker svn..?
>
You can do what you wish. If you wish the code @rpm5.org I need a clue
about what and why. I cannot maintain code under #ifdef YOUR_VENDOR_HERE
because I never see the code, haven't any clue, etc, etc.
Meanwhile your check-ins are _NOT_ under #ifdef and you argued with
Distepoch and now devel(...) that these are somehow generally useful.
Now try launchpad blueprints instead of arguing with me. You have until
May 1st, and merge/remove by June 1st.
73 de Jeff
> --
> Regards,
> Per Øyvind
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
