On 2018-03-16 06:49, Alexander Smirnov wrote:
> On 03/16/2018 01:07 AM, Claudius Heine wrote:
>> 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.
> 
> Have you tried to do this also?
> 
> 1. Isar is oriented to *Debian* community, yes, it's stand-alone
> project, but the main focus is Debian users and Debian infrastructure.
> This is not my IMO, this is the fact of this project. Everything we do
> should comply with Debian terms and philosophy.
> 
> 2. Debian bootstrapping (building from zero) is well-known problem in
> Debian community, which still has no complete solution. AFAIK this work
> is done manually. A dedicated project was started - rebootstrap, but
> it's still under development.
> 
> 3. I consider Debian bootstrapping as a possible Isar feature after
> adding cross-compilation. This bootstrapping has nothing common with
> calling debootstrap.
> 
> These bullets are the source of my concerns. So I proposed to rename the
> things because I realized that such change takes just a few minutes. But
> due to this topic becomes more complicated, I'd like to close this
> discussion for now.
> 
>>  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),
> 
> Reading some of your previous mails I wonder what you mean here.
> Especially reading this statement after your comments written above
> sounds like a kind of double standards. Stopped reading here.
> 

I hope this discussion is not blocking the progress of this important
feature.

Just the make it clear that naming is be far not as clear as it was put
here:

"Package: debootstrap
Bootstrap a basic Debian system"

"Package: cdebootstrap
Bootstrap a Debian system"

"Package: multistrap
multiple repository bootstrap based on apt"

So let's call this thing by its commonly used Debian name, bootstrap,
and move on to more important topics.

I'd really like to see the debootstrap migration finalized and merged,
specifically as I need some cross-buildchroot on top of it.

Thanks,
Jan