I'm finding it really hard to frame answers usefully in terms of the questions you ask (and even more difficult with the alternative reframings proposed) So I'll talk for a bit about universal, and I'm sorry, but that's what you'll get at least until you ask for clarification. I think I'm more in favor of letting people pursue their goals than Martin came across as. Martin talked about having to sell your goal to everyone--almost as a gate to working on it. I want Debian to be a place where we can try new things, where we can find and embrace our technical passions. Every time I look at buildd.debian.org and notice that one of my packages built on m68k, I'm amazed. Someone cares enough to actually make that work and keep making it work. In some ways Debian burst my bubble about how cool computers were. Back in the day, different computers were different and had relatively different operating systems. You got to learn and love (and often enough hate too) all those different operating systems. Somewhere along the line I realized that Debian ran on most of the systems I would contemplate using. Why would I run something else? I liked Debian and if if I found I needed it to be different I could work toward that. It kind of burst the magic of all those different computers, because if they were all going to behave the same, I might as well buy what was cheap and fast. And yet m68k is also a great example that universality should have limits. If someone sent me an m68k patch I'd apply it if it actually increased overall portability and was not m68k specific. I might apply a patch to fix build flags for m68k. Beyond that, m68k is a hobby, and it's not worth any significant complexity in my packages today. I think things start out as something you're trying. You as the advocate (and others who like the idea) need to do the work. You're welcome to try and contribute it. As a community we should be generally pro trying things and find ways to help people out with their cool new stuff--sometimes even their hobbies--when we can. We should at least be responsive even if we're saying no. But we're not under an obligation--complexity, time to review, disagreement with the direction might all be reasons not to accept a contribution. As an example, I've looked at dgit. I use it sometimes. If someone came along and volunteered to re-upload all my packages with dgit I'd reject the idea, even if they did all the work. We get to a stage where enough people have integrated something that we as a community have experience to talk about how valuable it is. At this stage, it would be nice to figure out whether we're going forward or not. Some things will always just be hobbies. (I don't think m68k was back in the day; during its time I'd consider it a real port) Other things are things that we as a project want to support. If we cross that bar and are supporting things, the bar for rejections needs to be higher. Disagreeing with the goal is less likely to be a good reason to reject. More complexity is acceptable. Still, most of the time overriding people won't make sense. At the support level, you may not have an obligation to proactively avoid breaking something, but when the breakage is pointed out to you, you should work to review patches that fix it and constructively be involved in the discussion. If you have objections, that's fine, but you are hopefully working to find approaches that would work around your objections even if you're not doing the implementation of that approach. Not being able to find such an approach is a good sign you might need some outside input about whether your objection balances the project's tradeoffs well. Some things reach the level where we're not just supportive of the effort but it is a goal. You never have an obligation to do work in Debian, but once things reach the goal level, there may be consequences for not doing work. You are more likely to be overridden; you might not be the appropriate maintainer for a package. There are probably a couple of levels within the support category that could be teased apart. Of course this is all a rough spectrum that exists only in my head. The biggest problem here is that there's no way to figure out where we are along that spectrum for any given aspect of universality. We don't actually make decisions; it just sort of happens for the most part. That's good in some ways. It has a couple of significant negative consequences though. You don't know where you stand. You don't know how much support you can expect. When you aren't getting support you don't know if that's reasonable or not. As someone considering giving support you can feel roped in in ways that don't feel good. This is another case where actually having an answer might be good even if it is not the answer you want. In the hard cases like init systems and some architecture decisions, I don't know that I know how to make the decisions about where we are on the spectrum. I do think the tools I outline in my platform have a good chance of moving us forward on things like workflow and packaging uniformity. Once we have some success there, I'd be happy to talk about whether we learned something that can help us in more difficult situations. Put another way, I think I'm good at helping make decisions. I do not commit the hubris of claiming that I could have made init systems easier. --Sam
Attachment:
signature.asc
Description: PGP signature