Comment 3 for bug 386596

On Fri, Jun 26, 2009 at 4:01 PM, Robert
Collins<email address hidden> wrote:
> On Fri, 2009-06-26 at 05:49 +0000, Jonathan Lange wrote:
>
>> On another axis, it's consistently restrictive -- we don't let you
>> create anything other than branches via the SSH server.
>
> Sure. However we want to change that don't we? to allow package
> builds-from-bzr and so on in the future :).
>
>> I talked to beuno about this (being a user-visible change, it needs a
>> UI
>> review). He suggested that we only create the package when --create-
>> prefix or some other option is passed to bzr, to avoid creating
>> packages
>> as a result of typos.
>
> I don't understand why creating a package is a problem. Surely a mistake
> can be corrected by just deleting the branch and the package?
>

In the following paragraph, I suggested that we point users to a way
of moving the branch to the package they intended and undoing the
creation of the package.

Why does 'bzr push' only create parent directories when
--create-prefix is passed? The directories can be deleted if there was
a mistake in the push location. To me, this seems like a analogous
user interface decision.

>> Another approach, which we didn't discuss, is for the codehosting
>> server
>> to create the branch without any special option, but to trigger some
>> client-side warning saying that it s doing so, and point to a way of
>> moving the branch to the correct package and undoing the creation of
>> the
>> package. This is probably more complicated to implement.
>
> Pragmatically, stderr on the ssh virtual socket is shown to command line
> users. There is a bug open about having something more sophisticated but
> I don't recall the number offhand.

It's still probably more complicated to implement, even with that.

In any case, beuno is the person to convince.

> I can suggest another option. Due to the machinery involved in
> packaging, the content in the packaging branch is tied to the release
> and package name; its actually possible to simply check that
> debiang/changelog is for the named package. (You could go further and
> check for the same release too if desired).
>

That would be still more complicated to implement, I think. If
implemented on the server side, it would make it inconvenient to push
new package branches that lack well-formed debian/changelog files.

jml