Fedora Extras packaging beta software into production repos, why?

[Hans de Goede]

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