what is unprofessional is that we acknowledge that poor QA can lead to breakage that is hard to resolve if one is not a dev with access to all previous versions.
i think it is unprofessional to acknowledge that it can happen and to reply "then they file a bug" when it could be avoided before hand
it is not much more professional (albeit helpful on the technical side) to make a suggestion and right out say "but i will not do it" which again shows no care for what happens to the users
wolf said proper QA would avoid what i outlined, and it would, but we are all humans, and noone is perfect, all i am after is a safety net
kind of like building a nuclear reactor with the rods pulled out from top, so in case of power loss they will sink into the core instead of allowing a tschernobil style meltdown (yes im saying we are building a core with rods pulled out from bottom, for analogy sake)
it was not my intention to say this is how it is done, my intention was to talk about versioned eclasses, while i only achieved to have people pick on an example, if anything, this thread was helpful to choose topic and initial post more wisely in the future
it should allow me to avoid misunderstandings and keep it closer to the issue, it will be asking for input on how it could be achieved, rather than sounding like i had a soultion i wish to push
and my summarizing came from the thread overall sounding like noone cares that it can happen, and that something should be done to minimize the risk, that i find unprofessional, to toy with a users system, cause an eclass that can be used across many archs is not tested first, but shoved into the tree instead, and please correct me if i am wrong, stable gcc-3.3.5-r1 inherits toolchain.eclass too, now if it is supposed (lets pretend for example sake) to be that it works entirely independent on gcc-3.3 than on gcc-3.4 i could still respond, that nothing was supposed to change for gcc-3.4, so how do we know it didnt affect gcc-3.3.5 too? then we are facing an eclass change affecting ~arch and arch users, which in my eyes is not professional
im not needing people to agree with me to find them professional, i just would like to see people take their QA seriously, which is what this in the end boils down to
Jon Portnoy wrote:
On Wed, Jan 19, 2005 at 12:54:50AM -0600, Daniel Goller wrote:
so what is the consensus?
we have people who care and wish there was versioning (in whatever most practical way this is realized)
some who say which is the only possible way to do it and immediately say they will not comply
some how all their negativity aside agree it would be lack of compliance that would hinder the success of the idea
so can this be summed up that we as gentoo developers do not care enough to do something that would allow us to prevent major breakage for users?
that we do not care enough to demonstrate enough professionalism "in the wild" to get people ever interested into something corporations (whatever the final name of the product would be) would be interested in testing?
that we dont care enough that we have a process that costs fellow developers money when a demonstration of gentoo simply doesnt work, and the interested customer in turn be turned off by what they see?
is this how we want to present ourselves?
someone please tell me this is not what this thread shows, cause when i go through it all, this is what i read.
i think this thread should continue under another name, and i will make sure the new topic will be shorter and more to the point, another, new point, just related, and i will try to no longer reply to pointless, purely negative, contructive criticism free comments, maybe those highly annoyed devs could simply refrain from creating traffic unless they have something to add, many should appreciate that, most likely..quietly
The fact that people disagree with you does not make them unprofessional.
You are not helping your position with this approach. There really isn't any room for "do it my way or you're not being professional" in a technical discussion.
signature.asc
Description: OpenPGP digital signature
