Ok, now that all the administrivia is out of the way (we have a chairman, and we'll soon have the list being archived properly), it's time to focus on the proposal.. er.. many proposals which have been presented to the committee about this FSSTND -> FHS migration issue.
[Aside: the issue of how to migrate from FSSTND -> FHS is a technical policy issue, and so is within our scope.] First off, we have a request by Wichert to choose one of the various proposals which have been made on debian-policy. Also, we have proposals by Manoj, Ian, and Chris Waters which I'm going to take as distillations of the discussion which has taken place on debian policy. Since I'm supposed to be charing this discussion, and I wanted to make sure I'm doing this right, I started to conduct a personal review of the debian-policy discussion -- to see where things stand. (*) debian policy 3.0.0.0 was ratified (which specifies the use of FHS in place of FSSTND) but it did not address how to manage the migration between the two standards. The implication is that all packages which have not yet made the migration are now non-compliant with policy. This seems to me to be fundamentally wrong -- policy should never have been ratified which says that every existing package violates policy. Policy should typically represent the best of existing practice.. So I went to look at what the constitution said about such policy. What I found surprised me: According to the constitution, the developers do not have the power to set technical policy. This means that technically all work done by the debian-policy group other than "documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software license terms that Debian software must meet." are in some sense unconstitutional. [[I think this was what has been upsetting Manoj so much..]] However, the debian policy folks have been putting a lot of work into formulating good policy. Also, it's *not* the job of the technical committee to formulate [technical] policy -- we're just supposed to be the first decision point for ratifying policy [once we've made up our minds the developers get to overrule us if enough think we've decided wrongly.] [[In the past, I've held the position that the debian-policy list has the same authority as an individual developer: they're the package maintainers for debian-policy, so they have considerable latitude in making decisions about what goes in the debian-policy package. However, declaring that existing packages are buggy clearly overlaps with the authority of other developers which puts it squarely in our laps.]] In general, I'd like to recommend that we ratify all decisions made by the debian policy group on technical policy, as long as those policies don't declare existing packages which were compliant with previous policy versions to be non-compliant with policy. I expect we'll discuss this further, shortly. Ok, back to my review of the debian-policy discussion: It turns out that there are packages which refer to the contents of /usr/doc/, examples include xfig (which refers to its own /usr/doc/ entries) and dwww (which refers to the entire hierarchy. [Also, there may be userland programs which refer to /usr/doc/ -- but I didn't see any discussion of this when I was skimming over the policy discussions.] ====================================================================== Aside: we are responsible for deciding on technical policy. By not electing a chairman earlier, and by not issuing any advice to the policy folks we've allowed this situation to develop. So while the policy group has made some mistakes here, so have we. This is important to keep in mind when thinking about how to react to this situation... I think that from this viewpoint the situation is very clear: (*) inappropriate policy has been issued. (*) a number of packages have been modified to comply with this policy. (*) "existing practice" now includes this state of affairs. ====================================================================== Because this point of view is so radically different from what I held earlier, I'm going to leave this issue open for discussion at least until tomorrow (that is: I'm not drawing up the ballot quite yet). I want to make sure I've not made some incredibly stupid mistake before we vote on this. However, at the moment, I'm inclined to put the following options on the ballot: (1) reject the current 3.X policy, pending further discussion. (2) ratify the current 3.X policy. (3) ratify the current 3.X policy but declare that /usr/doc/ shall continue to be used in place of the FHS mandated /usr/share/doc/. (4) ratify the current 3.x policy but declare that /usr/doc/ may be used in place of the FHS mandated /usr/share/doc/ (at the developer's option). (5) ratify the current 3.x policy as in (4) above with the additional requirement that all packages must be modified so that they provide a symbolic link so that their contents can be accessed from either /usr/doc OR /usr/share/doc. Note that (5) carries with it the same flaw that 3.0.0.0 originally had: it declares that every existing package is buggy. Note that (4) is pretty close to the status quo (doesn't declare any packages buggy), but doesn't really address any of the technical issues. While (3) has a certain esthetic appeal, I don't know if there are other migration issues lurking out there. If we go with (1) instead of (3) we have a sort of moral obligation to review the policy for other flaws and get it off our plates as fast as possible. Of course, if we go with (2), then we're effectively declaring that most existing packages violate policy. ====================================================================== Final notes: (1) is essentially Ian's proposal -- and yes, I'd include the other details from his proposal on the ballot. (5) is essentially Manoj's proposal and I'd include the details from his proposal as well for that item. (3) represents Chris's proposal. (2) and (4) represent two distinct interpretations of the "take no action" concept which several people have mentioned. As chairman, I don't get to declare which of these is the best decision. And, I might have even made some major blunders in my analysis of this situation. However, I do feel that we have an obligation to decide fairly quickly on this issue.. Comments? -- Raul
