Getting multiarch dpkg into Debian
Getting multiarch dpkg into Debian
Posted Mar 6, 2012 23:19 UTC (Tue) by rahvin (guest, #16953)In reply to: Getting multiarch dpkg into Debian by bug1
Parent article: Getting multiarch dpkg into Debian
Second, managing a process and people involved in that process is HARD even in commercial environments where you can tell someone what they should work on. It's even harder in environments where you can't tell someone what to do because they are a volunteer.
The package maintainer was right to want stability in dpkg and the technical committee was also right to want to move the code forward as it's a critical part of MultiArch. So if they are both right the trick is to bring about a solution that recognizes that and works with the process, that's HARD. As the article says the tech committee issued an ultimatum so the package maintainer made time for the review and got the patch merged. The process worked and in particular worked on a project with true democratic control and a mostly volunteer workforce. To me that's a direct indication of the dedications of the Debian maintainers. I think the only possibly negative thing this really indicates is that Guillem needs some more help (or needs to trust his helpers more) but DPKG is one of the most critical pieces of the Debian toolchain so I understand his caution.
Posted Mar 7, 2012 11:11 UTC (Wed)
by pboddie (guest, #50784)
[Link] (1 responses)
I think that the general point here is that in projects people need to be able to ask for help, and people must be willing to offer help. Again, in general, good management is about bringing these things together, whereas bad management (as many of us are unfortunately all too aware) often involves someone thinking that their job is merely to tell you what to do, frequently not contributing to the activity in any way other than to indicate that things must be done more quickly, as opposed to helping you get your work done by giving you what you need.
Posted Mar 12, 2012 10:00 UTC (Mon)
by man_ls (guest, #15091)
[Link]
Posted Mar 8, 2012 2:05 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link]
The underlying problem is that the standard procedure doesn't give any kind of deadline for the package maintainer to respond. That's reasonable because there really isn't a one-size-fits-all response interval, but it means there's a danger that something will be put on the back burner and never taken off because the maintainer always sees something else as a higher priority. That seems to have been what happened in this case, and it wasn't until the technical committee gave him a firm deadline that he bumped the priority enough to do the review.
The big question is whether there needs to be some general procedure for dealing with this kind of problem, or whether ad hoc solutions will work. This is a rare case where the package is on the critical release path for the whole project, so the technical committee really had to step in. But what happens when it's on a less important project that isn't going to hold up the whole release? Can a maintainer put off changes indefinitely because he wants to review everything and doesn't have time to do it? Does there need to be some kind of general process to generate a definitive answer for changes that have been delayed?
Getting multiarch dpkg into Debian
I think the only possibly negative thing this really indicates is that Guillem needs some more help (or needs to trust his helpers more)
May I nominate this comment for distribution quote of the week?
Getting multiarch dpkg into Debian
Getting multiarch dpkg into Debian
The package maintainer just wanted time to review the code to ensure it met the standards for a package that basically controls the stability of the entire distribution.