Discussion:
[META] new COLA branch
(too old to reply)
Michael FIG
2007-11-02 05:10:27 UTC
Permalink
Hi, Ian...

I'm sending this message to the mailing list, with the intent that
what I say and your reply to be public so that it can be archived for
future reference.

I joined the mailing list because I'm one of the "insatiably curious"
people you mentioned on your website. I'm also itching to contribute
to the COLA system, in whatever ways I can. For me, that means
advocacy, writing documentation, supporting other users and
developers, submitting patches and coding new features that interest
me and are in line with the project vision.

I understand from what I've seen of your writing and other projects
that you a highly skilled programmer, designer, and researcher. I
also understand that you are working for VPRI on what must be very
focused tasks without much leeway to meander endlessly as other free
software projects are wont to do.

I, on the other hand, have more enthusiasm than skill, but have a lot
of spare time on my hands in which to tinker and learn. I have been
looking for something exactly like COLA for the last 15 years or so,
and this is the first project that is both completely ambitious yet
not flawed by design (as far as I can tell by my experience). It
truly is an architecture that looks eminently teachable and flexible.

So, this brings me to the point... I know that for a free software
project to thrive, there must be a rapid stream of communication,
accessible over the Internet. The buzz of people collaborating needs
to be there to provide the transparency so that other people will want
to get involved.

I'm quite sure that COLA, despite whatever shortcomings are in the
currently public implementation phase (Jolt/Pepsi), is at a point
where it would benefit from and be capable of sustaining contributions
from outsiders. I would like to jump right in and help get that
process going.

I presume that the reason you've been silent in response to my earlier
requests (various bug fixes, the unanswered questions on LtU, no SVN
commits since 2007-09-20) has been just because you're deep into the
implementation of Coke and don't have the attention to spare to jobs
that can be done by other people.

So, I'm stepping up to the plate. I've immersed myself in SVN r332,
and made what I consider to be some changes that are both useful and
increase COLA's flexibility. I like these changes, but I'm not
certain you would adopt them.

I think the best way to accomodate these different needs from the code
base (your highly focused minimalism, and my flighty expansions) is to
take advantage of a distributed version control tool, to manage the
patches more effectively and make them easier for us to move back and
forth. In so doing, I will also have full ownership of my own branch,
can encourage other people to use it, and answer questions about it
authoritatively.

For that reason, I've adopted Mercurial as my source control tool
(http://www.selenic.com/mercurial/wiki/ - it's friendly, safer and
simpler than C/C++-implemented SCM's, and cross-platform). I am
planning to continually import the COLA SVN tree, with my additions
separated cleanly into different branches.

If you or anybody else is interested in my repository, you can find
instructions on how to get started with it at:

http://fig.org/ocean/ocean.html

["Ocean" is my codename for this COLA branch.]

In doing so, I hope to lower the barrier for people to contribute to
COLA by being as responsive as possible to people who have patches for
my branch, then helping refine and advocate them to be included in the
mainline. I will be sure to mention each of these potential
contributions on ***@vpri.org, so that you can decide if you want to
integrate them with the mainline.

Please let me know if you would like to see patches in general, or
just upon request. Also, would you prefer future discussion of my
branch to be held on ***@vpri.org, or my own mailing list?

Thanks, and I look forward to hearing your reaction,
--
Michael FIG <***@fig.org> //\
http://michael.fig.org/ \//
Ian Piumarta
2007-11-16 19:55:27 UTC
Permalink
Hi Michael,
Post by Michael FIG
I'm sending this message to the mailing list, with the intent that
what I say and your reply to be public so that it can be archived for
future reference.
Oooh, sounds ominous. Should my lawyer be talking to your lawyer? ;-)
Post by Michael FIG
advocacy, writing documentation, supporting other users and
developers, submitting patches and coding new features that interest
me and are in line with the project vision.
All of which are incredibly valuable!
Post by Michael FIG
also understand that you are working for VPRI on what must be very
focused tasks without much leeway to meander endlessly as other free
software projects are wont to do.
Well, there's actually a lot of leeway for meandering. The goal is
to build something that is 'as small and as correct as we can' that
is a complete, self-describing, self-maintaining system (where
'correct' means conceptually correct, not 'free of bugs' although the
latter is obviously a goal too).
Post by Michael FIG
I'm quite sure that COLA, despite whatever shortcomings are in the
currently public implementation phase (Jolt/Pepsi), is at a point
where it would benefit from and be capable of sustaining contributions
from outsiders. I would like to jump right in and help get that
process going.
Great! There's lots to be done.
Post by Michael FIG
I presume that the reason you've been silent in response to my earlier
requests (various bug fixes, the unanswered questions on LtU, no SVN
commits since 2007-09-20) has been just because you're deep into the
implementation of Coke and don't have the attention to spare to jobs
that can be done by other people.
Sorry for the silence. October was a month of administrivia,
deadlines, maintenance of non-COLA projects, demo preparation,
travel, vacation, etc., with the result that I didn't read email at
all for most of the month. November is a little less frantic, but I
still have a backlog to clear...
Post by Michael FIG
For that reason, I've adopted Mercurial as my source control tool
planning to continually import the COLA SVN tree, with my additions
separated cleanly into different branches.
You should do whatever works best for you. Sounds like this is the
perfect solution for your 'parallel' patches.
Post by Michael FIG
Please let me know if you would like to see patches in general, or
just upon request.
Interrupts work far better than polling. If there's something you
think is useful outside of your code base then please send them along
to me or to this list for consideration. It's unlikely I'd remember
to go looking for stuff remotely on a regular basis (and it would
take up a lot more time too).
Post by Michael FIG
Also, would you prefer future discussion of my
This mailing list is very low-volume so you wouldn't be overwhelming
it, and it might be good to discuss compatible contributions in a
wider context; it'd make advocacy for new features easier too. But
ultimately, do whatever works best for you and for your current/
inteded use of the system!

