On Sun, 2005-01-23 at 18:17 +0100, Patrick Lauer wrote: > I feel that you are answering "the grass is green" whenever I ask you > for the time of the day. Hmmm ...
...and you and Daniel are answering with a question every time we ask a direct question or ask you to refute something we've said. > > If we wanted the user to reproduce the same result, we wouldn't be updating > > the eclass in the first place. > eeeh .... > so you can't ever "emerge sync"? Where was this mentioned? I see nothing of the sort in Stuart's response. > you have to keep your own snapshot? Wow. Are you two just grabbing anything out of the air and trying to pass it off like we said it? > you can't respond to any glsa? Again, where does this fit in the discussion at all? > Eh? Care to explain that? We are a community that cares about our users. We are also all users ourselves. Every developer we have or will have has come from the user pool. In many cases, customers implies nameless faces, tied to some account number. "Hello, my name is Apu and I will be your Gentoo support today." > ... but I might be able to tell them how to fix it instead of saying > "Well, you'll have to wait until $DEV reads the bug, can reproduce it > and maybe even fixes it. Until then, don't use your computer." Because explaining to someone how to revert an ebuild/eclass from CVS is infinitely harder than having them mask versions and revert. Not to mention the fact that your argument holds no water consider that is how *EVERY BUG WORKS* in Gentoo. Would it be any different if it were a bug in a package that wasn't eclass-related? Even better, in the case of a serious problem that is deemed an emergency, if you cannot get in touch with the developer, as a developer yourself, you have the right to correct the problem to reduce the impact on other users and to help the users that have already been affected by the change. > > We don't need your proposal of versioned eclasses to "do control what we > > do". > Yes. Instead we should discuss this. Or rather, we should discuss if we > should > discuss it. Well ... Maybe we should discuss if someone should write a GLEP > to > start a discussion. Ahh yes, the old "Why don't we write a GLEP" defense. Why is it that this one always comes out whenever someone's ideas get rejected because they have no technical merit? > So please, to further whatever remains of a discussion here to a > conclusion, tell us how you want to fix the problems we are seeing right > now. How about you actually describe a problem, and not a solution, and then we could possibly see what you're talking about? > A frustrated one. > Y'know, the kind of answer that happens when you tell people their > brakes will fail and they still want to hop in their car. Or when you cry wolf over and over again? > > Reverting an eclass is no guarantee that the package will be installed > > correctly. Eclasses are normally changed to fix bugs after all. > but they might also introduce bugs So might any change to the tree. This sort of reactionary behavior would have us not doing any commits for fear of possibly breaking something somewhere sometime somehow. Thanks, but I'll stick with the current method of actually doing some work. > > Personally, I think that we should ship with 'strict' enabled on all arches > > which support it. There should never be a bad digest. > So ... how are devs motivated to sign all ebuilds? What does stract, which does strict digest/Manifest checking, have to do with signing? We made no mention of "sign" or "gpg" in this thread. > > What you're suggesting seems to be bad engineering. It is in no-one's > > interest for Portage to contain bad engineering. > Yes. So instead of yelling at each other and pulling the non-existant > seniority card > we could talk about some perceived problems, their impact on the users > and the developers and strategies to reduce those problems. Let us know when you come up with something and decide to stop beating around the bush. > > Cut n paste programming is very distasteful. It's unecessary, it's poor > > engineering practice, and I personally would support seeing all those who > > teach this practice being disbared for life from teaching software > > engineering in any shape or form. > So ... why does "emerge" have a copy of the digraph class from portage.py ? > You might want to beat some sense into those morons that did it. Oh yes. A single example versus duplicating every bit of code from every eclass multiple times. Bravo! > > Ah. This thread, like the last one, hasn't come across as you seeking > > answers > > to a problem. They've come across as "we want to make this change to > > Gentoo". > ... and it has been blocked with "I like the way it is right now. Go away." More like Stuart, Ciaran and myself each giving examples on how this proposal would increase workload, not solve any of the problems at hand, and unecessarily tie developer hands with a process and policy that decreases productivity and progress. But if you really want to hear it... "I like the way it is right now. Go away." ;] > > Yes, they do. Preventing them from doing so via software is not the > > answer. > > We should expect a higher standard from our devs. We should expect them to > > understand why certain things need doing in a certain way. If they're not > > capable of understanding the why, then they shouldn't be devs. > > And if someone offers what that person sees as an improvement, we > shouldn't tell him to go away because we might have to change things. No. Instead we show the person where there improvement is flawed based on many technical examples and hope the person has enough sense to take notice of our examples and give up on his idea, rather than blindly pushing it as the solution to a problem which they cannot even demonstrate exists. > > And out in the adult world, sometimes the rules have to be broken. That's > > why > > an educated dev is more use to us than a dev who is also told "you have to > > do > > this every time, and the software won't let you do it any other way just to > > make sure". > repoman Repoman doesn't even work in gentoo-x86/eclass, thanks for playing. > > It's not your wording that seems to be the problem ... it seems to be that > > you're not used to presenting problems for peer review. > "Arguing on the Internet is like winning the special olympics ... even if > you win, you're a retard" So you really want to win? > I think at this point we should change our strategy: > > At some point in time, we bribe the doc people to post a new policy and > commit stuff all across the tree. Then you'll have to use it. Excellent, except the same people that post developer policy are the same people that would be examining your actions and deciding whether or not you'll be sticking around once the complaints start rolling in from developers and users alike. There's also that fun thing about being able to revert a commit that you seem to forget, after all, the inability to revert a commit seems to be your prime reason for this proposal. > P.S. That strategy has been used by a few devs in the past and had on > average positive results ... Usually it was because their ideas made sense and worked, not because they were a vocal minority with a technically inferior solution to a non-existent problem. Perhaps it is time you rethink your position, but I don't see that happening any more than I see our moon suddenly raining cheese on Ethiopia. > P.P.S. If you find any form of sarcasm, cynism or humor, you can keep > it. It is "cynicism". There's no need to be funny. Your proposal is humorous enough on its own. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
