Hi Goran!
- Let's hope Ian takes better care of sucking up contributions from
the
early adopters.
There are three types of contributions:
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.
Type 1 contributions are ignored. If somebody has an essential
change that they cannot live without and it goes into my type 1
'circular file', then maybe a fork is the best option for everyone
concerned. I don't think I have been sent any (non-trivial) code
that has been of this type.
Type 2 and 3 contributions are adopted. Both have scheduling 'issues'.
Type 2 contributions (Makefile fixes, gcc worksrounds, etc.) are
adopted at a speed directly proportional to my use of the affected
system, compiler, OS, etc. 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. 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.
Type 3 contributions are extremely valuable since they pull people
into the vision sooner. They would, in an ideal world, be adopted
immediately. OTOH they tend to be complex and deep and require
combinations of concentration and monolithic time, to be sure they're
done right. This causes delays for very different reasons. 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. 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. ;)
- ...AND/OR let's hope Ian makes it easy for early adopters to
contribute directly!
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. ;-)
FWIW, delegation and autonomy will be better in the near future when
subsystems start to take on a life of their own and turn into real
sub-projects.
I would like to see a dedicated wiki.
This we can do. (We might even want to make it a Swiki.) Do you see
any disadvantage to its being hosted at vpri?
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. A distributed SCM like
Mercurial is
vastly superior to SVN in this regard and Mercurial is really, really
nice.
I'd certainly consider this if/when the 'pressure' from other repos
becomes significant. Right now SVN has the advantages that (1) it's
already installed on my server, (2) it's already serving up content
via a multitude of methods that were not entirely out-of-the-box
happy experiences, and (3) it's where all of my source code lives,
COLA and otherwise.
(Are you sure you want me to switch to Mercurial? 'git' would seem
more in keeping with my character. ;-)
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')?
This project is currently in a very early stage. It's still
meandering (to use Michael's rather apt term) but there is a long-
term vision; definitely at the crystallisation of style (and not the
agglutination of features) end of the spectrum. I'm afraid I am
necessarily going to be selective about the contributed code that is
included, and about its form, at least for the 'kernel' stuff.
Things that appear useful may well be rejected because there's a plan
for something similar (but better, according to my strange metrics) a
year or two from now. Things may be rejected for no better reason
than they don't 'feel right'. Things that are relied on by members
of the community may well vanish overnight, as and when a planned
longer-term alternative becomes viable.
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.
Am I being antagonistic? Well, perhaps, but I really, really want Fonc
to prosper as an open source project
Me too!
and I really, really fear that it will *not* unless people try to
make that happen.
+
I really, really want Fonc
to prosper as an open source project - and I really, really fear
that it
will *not* unless people try to make that happen. Just coding is not
enough, sorry Ian.
+
PS. I am an interested bystander and can't really contribute on the
lower levels - but would love to make at least some contribution in
the
higher levels.
= maybe you'd volunteer for Wikiministration, or anything else you
think could help?
(And darn. I thought I could get away with just coding. :)
Cheers,
Ian
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
