On Sun, 2005-01-23 at 17:34 +0000, Stuart Herbert wrote: > I feel like neither you nor Patrick are listening to anything any of us are > saying on this subject, but I'll give it one last shot.
I feel that you are answering "the grass is green" whenever I ask you for the time of the day. Hmmm ... > On Saturday 22 January 2005 08:52, Daniel Goller wrote: > > since we can change an eclass after it was used on a system chancxes are > > he can not reproduce the same result twice > > 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"? you have to keep your own snapshot? you can't respond to any glsa? ... Wow, I'm impressed by your solution. It reminds me of the past, when real programmers used to knit software from single bytes ;-) > a) Our users are not customers. Please do *not* talk about them that way. > They're much more important than that ;-) Eh? Care to explain that? > b) Your scenario is flawed. Most users do not attempt to install specific > versions of a package. So a bumped ebuild inheriting a broken versioned > eclass means that, for most users, the package is just as broken as it would > be 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." Cool. > > we can not control what they do, but we can control what we do once we > > are aware of a possible problem > > 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. 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. > > > 3) They can restore files from their regular backups. > > > > see 2) > > What sort of an answer is that? 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. And they are your driver for the day. ;-) > You didn't answer my question. Who goes around telling users to grab files > from viewcvs? Have you stopped beating your wife? (Or, put in other words, what does that have to do with blue kangaroos?) > 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 > 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? ... [snip] > 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. > 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. (Note to portage guys: This is not meant to insult you. It just shows that some general statements are quite stupid) > 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." > 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. > 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 'nuff said. > 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" 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. hth, Patrick P.S. That strategy has been used by a few devs in the past and had on average positive results ... P.P.S. If you find any form of sarcasm, cynism or humor, you can keep it.
signature.asc
Description: This is a digitally signed message part