Cheers,
Ian
g***@krampe.se
2007-11-19 09:04:47 UTC
Permalink
Hi fellas!

Ok, please don't fork already. :) And note that this "please" goes to
BOTH of you. It means that I would want you guys to *co*-operate not
operate in isolation.

So:
- Let's keep it on one ml.
- Let's hope Ian takes better care of sucking up contributions from the
early adopters.
- ...AND/OR let's hope Ian makes it easy for early adopters to
contribute directly!

I would like to see a dedicated wiki.

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.

Ian - if you use SVN mainly from CLI - then Mercurial is IMHO a much
better drop in replacement. Sure, some commands are a bit different -
but you grok it in minutes.

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. And then we can turn it
all around - we pull nice stuff from Ian instead of the other way
around.

Am I being antagonistic? Well, perhaps, but 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.

regards, Göran

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.
Michael FIG
2007-11-19 18:42:48 UTC
Permalink
Hi, Goran...
Post by g***@krampe.se
Ok, please don't fork already. :) And note that this "please" goes to
BOTH of you. It means that I would want you guys to *co*-operate not
operate in isolation.
Don't worry about this too much! I'm definitely going to keep working
on getting patches into the mainline, it's just that I need a separate
branch to satisfy the needs of my other projects while patches are
still being talked about and reworked for inclusion in the mainline.

I'm using Mercurial Queues, which helps ensure that my patches are
*not* a fork, but rather a layering on of other features that can be
easily submitted or changed.
Post by g***@krampe.se
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. And then we can turn it
all around - we pull nice stuff from Ian instead of the other way
around.
Urgh. I don't want this to happen... the only direct users of my
branch should be the people who need the patches it contains to be
able to use my other software (Figure, Pledge (an accounting package
whose web page is still to come)).

So, once I announce Pledge, I think you'll see the point of my
"branch".

Thanks for the comments,
--
Michael FIG <***@fig.org> //\
http://michael.fig.org/ \//
Ian Piumarta
2007-11-19 23:39:55 UTC
Permalink
Hi Goran!
Post by g***@krampe.se
- 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. ;)
Post by g***@krampe.se
- ...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.
Post by g***@krampe.se
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?
Post by g***@krampe.se
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. ;-)
Post by g***@krampe.se
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.
Post by g***@krampe.se
Am I being antagonistic? Well, perhaps, but I really, really want Fonc
to prosper as an open source project
Me too!
Post by g***@krampe.se
and I really, really fear that it will *not* unless people try to
make that happen.
+
Post by g***@krampe.se
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.
+
Post by g***@krampe.se
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
Michael FIG
2007-11-20 00:27:02 UTC
Permalink
Hi Ian,
Post by Ian Piumarta
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.
Post by Ian Piumarta
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.
Post by Ian Piumarta
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.
Post by Ian Piumarta
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.
Post by Ian Piumarta
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. ;)
Post by Ian Piumarta
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.
Post by Ian Piumarta
Post by g***@krampe.se
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. ;)
Post by Ian Piumarta
Post by g***@krampe.se
A distributed SCM like Mercurial is vastly superior to SVN in this
regard and Mercurial is really, really nice.
Agreed here.
Post by Ian Piumarta
(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.
Post by Ian Piumarta
Post by g***@krampe.se
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).
Post by Ian Piumarta
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.
Post by Ian Piumarta
(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 <***@fig.org> //\
http://michael.fig.org/ \//
Ian Piumarta
2007-11-23 22:30:48 UTC
Permalink
Hi Michael,

Thanks for the info re: Mercurial. I will look at it.
Post by Michael FIG
Post by Ian Piumarta
(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.
I think we have a cultural impedance mismatch here. If you look up
'git' in your dictionary you'll understand. (I have no intention of
adopting 'git' for SCM.)
Post by Michael FIG
I'd be happy to do the political stuff, if you want to just code. :)
More in a subsequent message...

Cheers,
Ian
Michael FIG
2007-11-23 22:33:22 UTC
Permalink
Post by Ian Piumarta
Post by Michael FIG
Post by Ian Piumarta
(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.
I think we have a cultural impedance mismatch here. If you look up
git' in your dictionary you'll understand. (I have no intention of
adopting 'git' for SCM.)
No cultural impedance... I've seen enough Monty Python to last a
lifetime.

I just *really* didn't want you to adopt 'git'. ;)
--
Michael FIG <***@fig.org> //\
http://michael.fig.org/ \//
g***@krampe.se
2007-11-20 09:52:50 UTC
Permalink
Hi all!
Post by Ian Piumarta
Hi Goran!
Post by g***@krampe.se
- Let's hope Ian takes better care of sucking up contributions from the
early adopters.
[SNIP of good explanation of types of contribs]
Post by Ian Piumarta
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. ;)
...which (the "grip") is why I really recommend Mercurial - it enables
us all to branch easily AND to make sure contribs easily gets fed back
etc.

(Darcs is slightly better at cherry picking - but it can go bonkers
sometimes so I am not using it myself anymore)
Post by Ian Piumarta
Post by g***@krampe.se
- ...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. ;-)
No, that is not important - but it is important to try to get the very
few people that really CAN contribute (like Michael) to actually feel
that they easily can do it. Again, a distributed SCM + a swiki with nice
lists of available repos would make this easily doable. In such a
scenario I can track (by pulling) Michael, or you, or both etc.
Post by Ian Piumarta
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.
Post by g***@krampe.se
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?
No, I don't see any disadvantage with that - presuming that VPRI really
wants this project to be open, see below.
Post by Ian Piumarta
Post by g***@krampe.se
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.
Fair enough.
Post by Ian Piumarta
(Are you sure you want me to switch to Mercurial? 'git' would seem
more in keeping with my character. ;-)
I know - but Mercurial is more cross platform and most people think it
is much easier to use.
Personally I believe they are very similar in capabilities, haven't used
git myself yet though.

Also, if Michael goes Mercurial (and others like me) we could set up a
gateway.
Post by Ian Piumarta
Post by g***@krampe.se
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.
I know it is - but you need to take some care about "community tending".
This means setting up a swiki, talking to the ml (about what is
happening), trying to get people involved in sub parts (like Michael)
etc etc.

There are people quite interested - but note that when I asked around at
OOPSLA this year it felt like... well, people feel it is stalling and it
seems to me that you don't need to do everything on your own. Like a
canvas UI? Ok, it's fun - I know :) - but perhaps someone else can pick
up that ball? But you need to show us that you *want* that.

Forgive me from thinking "loud" here - it is just to show you what I
feel. I think this stuff is really cool and really promising but I am
afraid it will stall because it all sits on your shoulders and you don't
have 24*10 hours per day to spend.
Post by Ian Piumarta
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 think we all share that idea. Contribution != agglutination of
features.
Post by Ian Piumarta
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.
And you SHOULD. That is your role. :)
Post by Ian Piumarta
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.
I think most of us share the purity idea - as long as we know what is
solid(ish) and what is not.
Post by Ian Piumarta
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.
Post by g***@krampe.se
Am I being antagonistic? Well, perhaps, but I really, really want Fonc
to prosper as an open source project
Me too!
Post by g***@krampe.se
and I really, really fear that it will *not* unless people try to
make that happen.
+
Post by g***@krampe.se
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.
+
Post by g***@krampe.se
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?
Sure, but I can't do much if you intend to host it yourself.
I could also help with a Mercurial gateway and perhaps some blog
articles if I get the time (ouch).

Btw, if you could whip up some Socket support in pepsi - then that could
open up some neat possibilities.
Post by Ian Piumarta
(And darn. I thought I could get away with just coding. :)
I know. :)
Post by Ian Piumarta
Cheers,
Ian
regards, Göran
Waldemar Kornewald
2007-11-20 11:36:49 UTC
Permalink
Hi,
Post by g***@krampe.se
[SNIP of good explanation of types of contribs]
Post by Ian Piumarta
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. ;)
...which (the "grip") is why I really recommend Mercurial - it enables
us all to branch easily AND to make sure contribs easily gets fed back
etc.
I have to agree with you. I've contributed to projects that used SVN
(e.g., Trac) and I really hated the fact that there was no easy way to
manage and save my patches (svk is horrible). If you have multiple
patches you can't keep them separate, especially if they're related
(e.g., you add feature A in one patch and in the next patch you add
feature B that depends on A but might not be accepted, so you want to
keep them separate).

Mercurial makes it much easier to manage separate changes and keep
track of them in your repos (e.g., one branch per patch, branches
extending other branches, etc.).

SVN sometimes frustrated me so much that I gave up and my contribution
was never incorporated. A distributed SCM would've solved my issue.

BTW, Mercurial is definitely easier to use than git and it runs on
Windows without having to install that stupid Cygwin and mess up your
system. There even is a full Mercurial package for Windows that comes
with a three-way merge tool and all necessary Mercurial plugins, so
it's even easier to get started.
Dan Amelang
2007-11-20 15:13:18 UTC
Permalink
...and it
seems to me that you don't need to do everything on your own. Like a
canvas UI? Ok, it's fun - I know :) - but perhaps someone else can pick
up that ball?
That's already pretty much my ball now. I have some interesting
results already, and will make a public announcement by the end of the
year.

Dan
Loading...