Hi Alex,

On Thu, 2018-03-15 at 11:58 +0300, Alexander Smirnov wrote:
> @Claudius:
> For me is very annoying when my question is ignored after explicit 
> re-posting. So let's be polite and keep conversations here free of
> emotions.

Read the following text without any emotions, apart from the paragraphs
  where I added the applicable ascii-emoji:

First, I already answered your question indirectly here:

>> If the distro-specific bootstrap mechanism builds its 'bootstraped
>> root file system' from a bunch of binary packages or directly from 
>> source is implementation and distro specific. So the distinction 
>> only makes sense in the upstream project but not here, since we are 
>> just using what the upstream distributions provides for general 
>> consumption.

Short: I don't agree with the presumptions in this question, therefor I
cannot answer it sensible.

And second I don't like responding to attempts at manipulation, like
you did with this loaded question:

> My question, why it's so important to use initially ambiguous term,
> which may lead to potential confusing for Debian users?

Maybe that is just a misunderstanding, but maybe we should go through
it piece by piece and then look at it as a whole, so you can understand
what I mean:

> My question, why it's so important

"why it's so important" reads accusatory, not neutral and together with
the following parts of this sentence colors the rest of your question
in a negative light.

> to use initially ambiguous term,

Here you are presuming my guilt by implying that I have chosen an
'ambiguous term' on purpose. I don't think 'isar-bootstrap' or
'bootstrap' is ambiguous in this context. Since generating an initial
root file system for linux distributions is called 'bootstrapping the
linux distribution' and that is exactly what is done here, so its not
ambiguous for me.

That debian has two methods of doing it also doesn't matter. Since that
is an implementation detail and can be easily looked up. The end result
is that we have some kind of minimal root file system that we can use
to install our customization on top.

> which may lead to potential confusing for Debian users?

"may lead to potential confusing" Is it or is it not? That sounds like
you are just making things up and spread FUD. It sound like "this code
could potentially cause your computer to catch fire and explode".

If I would have called something 'debootstrap' that formats your hard
drive, then yes, I see that this causes confusion and even more.

I don't see why a name like 'isar-bootstrap' or its containing task
'do_bootstrap' could confuse any Debian user that uses Isar. And even
if that "may lead to potential confusing" them, it will clear up fast
when they just take a look into the 'do_bootstrap' implementation.

Also, since Isar is a completely different Project than Debian, people
will have other expectations and might be positively surprised that
something with 'bootstrap' in its name still does what they have
expected it to do ;)

So then look at the whole question again and try to answer it:

> My question, why it's so important to use initially ambiguous term,
> which may lead to potential confusing for Debian users?

If I would nitpick then that isn't even a question, its a statement
that this is your question. Also, how am I supposed to answer it? (Hold
on, this us a rhetorical question and I don't expect an answer.)
The answer is obvious. Its like questioning:

    Why do you think it is right to kill everyone?

Maybe I should just reply to this questions and yours:

    That is not my intention.

I'm not sure that this is what you wanted to hear, but your question
can now be considered answered.

Since that is done now, I follow with my responses to some other parts
of your mail:

> It's not only about internal class names, this series introduces 
> 'do_bootstrap' task that is visible to user and will be a part of 
> documentation.

I don't expect many people building on top of isar-bootstrap, since
that is now pretty much the core internals of isar. People will build
their customization based on the output of isar-bootstrap, not isar-
bootstrap itself.

> If you use deboostrap, it's ok to name tasks/recipes/etc
> respectively (do_debootstrap, ...).

But in some cases it uses 'qemu-debootstrap' ;) (Nitpicky again, sorry)

Now we have a general name for all the bootstrap mechanisms
'do_bootstrap' and then if the need arise we can change 'do_bootstrap'
to some kind of 'virtual' task and have different implementations like
'do_bootstrap_deb_binary', 'do_bootstrap_deb_source', ... For now we
have one, because we only support one bootstrapping mechanism or
distribution. That is the reverse direction of your suggestion, but
this way we have some kind of meta-tasks names already, and changing it
later can be done more transparent.

> My position is simple: I read patches and if I've found something 
> unclear, I'm trying to understand what was the reason going this way.

That is a good position. And review generally really helps.
Here are some suggestions for me to improve the current situation.

First, please stay measured. Arguing a long time about minor things
like variable names, while there might be many other places in the
actual code that could be improved is not.

For instance I did like your suggestion to add '--homedir' to gpg, more
of that please.

In general more suggestions with measurable improvements and less
emotions like apprehensions about possibly confusing someone.

Second, please more 'trying to understand' instead of forcing your view
onto others via questions and or statements. Only after you understood
the view point of others you can really critique them. So ask questions
first (best in a neutral, open and honest way), after you understood
the developers view point and code you can make suggestions for
improvements while stating you objective reasons for it.
Also appreciating and praising good code occasionally will help a lot
spreading a positive and cooperative atmosphere in the project. :)

Maybe take a look at [1] and especially [2].

I left some parts of your message out, but I hope that I have made
myself implicitly clear how I stand on the other parts of your message.
If something is still unclear, then please ask.

Cheers,
Claudius

[1] https://mtlynch.io/human-code-reviews-1/
[2] https://mtlynch.io/human-code-reviews-2/

P.S. For me this kind of discussion now borders more on entertainment
than work and I don't think that this is a good sign. ;)

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net