Transparency in package update/maintenance policy in the TO repo

[anon50890781]

Taken from this forum thread

@cynerd

Updating packages is our priority but we can’t update everything and there are packages with higher priority and packages with lower priority. If you want to bump some package version then you can do it, test it and then send us patch (for testing compilation you can either use Turris Documentation or Files · master · Turris / myrepo · GitLab). You can also create issue on gitlab or github just to tell us that given packages has newer version, but that doesn’t ensures quick update.

At the moment wireguard is somewhat up to date, at least it has version that is compatible with latest version. If it wouldn’t be then I would bump it on my own us I am using it.

it raised some general questions for me:

1. 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?
2. Where is a transparent list of packages that cannot be updated?
3. How transparent for the user is the process of prioritising package updates and is there a priority list published for the user’s awareness?
4. What does ensure a quick update, short of the user submitting a patch, if creating an issue on gitlab/github does not?
5. 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?

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

[anon50890781]

@cynerd as always thank you for the response.

Just 2 people for maintaining such large repo seems a bit thin and may cause a drop in customer satisfaction. As described the current state of update policy leaves sort of curious impression.

Is my understanding correct that TO 4 is then vanilla OpenWRT with TO patches/packages (like Forris) as sugar coating on top? And thus all other packages are maintained at OpenWRT and not anymore at TO with 2 people?

[cynerd]

@anon50890781

Is my understanding correct that TO 4 is then vanilla OpenWRT with TO patches/packages (like Forris) as sugar coating on top? And thus all other packages are maintained at OpenWRT and not anymore at TO with 2 people?

You can say it that way. Yes Turris OS 4.0 is primarily upstream OpenWRT with few patches and our packages. So yes all packages (except of those added on top of OpenWRT) are maintained by upstream.

[anon50890781]

Is it feasible as of today to install OpenWRT and get the TO packages, say by adding the TO feeds, assuming that the TO packages are not hosted with OpenWRT?

[cynerd]

No they are in separate feed. But no it’s not feasible at the moment. We have some test builds but stuff are still broken. We have to fix our packages first.