Sorry, I wanted to be constructive:IMO, if a maintainer of a package isn't sure how to address a policy request, I believe the best response is to reject/park the issue, pending a separate discussion and adding of the needed details to policy (or appendices etc).
The reason I feel this way, is that when an implementation detail isn't pushed into policy, the debate happens more than once, and often with differing loud results (based on opinions of those awake at the time).
if policy isn't clear enough, make the process require fixing the documentation, rather than allowing having debian-mentors etc re-debate in an adhoc and lossy way.
Sven On 02/07/12 23:37, Sven Dowideit wrote:
On 02/07/12 12:53, Russ Allbery wrote:y, instead they all volunteer to pontificate on details that come due to the lack of detail - like where to put the ssh keys.Sven Dowideit<SvenDowideit@home.org.au> writes:On 02/07/12 02:03, Marc Haber wrote:I am really really astonished about with which ease we hurl RC bugs at packages without having thought-out alternatives.Would it not be better to reject the Debian QA 'suggestion' until such time as its documented thoroughly in the Packaging manual?Not using /home is already documented in Debian Policy. Marc quoted the relevant excerpt in his original message. It would indeed be best if everything possible was documented, but veryfew people volunteer to do the work to drive changes to the documentationthrough to completion.ie, having the doc say 'don't use /home' without addressing common reasons for wanting to use /home in that doc is the problem. (And I'd consider them a blocker for putting such a statement in the doc.but as i said, I declined to do more because dealing with the details meant that every year someone would demand that I undo something i was demanded to do the year before. (The policy on complicated self-modifying web apps is pretty much non-existant)Sven