Patrice Dumas wrote:
You cannot say that for packagers. Packagers may be interested in that
work. If we forbid new init systems we prevent interested people to do
the job.
Are you suggesting that all packagers would be interested in providing
alternative versions of the required init scripts for all different init
scripts systems?
Why? If people are interested, they will make it scale.
The problem happens when people are not interested. We would end up
having init script systems which don't work properly because the
packages dont provide init scripts except for the default init script
system. When end users find more such packages in the repository (which
do not know is experimental), the level of trust on the quality of the
repository goes down. More choices without proper integration and
testing is bad.
The question here is: What do you propose to guarantee better
integration for all the different init scripts?
The critical difference between a package like the window manager and
alternative init systems is that with window managers integration is
centralized and can be done via proper generation of menus within the
package itself.
With init systems, thousands of packages have to provide alternative
versions of all their init scripts.
We have to
accept new stuff, otherwise it won't get off. For example, for init
systems, if we say 'this system is too new, it needs new init
files/scripts' it will never get in because packagers and upstreams
potentially interested will say 'this system is not packaged it is
a waste of time to get interested in it'.
If the goal here is just to experiment and ultimately find the "optimal"
init system (within the constraints that nothing is optimal for
everyone), the solution there is provide the alternative init system
only for the development branch which helps packagers integrate with it
and testers test it and provide feedback while not disrupting the end
users and then only provide a single init system for the stable branches.
> Let the new init systems packagers decide (as a community) when they
can put new init systems in stable release, just like for normal
components. If contributors cannot be trusted, things are wrong anyway.
Trust is not a black and white thing. Neither it is always a question of
trust. If we can trust everyone we don't require ACL's in any packages.
We have several cross checks in place, processes and guidelines
precisely because we *cannot* trust all contributors all the time. As we
scale to more contributors expect such processes to *increase*.
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
