Re: Bikeshedding
On 15356 March 1977, Anthony Towns wrote:
Did anything happen to that? (Or perhaps, that's better phrased as:
did anything cause it to stall other than ENOTIME?) I'm guessing not?
[1]
ENOTIME. And ENOONEELSEINTERESTEDINCODING.
Unless the things that caused it to stall were legal concerns or a need
for separated hosting/mirror infrastructure, that might not be something
the DPL can make much better. Perhaps if Joerg quits DAM due to being DPL
and ftpmaster due to having to re-delegate it, the combination of those
might leave him with more time for dak development despite also being
DPL?
Thats an interesting take on it.
As a result, I kind of disagree with Joerg's statement in his platform
that "As the DPL is not the lead of actual technical development, it is
not for the DPL to find technical solutions for the challenges we face"
-- I think spending time making a huge technical improvement for the
project, like bikesheds, would be the best way to demonstrate leadership
(whether done by the DPL or not), and honestly I'd be more impressed
seeing a DPL do that compared to a DPL spending a year's time focussed
on mediating disputes and PR. Obviously, YMMV.
I stay with my statement. The DPL is not the lead of actual technical
development. But that does not exclude a DPL from being the lead of
actual technical development - by the virtue of the person thats DPL at
the time also being in a team where that development happens.
Maybe obscure, but I think of that as two hats.
* Debian is made up of a lot of policies, and rules; and often has a
lot of arguments and hurt feelings. Debian's also made up of a lot of
genius (and admittedly not so genius) code and technical achievements.
Usually, DPLs seem to spend all their time dealing with policies and
conflicts, rather than technical stuff.
Do you think it makes sense to put some real effort in moving the
balance the other way? If so, how?
I think we do have a good amount of policies and sometimes too much of a
fear to just go and break one if its sensible. Also, everyone likes to
define sensible different.
And yeah, we discuss things to death way too often.
Unsure how to get that pendulum moving into the other direction, and for
how far.
* Do you think bikesheds are actually a bad idea, or know of any other
particular roadblocks in the way of making bikesheds happen? If Joerg
is too busy to do it, do you have any ideas on how others could make it
happen (within Debian, not as a derivative of some sort)? If elected,
would you help remove those roadblocks?
I think they are a pretty nice one and would still love to see them.
Others: The hard way, join the ftp team, work your way up until you have
the powers to just go and do em. Takes years.
Better: First off it needs code finished. There is a branch, bikeshed, I
just pushed it to salsa. That does need to get a recent master $magiced
(merge, rebase, whatever) in, then cleaned up and finished off. Anyone
who understands python can start working on that. A bit of understanding
the archive will help, sure, but first off, its python code.
That will take a while before it does need an ftpmaster. Any of us,
though I am happy to be the contact and think Ansgar won't run away
screaming either.
* As far as technical projects go, is there anything you think would
have more of an impact than having bikesheds available to every DD?
(Or, if you think bikesheds are a bad idea, what's the biggest positive
impact technical project, in your opinion?)
Salsa as the one and only platform of hosting our packaging, with only
ONE way of doing so in git, not half a dozen, followed by "git push ==
upload" I mentioned elsewhere.
And less "I'm the package maintainer, this is my castle, go away" and
more "This is how the majority does it, you follow, the benefit of it
being one way, not a dozen different, outweight some personal
preferences".
--
bye, Joerg
Reply to: