DPL Campaign Questions 006
I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too.
I think that some DPLs are overwhelmed by the amount of requests they receive, and more importantly, are overwhelmed by the feeling of futility from perceiving that it is impossible to fix the things that they had intended to fix.
So, unless there are other factors I would need to adapt to, I would try to discourage the number of private requests, and to not lose hope and faith in Debian. I imagine that delegation could be very useful in both these areas.
What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect?
The DPL is theoretically one of the most important checks against the power of delegates. The absence of a DPL would thus increase any power imbalance in the the project, and likely to make the fighting between core teams even more political and harmful.
Communities and teams are destabilized by egos because people stop paying attention to their healthy shared goals and the people around them and instead focus on their own individual success. So if the project were to achieve some kind of anarchic utopia where this is not an issue, I could imagine that the DPL would be the last remaining ego threat, and removing that role would make things better.
However, we are nowhere near that now, and I think the DPL can do more good on this front.
What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is "goodness" or you're in the "good riddance" camp?
I definitely think that one of our strengths is being available on a large number of architectures, and beyond that, providing nearly identical experiences on each of those platforms. I am saddened when porters or package maintainers make decisions to stray from the norm on a particular architecture, because I truly enjoy the consistency. I have run Debian on i386, sparc, hppa, powerpc, amd64, and in the few cases where something was different, I found it irksome.
However, there is definitely a point where the cost in maintaining a release architecture far exceeds the benefit, and at that time I think we must regretfully bid it farewell.
So you are right that porters are a precious resource, and as DPL I would try to reduce their attrition. Speaking as a former porter, I found the unresponsiveness and uncooperativeness of certain buildd maintainers (especially when not porters themselves) to be extremely demotivating. I would try to find a way mitigate porters being demotivated in such a way.