[meego-packaging] rejections FAQ - upstream tarball in MeeGo should be an upstream released or tagged version (was RE: autospectacle)
Arjan van de Ven
arjan at linux.intel.com
Wed Aug 4 04:15:44 PDT 2010
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
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.
More information about the MeeGo-packaging