On Mon, 2014-06-30 at 11:29 +0000, hasufell wrote: > > I agree that masking for testing is like having a 3rd branch, but I'm > > not convinced that this is a bad thing. > > I have to reiterate: > * increases the workload, because we are effectively running 3 branches > * decreases the amount of testing for that time period, because... it's > masked > * causes confusion (see this thread)
A branch is is supposed to be internally consistent: for any X and Y, the latest version of X from a given branch is in theory compatible with the latest version of Y from the same branch. If they are not compatible, there should be a bug that somebody is actively working on resolving, or a blocker dependency, and such blockers ought to be relatively rare to make things easy for human minds and package managers. Masked packages are not a third branch. Some packages are hardmasked for being untested, some for impossible-to-fix bugs, some are known to break a reverse dependency and are waiting for that reverse dependency to be updated, some are lastrited for removal in 30 days. There is absolutely no expectation that all masked packages are compatible with each other. > * decreases the quality of our stable branch, because people suddenly > expect the unstable branch to be ...stable and don't bother with filing > stabilization requests anymore Stablereq for wine-1.6.2 was filed in February. It got stabilized on amd64 exactly 4 months later. Security stablereq for freetype-2.5.3-r1 was filed in March for all arches. Thus far, only hppa and ia64 stabilized it. People don't bother with filing stabilization requests because they realize that arch teams usually have a long backlog of existing requests, and might take weeks/months to get to your new request. Especially if your new request depends on other stablereqs.
signature.asc
Description: This is a digitally signed message part
