[ANNOUNCE] Upcoming ISAR release

[ANNOUNCE] Upcoming ISAR release

[Maxim Yu. Osipov]

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?

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.

I'll submit later Changelog describing major changes since the last 
release and sort out the issues present on the project's wiki.

Please inform me about any open issues that may be a subject to postpone 
a release.

Thanks,
Maxim.
-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: [ANNOUNCE] Upcoming ISAR release

[Claudius Heine]

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
  - Improve documentation
  - Cleanup the user interface variables
    - Consistent variable nameing style
    - Use feature variables instead of many VAR="1" ones. They can be 
more easily bundled together in code and docs.
  - Consistent and clear naming of things
    - Build, host, target in line with GCC and Debian definition
    - 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

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?

Cheers,
Claudius

> I'll submit later Changelog describing major changes since the last 
> release and sort out the issues present on the project's wiki.
> 
> Please inform me about any open issues that may be a subject to postpone 
> a release.



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

Re: [ANNOUNCE] Upcoming ISAR release

[Maxim Yu. Osipov]

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

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


>   - Consistent and clear naming of things
>     - Build, host, target in line with GCC and Debian definition

Could this renaming confuse current Isar users?

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

Thanks,
Maxim.



> 
> Cheers,
> Claudius
> 
>> I'll submit later Changelog describing major changes since the last 
>> release and sort out the issues present on the project's wiki.
>>
>> Please inform me about any open issues that may be a subject to 
>> postpone a release.
> 
> 
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: [ANNOUNCE] Upcoming ISAR release

[Claudius Heine]

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

Re: [ANNOUNCE] Upcoming ISAR release

[Henning Schild]

Am Mon, 18 Feb 2019 12:52:18 +0100
schrieb "[ext] 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"

I was about to cite exactly that statement ;). We either confuse a few
people using cross on Isar, or everybody else. Debian did not invent
the naming either but that seems a natural choice to align with.

That is a TODO i never finished. It was never meant to be merged but to
raise attention.
https://groups.google.com/forum/#!topic/isar-users/QU10HPRVlFc

Henning


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

Re: [ANNOUNCE] Upcoming ISAR release

[Jan Kiszka]

On 18.02.19 12:52, [ext] Claudius Heine wrote:
>>>
>>>   - 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.

Jessie might be nice from testing perspective, but only when it's not making 
life too hard for moving on. Practically, it plays no role in the field, simply 
because everyone started on Stretch as Isar was not usable at the time jessie 
was the latest version.

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

Not quite: Kernel and a set of Debian core packages (we are still shaping the 
latter set) will be maintained for 10 (ten) years. There will soon be an 
official Isar layer encoding that package set (it's currently only in 
https://gitlab.com/cip-playground/isar-cip-core).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [ANNOUNCE] Upcoming ISAR release

[Henning Schild]

Am Mon, 18 Feb 2019 10:01:09 +0100
schrieb "Maxim Yu. Osipov" <mosipov@ilbers.de>:

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

A 1.0 is a good idea, but my personal feeling is that we are not there
yet. There are still a lot of minor issues and at the same time we are
gaining important features.

Henning

> 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.
> 
> I'll submit later Changelog describing major changes since the last 
> release and sort out the issues present on the project's wiki.
> 
> Please inform me about any open issues that may be a subject to
> postpone a release.
> 
> Thanks,
> Maxim.

Re: [ANNOUNCE] Upcoming ISAR release

[Jan Kiszka]

On 18.02.19 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?

At least reproducible build should be solved for that. I think we have currently 
three open issues in that area:

  - switching between cached and non-cached builds on the fly
  - cache unconditionally (make related task implicit)
  - cache source package (re-)builds

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [ANNOUNCE] Upcoming ISAR release

[cedric_hombourger]

[-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --]

I agree that reproducible builds should be on the list.
I have a patch to the dpkg-raw class which I will submit shortly to avoid 
getting a new timestamp in debian/changelog with every build

In other words, there are two parallel tracks / work-packages towards 
reproducible builds (at least that I see):

(1) get fixed content from designated upstream sources (ie what is being 
delineated below)
(2) identify and fix areas where Isar is generating/building content in a 
non reproducible way

It would be really nice if we could come up with some tooling to report 
differences between two Isar builds (obviously leveraging tools used by the 
Debian project such as diffoscope)

Cedric

On Monday, February 18, 2019 at 11:25:06 AM UTC+1, Jan Kiszka wrote:
>
> On 18.02.19 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? 
>
> At least reproducible build should be solved for that. I think we have 
> currently 
> three open issues in that area: 
>
>   - switching between cached and non-cached builds on the fly 
>   - cache unconditionally (make related task implicit) 
>   - cache source package (re-)builds 
>
> Jan 
>
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE 
> Corporate Competence Center Embedded Linux 
>

[-- Attachment #1.2: Type: text/html, Size: 1777 bytes --]