Re: [ANNOUNCE] Upcoming ISAR release

[Claudius Heine <claudius.heine.ext@siemens.com>]

Hi Maxim,

On 18/02/2019 11.29, Maxim Yu. Osipov wrote:
> Hi Claudius,
> 
> Thanks for the feedback.
> 
> OK, let's focus for v0.7 release for now.
> 
> On 2/18/19 10:58 AM, Claudius Heine wrote:
>> Hi Maxim,
>>
>> On 18/02/2019 10.01, Maxim Yu. Osipov wrote:
>>> Hello everybody,
>>>
>>> Last release (v0.6) was made on 1st of October 2018.
>>>
>>> We plan to release the next version of ISAR on 1st of March, 2019.
>>>
>>> BTW, what do you think about making a 1.0 release?
>>
>> IMO we need a lot more cleanup stuff before we can do a solid 1.0 
>> release.
>>
>> We should make a list of issues that should be done before 1.0 release.
>>
>> Here is a suggested checklist before 1.0:
>>
>>   - Remove jessie support
> 
> That's a point which I don't understand - yes, we don't support jessie 
> as a host system, but why don't continue to support jessie based targets 
> if this doesn't require big efforts?

Well IMO it does require effort as shown with the unavailable `-d` 
parameter in mkfs.ext4. For image creation not the build machine tools 
should be used but those of the host (or what you call target), which 
should then be >=stretch. The image creation tools might have patches 
applied to them.

> Industrial programming is very 
> conservative in this point (that's why all these 
> https://www.cip-project.org/ serve for).

That has nothing to do with this. linux-cip is a project to support 
kernel versions for ~25 years. AFAIK nobody does that for the userspace.

> 
>>   - Improve documentation
>>   - Cleanup the user interface variables
>>     - Consistent variable nameing style
> 
> naming ;)
> 
>>     - Use feature variables instead of many VAR="1" ones. They can be 
>> more easily bundled together in code and docs.
> 
> I vaguely remember this discussion.
> Could you please provide arguments why we will benefit from that?

  - fewer variables to remember, which lead to
    - easier to document
    - better learning curve
    - better UX
  - Features are easier to work with, because
    - single place in 'bitbake -e' where they are condensed
    - easy to read names, because variable names need to have some 
additional 'namespace information'
  - Similar to OE, which lead to
    - easier switch for OE people to and from Isar
    - easier to compare feature set of OE and Isar
...


>>   - Consistent and clear naming of things
>>     - Build, host, target in line with GCC and Debian definition
> 
> Could this renaming confuse current Isar users?

This is much more confusing IMO:

     meta/recipes-devtools/buildchroot/files/common.sh
     26:    set_arch="--host-arch $target_arch"

Of course that will confuse current Isar users, but IMO current Isar 
users are used to be confused most of the time they work with Isar 
anyway ;) You have to take care not to confuse new users, since that is 
the critical period where you really want to make it easy for them.

We will need to break this at some point, better do it before 1.0.

> 
>>     - meta, meta-isar -> either meta and meta-example or meta-isar and 
>> meta-isar-example. Currently 'meta-isar' sounds like it is required.
>>   - Clearly defined task pipeline for all recipe types
>>     - no more do_build with stuff in it, that should be treated a the 
>> default target not some real one
>>     - dpkg_runbuild should be a task with postfunc and prefunc 
>> attributes to wrap mounts around it
>>   - Cleanup meta-isar layer to show best practices of using isar
>>     - multiconfig should not contain other variables than DISTRO and 
>> MACHINE

Here some more:

- IMAGE_INSTALL should not add itself to DEPENDS, that breaks recipes 
that produce more than one Debian package
- support of IMAGE_TYPE with more than just one image type (IMAGE_TYPES)

I still expect more of those...

>>
>> I am sure I will find a lot more of those if I think a bit harder 
>> about it. All of those issues makes adopting Isar for new, OE or 
>> Debian people alike very difficult. With the 1.0 we should try to 
>> bring Isar to a level were we don't expect many breaking changes on 
>> the next 1.1 release.
>>
>>> At the moment I'm busy with testing/applying pending patches, I plan 
>>> to finish this activity in a couple of days and make a first release 
>>> candidate and code freeze (only bug fixes will be applied in the 
>>> 'next') after that.
>>
>> Shouldn't we open a release staging branch for that, so that feature 
>> submissions can continue to next?
> 
> Does it makes sense for now with the release cycle taking one week?

If you think that works, then ok. Personally I don't really care about 
the releases <1.0 since they get old rather quickly, but I don't want to 
stop the progress, since there is so much still to do in Isar.

regards,
Claudius

-- 
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