Re: [ANNOUNCE] Upcoming ISAR release

[Henning Schild <henning.schild@siemens.com>]

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
>