Re: [Chicken-hackers] Re: repository branching

[Jim Bailey]

Hello,

I don't really use Chicken all that much, and so don't really care
about it all that much, but it is a useful tool so I hope you don't mind
if I voice an opinion as a complete outsider.

A tool is only useful to me if it is reliable. I would prefer to get
something that I know and trust (through experience), and know that if I
want to get it again I do actually get the same thing again. I would
also like the option of getting bug fixes if I find I need them, but
that should never be the default or hidden from me because bug fixes
can also introduce new bugs, and my code might be able to handle the
fixed bug and not the new bugs.

> I would rather not.  I would like to continue providing updates for my
> eggs for older releases *in those cases in which it costs me nothing
> to do so* (that is, in 100% of my 22 eggs).  Since it costs me nothing
> to continue supporting them, I don't see a reason to force users of my
> eggs to upgrade whenever they want access to new functionality (or, to
> put it another way, I don't want to have to update 4 chicken
> installations the next time I release one of the eggs in which my
> software depends).

New features and bug fixes are dangerous, I would not want them by
default. They can however be useful, in which case I would appreciate
being able to download a maintained egg, try it out and maybe deploy it
if I think it is suitable. So I would say thank you for maintaining
your eggs so well, it is appreciated, and if you could make them
available outside of the repository that would be great. Of
course they are in the repo anyway because they are the latest versions
for the latest release, but for a simple bug fix I would like to just
download the maintained egg, try it and deploy it.

> > >  I think the "ah, only release for the latest release" policy is a bad
> > >  idea.  I expect ALL my 22 eggs to work on both releases 2 and 3.  When
> > >  I make a new release, I don't want to force people to upgrade to
> > >  Chicken 3 if they want the new functionality I add to my eggs.  And,
> > >  of course, I don't want to have to deal with having to set tag 1.12 in
> > >  multiple /tags/ directories.

These new releases are certainly welcome, making them available
externally lets those who want them get them. Those that don't,
won't. Installing using a mix of custom eggs and repository eggs is
rather trivial after all.

Now one thing that does strike me is that a lot of the issues here are
a problem with SVN. I stopped using centralised revision control
systems a long time ago because they are so utterly wrong, and here is
why:

Felix, you are right. You made a damn useful tool and I agree with your
take on what needs to be kept frozen (i.e. old versions). Because I
know you are right, it is your version that I trust. I want to be able
to get code out of your repository and know that it only has the things
in it you approve of.

Alejandro, you are a different right. You have also made some damn
useful contributions. How you want to handle updates to the eggs is
unacceptable to me, but probably perfect for you and other people too.
Anyone that prefers your way of doing things should sync up to your
respository instead. As long as you continue to base your principal of
"I want Felix's Chicken with all my latest eggs" you just have to keep
on syncing up with Felix's repository - which leaves all your changes
intact, so is exactly what you want.

Anyone else with any ideas can also have their own repository and leave
Felix alone! This is as it should be, because I do not want you trying
to cooerce the person I have considered trustworthy. If you make
something truly wonderful then you can expect to have your code pulled
into Felix's repo when he is ready.

Most importantly to me, and anyone else managing deployments, is that
with a distributed CMS when you decide that a version is good, you can
then deploy that exact version. All my servers get their repos
from my staging machine's repo, no where else. If I find a bug I go to
the staging machine and either cherry pick a fix (i.e. I only get the
fix, nothing else) from someone if there is a fix out there, or fix it
my self and check it in. After that has been tested properly I can then
do a sync on all the servers and they get my new version. If I am
feeling generous I would then email a patch upstream. As a bonus there
is nothing special about the staging machine's repo, it is identical to
the servers' repos, so if it gets destroyed I already have a backup - on
each server.

In short, I recommend using git, it addresses the social needs of the
developers and admins as well as the technical ones. It can also import
your entire SVN repo, history and all, so is at least worth playing
with.

I think I have said enough for a meddling outsider. Thanks for all the
development, Chicken, eggs and all. I hope you get the version control
sorted out and get back to coding soon :)

Best Wishes,

Jim