Hi Ian, Ian Piumarta <[EMAIL PROTECTED]> writes:
> 1. Those that are not useful in the long term or the short term. > 2. Those that are not useful for the long term vision but that are > pragmatic, solve a minor complaint in the short term, or provide a > simulacrum of something desired for the long term but that cannot be > implemented 'correctly' yet. > 3. Those that are useful for the long term vision. That's a good description of the different contributions. > I have browsed Michael's big list of commits on his cvsweb > (MercuryScope? ... whatever it's called) and many of them are > clearly relevant and of this type and already on the in' pile. I recently made a switch from using plain Mercurial to the Mercurial Queues extension (which is similar to the "quilt" system), as that better suits the kind of development I intend to do. This vastly improves the signal-to-noise ratio of the source browser linked at http://fig.org/ocean/ocean.html, if you haven't seen it yet. > If someone's continued existence depends on one of these, then a > fork is definitely overkill: it _will_ eventually make it into my > trunk, unless for some reason I think it's wrong or irrelevant. I need to clarify why I said "branch" and not "fork". It is fully my intention to help LOLA (BTW, great name!) evolve features in a way that is consistent with the end vision, but at the same time, I will probably have a plethora of type 2 patches that I need in order for my application software to work. If somebody is tracking my branch, I expect the only reason they'd do so is if they want to try my application software, or they want to build their own applications on features that have not yet been "done correctly" and included in the mainline. > So far Michael's __frame thing is the only contribution of real > consequence of this type, and I think we're rapidly converging on a > shared vision for it and it certainly will be adopted in the very > near future. Yes, I expect that this is what will happen to everything of the type 3 category. > In these cases I think a fork is a more complex issue; > if it's the best way to share significant experimental changes with > the rest of the world, faced with my anally-retentive death grip on > my repo, maybe it's not such a bad idea. ;) If we make a comparison to Linux development, I would very much like Ocean to be the "mm" tree... an experimental proving ground for features that may or may not make it to the mainline in the end, but which are temporarily useful to my own goals. No need for lawyers, Ian. ;) > I doubt I'll be giving out write tokens to my trunk to many people. > (If it's important to anyone to have a swarm of uncoordinated random > committers, maybe a fork is what they need. ;-) This is what Mercurial is good at, so I would encourage anybody who wants to swarm, to swarm around in Ocean. The goal is to evolutionarily (is that a word?) produce high-quality patches that can be submitted to the main LOLA tree. >> I would also love to see Ian switching to Mercurial thus making it >> VERY easy for people like Michael to both branch off and to >> contribute back - or for Ian to receive contributions. Not really. The only functional difference between you using Mercurial or SVN, is whether I do: $ hg qpop -a $ hg pull http://piumarta.com/lola/hg.cgi $ hg update $ hg qpush -a or $ hg qpop -a $ svn update $ hg commit -m "Imported from SVN." $ hg qpush -a If you use Mercurial, then the Ocean repository gets all of your pretty log messages. If you use SVN and I have to import, then it looks like I'm doing all the work, not you. ;) >> A distributed SCM like Mercurial is vastly superior to SVN in this >> regard and Mercurial is really, really nice. Agreed here. > (Are you sure you want me to switch to Mercurial? 'git' would seem > more in keeping with my character. ;-) Git is more complex and seems to suffer from regular security problems due to it being written in C. >> Now, if Fonc is going to be run as a "closed shop project" - which I >> really, really hope not - but which I also fear - then, well, then I >> will reconsider and perhaps instead look at Michael to give me the >> satisfaction of a living open source project. > > Can you elaborate on this? What would make it more 'open source' (as > opposed to 'open write')? Spin. Hype. Excitement. I'm a world-renouned Free Software cheerleader. ;) I want to solicit even the most trivial changes, and get them into the Ocean tree ASAP to give people instant gratification. But it's really an illusion: they won't get into the *real* tree until their patches are discussed, reworked, and make the grade. I just want to provide a repository where that can happen incrementally without people having to host their own repo (if that's not what they want). > This might be what Michael was talking about when he said we're > working on something 'very focussed'? The path is completely fuzzy, > but in my mind much of the destination is in perfect focus. Yes, exactly. > (And darn. I thought I could get away with just coding. :) I'd be happy to do the political stuff, if you want to just code. :) -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
