Timothy Redaelli wrote: > Hi, > I want to propose a "Maintainer Timeout" such as FreeBSD. > If a maintainer or herd does not fix (or assign/comment) a bug in a > reasonable amount of time (2 weeks? 3 month?) any developer can fix it > (or a pre established group of developers such as QA) > > Thanks for your time :)
I think if everyone abides by two rules (which I thought were pretty evident, but maybe not). Don't be an asshole Don't screw up* Don't be an asshole means you should make a good faith effort to contact a maintainer or herd before touching stuff. I remember a time when portage was generating duff sha256 checksums and marienz and I were working on fixing them; this was right around the time that Xorg 7 (or 7.1) was coming out and we had to touch all the modular builds. Of course little did we know by touching the ebuilds we messed up all of the checksums for the source tarballs (because we had older tarballs locally; such that the local copy was older than the one on the mirrors). So even simple things like fixing a duff digest can be harmful if you are not careful. How long you wait depends on the severity of the problem. Don't just ping people on irc, send mail. If they get pissed, you should have some CYA material (thats cover your ass, for those who don't know). If they come complaining about it you have the MAIL-ID of the e-mail you sent them. Don't Screw Up means you shouldn't try to touch crap you have no friggin idea how to fix. ASK QUESTIONS FOR THE LOVE OF GOD. Most of my learning here has just been from incessantly annoying the hell out of the developers with more experience than me (especially marienz, vapier, and flameeyes). If you think your idea *might* work, test it out. Get others in -dev to test it out. Get someone in the herd to look at it, get ANYONE competent to look at it. And the Corollary: be honest when someone asks you a question to which you do not know the answer. The worst case is asking someone a question to validate your idea and them agreeing with you just for the hell of it, as opposed to actually examining the issue at hand. This is one of those cases where the more you know about the tree and it's workings the better equipped you are to deal with issues like this. We have a lot of developers who do not know as much as what I'll term 'the old skool devs' did (myself included). That makes keeping the 'everyone owns all the packages' idea around more difficult; in the end we have a team of developers that are not as well equipped to deal with issues. * Corollary: if you do screw up, take responsibility and fix it/find someone to help you. DON'T MAKE IT WORSE. -- [email protected] mailing list
