Deprecating the wiki-based Packaging Guide

[Mike Carifio]

On 12/18/2012 05:48 PM, Scott Kitterman wrote:
> Barry Warsaw <barry at ubuntu.com> wrote:
>
>> On Dec 17, 2012, at 07:52 PM, Scott Kitterman wrote:
>>
>>> UDD is not mature or reliable enough to be presented to new users as
>> "the"
>>> way to do packaging for Ubuntu.  I think the current guide is fatally
>> flawed
>>> as is.
>> Yes, it's frustrating when you need to work on a package that has
>> import
>> failures, and yes, I wish we had more cycles to devote to fixing this,
>> but the
>> majority of packages import just fine, and UDD (IMHO and YMMV) has
>> enormous
>> benefits which outweigh those frustrations.
>>
>> Of course, I'm not saying that traditional packaging shouldn't also be
>> described.
>>
>> -Barry
> It seems obvious to me that the standard approach ought to be the reliable one.  Making the UDD based approach 'normal' ensures people need to know two ways to do it and for introductory material, I think that is clearly suboptimal.
>
> Also, I think the benefits primarily accrue to people that use UDD a lot.  The benefits to people that don't use it quite regularly are minimal.  This reinforces the idea it's not the right default to present.
>
> Finally, it's a more complex toolset that raises the barrier to entry for newcomers.  I don't think that's what we want.
>
> Scott K

I don't mean to be argumentative, but none of that seems obvious to me.
If UDD is a better workflow when it works, then fix it until it works.
Then describe it so it makes sense. Then use it consistently to improve
the ecosystem. That will make it the default. Right now, we seem to have
to work with debian source packages so we can feed the build system but
work with a version control system to "upstream" changes in a productive
way. That seems suboptimal too.

I'm the first person to admit that I probably don't get it yet or see
the obstacles to UDD utopia. But not using a
version control tool for a source code control problem doesn't make
sense either.