[Was: Re: Firmware Selector Setup]

[Paul Spooren]

On Mon Sep 14, 2020 at 9:35 AM HST, Moritz Warning wrote:
> On 9/14/20 9:15 PM, Paul Spooren wrote:
> > Hi,
> >
> > On Mon Sep 14, 2020 at 8:41 AM HST, Baptiste Jonglez wrote:
> >> Hi,
> >>
> >> Congrats, great work!
> >
> > Yea congrats from me too, great work Moritz and Petr!
> >
> >>
> >> Here is some feedback on the staging version:
> >>
> >> - the latest stable release should probably be the default (currently,
> >> snapshots is the default)
> >
> > Yes I agree, tht should be changeable in config.js:
> > https://gitlab.com/ynezz/openwrt-firmware-selector/-/blob/master/www/config.js
> The problem here is that the entries are written by a script. And the
> script does not care for the order.
> Maybe we need a "default_version": "snapshot" setting..

Please implement a `default_version` for now so people don't default to
instable snapshots.

Long term I'd rather use a *upstream provided* versions.json file (which
I mentioned in another email) to offer correct ordering and also
additional information. For example, when selecting 18.06.x, the wizard
should show an information that EOL is near.

>
> >
> >>
> >> - the date is the same for all models, even for 19.07.4 images: "Mon, 14
> >> Sep 2020 10:14:12 GMT". I'm not sure what this date is supposed to
> >> mean.
> >>
> >
> > Moritz is his PR still your favorite approach?
> > https://github.com/mwarning/yet-another-firmware-selector/pull/55
> I am still conflicted. :-)
> A model has different images (factory, sysupgrade, ..), but we show only
> one date per model.
> We could show the latest creation date of those images or the date when
> the target/profiles.json was last modified (done in the PR).
>

I think the last modified date of target/profiles.json is fine, I'd say
an entire release is fine to have the same date. It's meant to give give
users an idea if the files are *old* (e.g. 18 month) or if the currently
running release snapshot is the same as provided upstream (they are
build weekly iirc). It shouldn't be used for a hour/minute/second based
comparison.

> >
> >> - is it possible to add 18.06?
> >
> > From my understanding, no. JSON support was only added to 19.07. We
> > could manually backport the patches oot and build once all targets just
> > to receive the profile.json files. Then we would have to update all
> > containing checksum inside the profiles, as many images are not yet
> > reproducible. Maybe a bit to much work?
> We do not need the checksum, since we do not display any checksum.
> Anyway, that single json patch should apply without problems and should
> suffice.
>
> >
> >>
> >> Regarding 18.06, here is a use-case: I would like to search for a model,
> >> and then it would give me the latest stable version for it (18.06 or
> >> 19.07). A bit like https://openwrt.org/toh/start
> >>
> >> Currently, when I search "WR841", it only gives me TL-WR841N v13 because
> >> the earlier models are no longer built for 19.07. It would be nice to
> >> show the other models; that is, propose 18.06 as a fallback when 19.07
> >> is
> >> not supported.
> >>
> >> If this is not straightforward to implement, this could be added to a
> >> later version of YAFS: the current version is already good!
> >>
> >> Thanks,
> >> Baptiste
> >>
> >> On 14-09-20, Moritz Warning wrote:
> >>> Hi Petr and everybody else,
> >>>
> >>> thank you very much in making this possible!
> >>> I think this will be a significant step forwards in end user usability.
> >>>
> >>> On 9/14/20 12:36 PM, Petr Štetiar wrote:
> >>>> Moritz Warning <moritzwarning at web.de> [2020-08-01 02:13:05]:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> we have reached the point that we can finally set up the firmware selector [0]. Yay!
> >>>>> But somebody need to finally put it on the website...
> >>>>
> >>>> so https://firmware-selector.staging.openwrt.org is alive, deployed
> >>>> automatically from CI pipeline[1]. Any push into master branch deploys site at
> >>>> firmware-selector.staging.o.o (once all CI tests pass). Then after additional
> >>>> QA steps done usually by humans it's possible to manually trigger another CI
> >>>> pipeline which is going to deploy the site at production URL
> >>>> firmware-selector.openwrt.org.
> >>>>
> >>>> Next steps:
> >>>>
> >>>>  - fix the `web` group/repo name clash on GitLab.com/openwrt and setup mirroring and
> >>>>    CI/CD deployment from GitLab.com/openwrt/web/firmware-selector-openwrt-org.git
> >>>>  - fix remaining issues (if any) on staging and make the site officialy alive
> >>>>    on firmware-selector.openwrt.org
> >>>>
> >>>> I plan to tackle these in the upcoming days.
> >>>>
> >>>> 1. https://gitlab.com/ynezz/openwrt-firmware-selector/-/pipelines/189588455
> >>> Let me know if I can help.
> >>>
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Petr
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> openwrt-adm mailing list
> >>> openwrt-adm at lists.openwrt.org
> >>> https://lists.openwrt.org/mailman/listinfo/openwrt-adm
> >