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
Properly signed and key available
Sincerly,
Daniel Goller
Daniel Goller wrote:
I think any change to things pertaingin to gcc, glibc, binuntils and their eclasses should require a rev-bump, even if the change seems trivial like splitting out more functions into eclasses.
It might be rather easy for a developer to revert to an older version of a file, but if version X-Y-rZ is replaced with a incorrectly working ebuild of the same revision level, a user who caught this via a emerge --sync is pretty much "effed" if the breakage is big.
such a rev bump could propate though package.mask into ~arch after devs tested it, then hit ~arch and arch as usual
i know policy says not to bump if it adds no new functionality and we wouldnt want people to remerge OpenOffice for a bug fix someone receives.
Rearranging the ebuilds of essential core funtionality on the other hand i think is different, the inconvenice of down the road merging one that does nothing new for you is far less than finding your system dead after remerging just to add say USE=fortran
You go emerge gcc -vp after adding fortran to USE in make.conf and see portage with the R you hoped for noe U you might be wary of and remerge your gcc, just to find your compiler dead afterwards
now, did somehting like this rcently happen, no thankfully not
did something happen, yes, it is minor, wont break your gcc, only doubles your merge times so people who are used to 1 hour, merge it in 2 hours on x86 at the moment (gcc-3.4.3-r1)
i think this is the right opportunity to say, hey, let's all be careful and make changes to toolchain known to users in a very obvious way
dont make them check ChangeLog each time they merge, aside split out functions into eclass might not alert them anyway
Package.masked would give us time to catch a real problem before it hits ~arch users
or more interestingly arch users if a change might seem to work for both arch and ~arch and is done in one wash
if we dont make changes transparent to users on every package, fundamental tools should be bumped.
Please don;t tell me such a trivial change in how we handle bumps requires a glep ;)
I think this would be a good thing for everyone and we would be safe from "what? nothing changed in foo-X.Y-rZ" in the future
Daniel
signature.asc
Description: OpenPGP digital signature
