Patrice Dumas wrote:
You cannot say that for packagers. Packagers may be interested in thatwork. 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 upstreamspotentially 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