On Friday, July 12, 2013 17:48:50 David Jarvie wrote: > On Fri, July 12, 2013 4:42 pm, Aaron J. Seigo wrote: > > * there were 2 main reasons the branched-kdelibs shifted back to master- > > > > kdelibis: > > * people were too stubborn and too (willfully) uninformed to understand > > > > why this was a useful thing and just kept pelting it with stop energy at > > every possible opportunity. > > That's unnecessarily negative - why do you think that people would > willfully remain uninformed?
I don’t known the why, I just saw the discussions and they were too often characterized by stubborness and a lack of informed opinion. > Much more likely is that they would be > innocently uninformed due to not having seen announcements. Even for After having been pointed personally to the relevant materials, that’s no longer an excuse :) I’m certainly not suggesting everyone was this way. It was certainly a minority; but there were enough who were, and enough people who accommodated their stop energy. My point was not that *everyone* is stubborn or willfully uninformed, but that the flip flopping of strategies for kdelibs branches had a lot to do with those who were combined with the development requiring an extended period of time. It had very little (if anything) to do with the technical merits of the plan. So looking at it as somehow being a relevant reflection of that doesn’t make much sense. > best of intentions) for old habits to take over and to accidentally use > master again. This happened to me more than once. So how can we make that clearer for people and hard for this sort of mistake to be made? Here’s a possible idea: we could make the build fail (along with a relevant message on console) unless a specific env var or a cmake option is passed. If it doesn’t build, you probably won’t end up using it, and hopefullya build failure gets noticed. > > Example given: Build-tool failed to follow the repository switch of amarok > > (it was announced. i > > missed it because of being very busy) and continued to build the old stuff > > for months without problems. > > I agree. I'm sure that this must have caught out innocent people more > often than willful miscreants. Which is why we have projects.kde.org with the projects xml file which allows tools to track these movements. When we identify situations where we get caught out, we can look for ways to minimize the chances for that happening in future. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.