[meego-packaging] rejections FAQ - upstream tarball in MeeGo should be an upstream released or tagged version (was RE: autospectacle)

[Arjan van de Ven]

On 8/4/2010 12:33 AM, fathi.boudra at nokia.com wrote:
> It seems we don't have a consensus on this topic.
> So let's continue the debate in the appropriate thread.
>
>    
>> at least in Moblin we've been burned many times from not doing that...
>> and really have absolutely no appetite to try again.
>>      
> Could you elaborate?
>    

we had a constant stream of issues like "oh not that one" "oh not that 
branch" "oh not that git"

a release makes a very clear, undeniable and explicit handoff, and a 
tarbal is the customary and most obvious way to get a release done.

yes a maintainer can do all the same steps for a release (including 
making a tarbal for himself to verify it's complete etc) and then just 
not upload the tarbal he made.
and no I really don't care, uploading the tarbal is such a small effort 
that I don't buy that.

>    
>> if software isn't good enough for upstream
>> to make a release from it, it's not good enough for MeeGo.
>>      
> It's free-software, I know several upstream that don't do proper release tarball.
> I don't think we should skip some piece of software because the upstream is lazy to do a release.
>    

if the upstream is bad, and a good alternative is available...

and here we're not talking about some random obscure upstream, but a 
meego related upstream.

 > What is everyone else here? All distributions allows 
snapshot/unreleased software.

many distributions only allow this by high exception, and generally hate 
it.... well guess what, so does meego right now
> We can't force upstream to do proper release... so a fallback should be allowed.
>    
every policy can have exceptions for good cause

the packages this is about aren't.