On 6/30/2013 7:37 PM, andy pugh wrote: > On 30 June 2013 14:11, Michael Haberler <[email protected]> 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. > Regarding your case in point:
We should be able to have user loadable (at run time) components -- running everything in user space would make that trivial. That would mean we could have as many gear change components as people cared to write. A broken component would only affect those who tried to use it. It would be marked as a contributed component (use at your own risk). Modularization is good. [BTW (Andy): It was good meeting you in Wichita. I'll remember you as (among other things) the guy who knew what Flemish bond was -- any why it was.] Regards, Ken ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
