Transparency in package update/maintenance policy in the TO repo

[cynerd]

@anon50890781

if not eveything can be updated than why carry packages in the TO repo that cannot be updated in the first place, what is the point?

Point is that someone might want to use it and it’s more work to drop them then just have them. Not talking about case where users are already using them and we would removed them. Not good.

@anon50890781

Where is a transparent list of packages that cannot be updated?

There is no such list. And there is no package that cannot be updated. There are just packages that are not updated without any intention.

@anon50890781

How transparent for the user is the process of prioritising package updates and is there a priority list published for the user’s awareness?

All packages that are part of lists (packages that are automatically installed when list is added trough Foris) are updated on regular bases.

@anon50890781

What does ensure a quick update, short of the user submitting a patch, if creating an issue on gitlab/github does not?

Submitting patch? Look we have two people maintaining few thousands packages. Every update has to be checked, verified and tested. If you give them less work to do to update package then they will do it faster. If you don’t provide any patch then they will just move to other more important package. If you notify us that there is new version of dnsmasq then be sure that we will update it. If you notify us that there is new version of mc then it’s most probable that update will happen in months not in days. It really depends on package to package bases.

@anon50890781

a package used by one of the TO team members gets higher attention/update priority than one not being used by one of the TO team members?

No they doesn’t. At least they don’t sort of. If something that I am using breaks then I will create patch and because I have right to repository I will patch it immediately. But I am not a package maintainer. It’s just faster for me to patch it directly but if you as user do the same then only thing you have to do on top of me is to submit merge request. If you test compilation (we really hate pull requests that were not even tested if they have valid syntax) then there is no limitation in getting it to next minor or fixup release (depending if it’s major or minor version change of package).

Also please understand that current state is just temporally. Our fork is unmaintainable in long run. We know that and at the moment it’s more or less in just lts where we try to update only our software and security fixups. In parallel we are working on Turris OS 4.0 that is based on planed OpenWRT 18.5. We can’t promise migration date but be sure that all software versions will be almost one to one to OpenWRT with 4.0.