I have an idea: how about fixing the damn bug as soon as someone proposes a good fix for it?

Someone still has to judge what is a "good fix," and do it promptly. This may involve regression testing, which also takes developer time. This means someone still has to decide what bugs are high priority, and make developers work on them.

how about the developer applying that fix? Either use it or leave a note like 'this patch is shit, no can do'.

I *love* people who extrapolate their opinion to global validness.
(But of course installed packages from sunrise decrease naturally as the ebuilds make their way to the main tree. Question: Do you think those ebuilds would ever hit the main tree if they weren't introduced in and tested by the sunrise project?)

And finally, my dear fellow gentooers, asking whether people are "nuts", "drunk", "insane" or anything else just because you do not share their opinion (and experience, mind) is no real option for any discussion.

Don't you think it's terribly wrong that some of the devs have to be constantly poked in the back in order to function properly?

Well... I would admit that... as an ordinary human being... I function... a bit like that...
At least, I never made any personal progress without having been poked.
Hopefelly... I get the capability to poke myself... but... that's only a capability I presume...

Honestly ! Isn't it just obvious that the more you feel responsible for something, the greater your response time to events is ?

Practically, I do personally ask for your help now on decision making about a real practical problem I get :

I am currently in the process of packaging a new kernel release.
Of course I carefully review all the new patches (pfff ! quite a few !)
OK then, now I get one on a domain of the kernel I know nothing about. Patching a file I know nothing about, dedicated to a supported arch but I don't get such a system in order to test.

Please consus, tell me what should I do :

- Include this patch and wait for some user to (rightly) blame me for having broken his system ?
- Not include this patch and wait for some user to (non-less-rightly) blame me for not fixing something wrong in his system ?

BTW, you'll notice that (apart in some exceptional cases, that is to say when the patch does nothing) I will be poked back anyway.
well... I feel that I just get the choice of which poke back I accept...

I am currently in the process of packaging a new kernel release.
Of course I carefully review all the new patches (pfff ! quite a few !)
OK then, now I get one on a domain of the kernel I know nothing about. Patching a file I know nothing about, dedicated to a supported arch but I don't get such a system in order to test.

Read the ... [Mod edit for language. — JRG] documentation first. Ask someone competent enough. If you know nothing about the stuff you deal with, the whole thing is screwed.

Thanks for the warning by the way. I will try to avoid the software you package in the future.

how about the developer applying that fix? Either use it or leave a note like 'this patch is shit, no can do'.

A developer has to pay attention this bug out of thousands, then take time examine and test the fix. My point is that someone has to decide that this bug out thousands is worth the dev time, and there is no such mechanism in place to do that. Obviously, an Apache bug is worth the dev time, but if it falls through the cracks there's no way to catch it other than seeing complaints on the forums._________________Personal overlay | Simple backup scheme

I am currently in the process of packaging a new kernel release.
Of course I carefully review all the new patches (pfff ! quite a few !)
OK then, now I get one on a domain of the kernel I know nothing about. Patching a file I know nothing about, dedicated to a supported arch but I don't get such a system in order to test.

Read the goddamn documentation first. Ask someone competent enough. If you know nothing about the stuff you deal with, the whole thing is screwed.

Thanks for the warning by the way. I will try to avoid the software you package in the future.

lol !
Not to speak about me personally... just with regard to the method I had described on purpose... : Well... I bet that you are soon going to be very short on code to feed your processor with... _________________

Lol what? This is very far from being funny. You have clearly stated your incompetence in the area you are working. Both of the approaches you proposed in that case may lead to the broken [Mod edit for language. — JRG] kernel. This is really very far from being somewhat funny or clever. Please, avoid software maintaining, you are clearly not qualified for this.

Lol what? This is very far from being funny. You have clearly stated your incompetence in the area you are working. Both of the approaches you proposed in that case may lead to the fucked up kernel. This is really very far from being somewhat funny or clever. Please, avoid software maintaining, you are clearly not qualified for this.

Oh probably ! Now, this being said, you are yourself clearly not qualified for ranting as you did not even realize that what you are actually demanding would not require more workforce, would not require more competence, would not require more user care...

It would just require what is called in terms of project management : Infinite resources !

OK the evidence is so strong that I won't elaborate. As this does not seem obvious to you, here's a clue : The problem for which you demand a solution is recursive !

If you did not realize that... then... yes ! lol !_________________

Last edited by aCOSwt on Tue Dec 18, 2012 10:48 am; edited 3 times in total

If there's one thing I hate about IT, it's that it's filled with self-righteousness ... like grey_dot. There's a small group of developers that have sacrificed their time to keep all of our systems running for years, and this guy figures the best way to promote his personal (bug) agenda is to post an inflammable POS like this topic. Great way to motivate a group of volunteers. Let's stop giving this ... [Mod edit for language. — JRG]