Re: Policy progress
On Tue, 02 Sep 2003 19:36:11 +0200, Stefan Gybas <sgybas@debian.org> said:
> Josip Rodin wrote:
>> Sorry, I lost you there. Is that to make us believe FHS transition
>> was proper or improper, necessary or unnecessary, or what? :)
> No, I only wanted to show that it has been impossible the get major
> Policy changes accepted in the past 4 years. It's not that there
> haven't been any innovative proposals (mostly on debian-devel), it's
> just that you get an objection if you propose more than a
> clarification or an addition to the list of virtual packages. In
> most cases the submitter of the proposal loses interest in other
> proposals (or his whole Debian work) after getting a lot of
> objections.
I would not want this to change. Anyone can make innovative
proposals, but the hard part is getting things to work -- and just
doing it. Debhelper, debconf, the whole testing distribution -- were
all proposed, and worked on, without first getting policy to bless
them.
> This means that the only innovation in Debian in the past 4 years
> has been more packages (or newer versions) and more
> architectures.
I see. debconf, debhelper, testing, the whole new bts system
-- not innovative, just because they do not fit into your theory?
> Improving the init scripts to at least catch up with other major
> distributions (status option, exit codes, chkconfig, colored output
> on supported consoles, ...) is less work than e.g. adding another
> architecture -- but it requires consensus among developers. When a
Right. Actually, it only needs buy in from a majority of
the people who do the work -- hte rest do not really count; which is
as it should be.
> package does not build on a new architecture you can file an RC bug
> and the maintainer has to fix it (or you can NMU). But you can't do
> this for new features unless Policy prescribes them. So if Policy
> only documents common practice, we are stuck.
I see. Unless we can use policy to beat developers on the head
with RC bugs, we are stuck. (Never mind that RC bugs are not
determined by policy, but hey).
> Therefore I suggest to accept changes to the Policy even if this
> means that some packages suddenly violate the Policy. This of course
> only makes sense when the required infrastructure (e.g. a features
> in dpkg) is already there and the proposed change has proven to work
> correctly in other packages (reference implementation).
I think this is a stunningly bad idea, for reasons I have
already extolled.
>> Probably only if you file bugs without any rationale. If not, those
>> maintainers need some attitude readjustment.
> Ok, let's test this: I'll file 10 bug reports with example code and
> explanation against packages with init scripts that use
> start-stop-daemon asking the maintainer to add the status option and
> adjust the return code according to the current proposal. I really
> fear that I will not be very successful unless this becomes part of
> the Policy, even if I submit patches. But we'll see...
Well, if you cannot convince the people who do the work, no,
it shall not get done. If the idea is so good, why would it be so
hard to convince the developers who maintain the packages that it is
a good idea?
manoj
--
Feel free to contact me (flames about my english and the useless of
this driver will be redirected to /dev/null, oh no, it's
full...). Michael Beck, describing the PC-speaker sound device
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: