Include readme like information for local imports

[Konrad Zapałowicz]

This is to propose including readme-like information for imports that end up being used locally (--no-push --no-clean) so that the importer is better informed about what is the state after the import finishes.

Right now the target directory seems to be empty (only hidden dirs) and no branch is checked-out (orphaned state). At the first glance it looks like something has gone wrong when in fact everything is perfectly fine.

The proposal is to either:

1) for case mentioned above print short informational msg on the console that would describe the current state and give insights on how to move forward. kind-of a very quick start guide.

or:

2) end in a state where a special "readme" branch is checked-out with just a single file on it (README.md) that would describe the current state and give insights on how to move forward. kind-of a very quick start guide.

[Nish Aravamudan (nacc)]

This should be safe to do as 2) by putting a commit on the orphan master branch, where you stay after the nofetch/nopush import.

[Robie Basak (racb)]

Thank you for the report!

On Wed, Jul 19, 2017 at 08:57:12AM -0000, Konrad Zapałowicz wrote:
> 1) for case mentioned above print short informational msg on the console
> that would describe the current state and give insights on how to move
> forward. kind-of a very quick start guide.

I favour this option, as I'd prefer the result inside the git repository
to be exactly the same between the push and no-push modes.

[Nish Aravamudan (nacc)]

On Wed, Jul 19, 2017 at 3:56 PM, Robie Basak <email address hidden> wrote:
> Thank you for the report!
>
> On Wed, Jul 19, 2017 at 08:57:12AM -0000, Konrad Zapałowicz wrote:
>> 1) for case mentioned above print short informational msg on the console
>> that would describe the current state and give insights on how to move
>> forward. kind-of a very quick start guide.
>
> I favour this option, as I'd prefer the result inside the git repository
> to be exactly the same between the push and no-push modes.

I wonder if in the --no-push case, it would be sufficient to checkout
a local branch to ubuntu/devel from namespace/importer/ubuntu/devel
and leave the repo in that state. We could also checkout to a detached
HEAD state, but that might be more surprising (but would mean the
'repo' state in push and no-push modes is identical). That will be
roughly the same commitsh as the bot importer running at the same time
and then `git ubuntu clone`?

[Robie Basak (racb)]

On Wed, Jul 19, 2017 at 04:59:13PM -0000, Nish Aravamudan wrote:
> I wonder if in the --no-push case, it would be sufficient to checkout
> a local branch to ubuntu/devel from namespace/importer/ubuntu/devel
> and leave the repo in that state.

I agree. Konrad, would that be acceptable?

[Konrad Zapałowicz (kzapalowicz)]

@Robie, @Nish, I think it will be acceptable.

Additionally, for inspiration, check out how we have implemented one of our tools. It outputs some kind of handy info when it is done with it's work https://pastebin.canonical.com/193942/ My original idea was sth like this. What do you think?

[Robie Basak (racb)]

There's a TAOUP principle that commands should be silently successful and only noisy on failure. Otherwise scripts become extremely noisy. And a familiar user loses the value of backscroll because it's too noisy too. So there's a balance that needs to be struck I think.

[Robie Basak (racb)]

(also, being noisy hides errors)

[Konrad Zapałowicz (kzapalowicz)]

Good point. However I have been thinking just about this part:

At this point you are on a feature/new-snap branch with all the
necessary files created and commited. Your job now is to fill them
with valid data.

There is also 'master' branch available with an empty README.md
commited (but not pushed) there.

I have not pushed anything and it is your job to do so. Make sure
that you follow the way-of-working that is:
 - First git push origin master
 - Add your own remote pointing to your repository and push
   feature/new-snap there.
 - Submit your snap as a MP against master branch that you just have
   pushed directly

Have fun!

In your case it would be even shorter. Nevertheless I will not strong argue about it.