On 30 June 2013 14:11, Michael Haberler <mai...@mah.priv.at> wrote: > there's something different at work, namely a rather high ranking of > stability and quality of support being the overriding driving factor. While > that clearly is a more commendable explanation, > unfortunately the effect is similar: the focus on a single technical aspect - > quality at a given point in time - drives other aspects into the background - > for instance: even if it is not 100% > ready for use, is it an important or at least first step into a new (and > eventually important) direction.
I think that there is possibly too much of an expectation that "Master must never be broken", but at the same time I can see why that is seen as important, because a lot of people routinely run it. (including me). I have always been of the opinion that creating a new branch was a mistake (and, to be honest, the times I have done that it has definitely been both a mistake and an accident). Having talked to folk at Wichita I am now seeing that this was largely a problem with my understanding of how things are meant to work, and I very much expect to be pushing a new (and explicitly, knowingly broken) tooltable branch this week. Part of my misunderstanding might stem from the fact that JA3 has been stuck in a separate, unmerged, branch for all the time that I have been involved. I haven't noticed anything from an experimental branch get merged. I may not have been watching at the right time. I can see an argument for deleting (or tagging) branches that got merged. (and possibly for tagging the "rejected/superceeded" branches. To merge threads, is it possible to set up a multi-level access to our Git server, where almost anyone can create a new branch, people like me can create a branch or push to master, and the folk who actually know what they are doing can push to the release branches? I don't think we need to migrate to Github to make ourselves more open to contributions, I just think we need to make it clearer how to contribute. (and to make it harder to lose contributions, and, as a consequence, the contributors). Case in point: http://thread.gmane.org/gmane.linux.distributions.emc.devel/4043/focus=4239 The current 2-ratio gearchange component is rather limited (and not just in the sense it only supports two gears). I know of at least three better versions that have been passed by. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
