[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Making Debian ports less burdensome




I would have thought porters would be following the buildd/piuparts/CI
pages for their port (where available) and thus would not need to be
notified about arch-specific FTBFS or testing issues. If porters are
relying on package maintainers or some automation to notify them
instead of being pro-active about builds and testing, that isn't going
to produce a high-quality port.

There is a tool for checking uninstallable and out of date packages already:
The problem with the current tools is they don't do a good job of:

1: seperating out port specific issues verses general issues.
2: seperating out issues with packages that actually matter* verses low popcon leaf packages that could be removed with minimal impact. 3: seperating out very new issues verses older issues without bug reports verses issues that are already being actively discussed verses stale issues with bug reports but no patches verses stale issues with bug reports and patches. 4: linking the automatic detection of an issue to the bug report on the issue (afaik the dose pages have no mechanism for this, the buildd pages have "failing reasons" but they are little used because only buildd admins can set them). Also linking together reports of essentially the same issue from multiple sources (i.e. package is uninstallable *because* it failed to rebuild for a transition). 5: in the dose case seperating out arch specific packages (which are not allowed to be uninstallable) from arch all packages (which are allowed to be uninstallable), it is indicated in the list with an [all] tag but spotting the handful of uninstallable arch specific packages in the much larger list of uninstallable arch all packages for testing isn't easy (for unstable the information is even less useful because of the massive ammount of entries that have nothing to do with ports). 6: indicating issues that are both blocking transitions (so need to be dealt with urgently) and are specific to a handful of architectures.

Improving the existing tools might help with some of the issues but I can see advantages in a porter-focussed tool that collects information from multiple sources.

* Exactly where to draw the line on "actually matter" is potentially a subject of some debate.


Reply to: