Re: [PATCH v4 1/5] implement isar-bootstrap using debootstrap

[Alexander Smirnov <asmirnov@ilbers.de>]

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.

Alex

>  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. ;)
>