Michael Schwendt wrote: > On Sun, 29 Oct 2006 14:53:43 +0100, Hans de Goede wrote: > >> That depends on the afterwards, 2 days later no that is seriously >> abusing the process, but 6 months later if the packager finds he has a >> good reason yes, once again we have to trust each other! > > Again, this is splitting-hairs. > > And once more, even if an upgrade to a beta is done 6 months later, the > reason for such an upgrade can be documented in the %changelog. > And again I agree, I must have misread / understood you wrong. There aren't many ways to rub me the bad way / I don't have many allergies, but bureaucracy is one of them, so I guess I overreacted. Yes requesting people to properly document the why (for example in case a special request was made through BZ refer to the BZ ticket) is very reasonable. > Afterall, the packager overrules upstream's release scheme. Sometimes much > disliked by upstream developers when they discover that a distribution > includes a pre-release. Why not document the decision? > Documenting good, having to ask permission bad, so it seems we agree and I misunderstood. >>>> Its quite simple: motivated and educated packagers good, bureaucracy bad! >>> Motivation is a rather vague term here. Too much "wrong motivation" can >>> easily lead to over-ambitious packaging and then is bad, too. >>> >> Once again this all boils down to trust, and we can't trust each other >> we might as well stop FE right here and now! > > The step you're missing is the time it takes to build up trust. > Yes the time needed for new FE contributers to become familiar with FE and more importantly to learn all the fine details (like whats an ABI, how can I check if it changes?) is a problem, but we must have a way for people to make mistakes to learn from. I do not see an easy answer to this. In the case of ABI breakage I guess we need to write some docs on this, atleast on howto check for soname changes. Also I prefer to start with a certain level of trust, but I think our main "conflict" here is the choice of words, with trust I mean the Dutch vertrouwen, German Vertrauen. As said I prefer to trust people (with regard to their intensions) from the start, I agree that with regard to their technical skills they often have to learn much and that takes time. > We are at a level where we still see ABI breakage in upgrades for FE5 or > FE6. Usually, the spec changelog says nothing else than "Update to 2.x", > and only afterwards, the reported breakage is cleaned up with rebuilds. > No comment on whether the ABI breakage was expected or not. If breakage > was expected, I would hope for at least a warning the in spec changelog. > And that would increase trust in the packager. > Yes that is a big problem, one which I was bitten by once too with my directfb push. Now I know better and I only do ABI changing updates in devel. I've just pushed a few now FE-6 is out, which I have deliberately delayed until FE-6 was released as I didn't want to add any ABI breakage to devel once the mass rebuild had started. Going offtopic here, AFAIK we still don't have a policy for this I once did a feeble attempt at one, but I now see that was overcomplicated and thus didn't get a warm reception, may I thus introduce a new attempt at a simple soname / ABI breakage policy: 1) soname / ABI changing updates may only be done in the devel branch 2) Normally* any not backward compatible ABI change should come with a new soname 3) Any ABI and/or soname packages must be announced with a mail to fedora-extras-list 4) Adding new libraries to non devel with a different soname then found in existing packages of these libs in third party repos should be avoided. *) Exception, when you're packaging a pre release of a library the ABI may change without changing the soname, packaging such a pre-release should be avoided if possible. > In one mail, you wrote: > >> Yes, so we need high quality packagers, we need to educate them, no >> system is 100% error free, > > So, obviously there are different levels of trust. One level is to trust > a packager's good intentions. Another level is to trust his capabilities. > Ah, yes I see now how you use (and can use) the same word (trust) for these two, forget about my above ramblings. Yes I agree I assume good intentions, but I don't assume good packaging skills > What is so difficult about requesting packagers to be more verbose in > spec changelog comments _and_ reviews? It is not bureaucracy where you > depend on somebody else's decision. You just document "your stuff" and > be done. > As already said I agree, this mainly seems a misunderstanding, sorry! Regards, Hans -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
