Re: [Chicken-hackers] Re: repository branching

[Felix Winkelmann]

From: Alejandro Forero Cuervo <address@hidden>
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Sat, 23 Feb 2008 04:16:14 -0800

> First of all, I apologize for the way in which I voiced my opinion
> about this change originally.  It probably wasn't the best way to do
> it, making it hard to work together as a team.  I was a bit frustrated
> by this change and I got a bit carried away.  I'm sorry, Felix.

No, you didn't do anything wrong. It's me who occasionally gets
impolite.

> 
> > >  So what about the idea of adding a (supported-releases 2.3 3.0.0) tag
> > >  to the meta file, where particular versions of an egg that needs to do
> > >  so specify which is the range of Chicken releases it supports?
> > 
> > But for which version of an egg does this apply, then?
> 
> For the version containing the meta file with the tag.
> 
> For example, you would have:
> 
>   stream-wiki/tags/1.12/stream-wiki.meta, old version:
>     (supported-releases 2)
> 
>   stream-wiki/tags/1.13/stream-wiki.meta, supports both:
>     (supported-releases 2 3)
> 
>   stream-wiki/tags/1.14/stream-wiki.meta, starts using new features:
>     (supported-releases 3)
> 
>   stream-wiki/tags/1.15/stream-wiki.meta, new release:
>     (supported-releases 3)
> 
>   stream-wiki/tags/1.16/stream-wiki.meta, fixes security issues in
>   1.12:
>     (supported-releases 2)
> 
> Based on this, the post-commit script would maintain the following
> info (of which version of the egg should be used by each release:
> always the latest that includes it in the supported-releases list (or
> which doesn't have any supported-releases list in its meta file, which
> would be the same as saying “it supports all releases”)):
> 
>   ((2 1.16) (3 1.15))

I doubt that this would work. The syntactic and semantic differences
between two major chicken versions are subtle and try to make
eggs compatible over all of them is impossible - nobody can keep this
in his head. The only reliable method is to maintain the eggs
for the current release, and only to critical fixed for old releases.

> 
> > I'm actually not frustrated about people complaining: I'm frurstrated
> > myself (and complain). I can't find a much better solution right now.
> 
> I see.  I agree that we should try to fix the problem.  It has bit me
> in the past, I must confess.

It has bit us all. The problem is: I am a user too! I use for example
hato at work. It is of critical importance to me. I can't afford
any egg to break, and if I move to another machine, setting up
my environment I expect eggs to build and work out of the box.

> 
> > No. Too much can break. I'd rather do that myself. If anyone touches
> > the stuff, we have 3 weeks of chaos. No way. We need stability
> > much more than we need the perfect repo layout.
> 
> What if someone makes the changes in a copy and sends you the patch?
> Would you be willing to review them and, if they look good, apply
> them?
> 

Yes. I'd review them at least.

> I would say even a break of 3 weeks once could be worth if it reduces
> the potential for confusion and chaos in future times.
> 

Absolutely not. 

> > >  I'm also shocked to see that for each egg that I maintain now there
> > >  are two trunks.  That's 44 trunks for me.  Which one should people
> > >  commit to?  What if they commit to the wrong ones?
> > 
> > To repeat: You should maintain the one for the current released major 
> > version.
> 
> But shouldn't the semantics of the repository reflect that then?
> Right now we're left with a different trunk for each Chicken release,
> even if the policy is that we're only releasing for the latest one.

Indeed, as a backup, and for applying fixes, should it be required.

> 
> I would say that even if we decide to use separate branches of each
> egg for each release, we should probably use egg/branches/chickenN
> (where N is in the set { 2 } right now, { 2, 3 } when there's a new
> major release, etc.) and similar for older releases (and come up with
> some simple way of making releases for those branches, such as a
> tags/chickenN/ directory).  Umm, what do you think of this approach?
> (I would still prefer the “supported-releases” approach for the single
> reason that in this approach, “egg v1.2” is still ambiguous,
> potentially refering to different code bases).

I don't see much of an improvement over the current layout.

> 
> > >  What percentage of the eggs in /release/3/ are currently different
> > >  than those in /?  5%?
> > 
> > That's not important. Consider the older releases obsolete. Forget
> > about them.
> 
> 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).

I have seen too many installations break with new features that depended
on the chicken version.

> 
> > >  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.
> > 
> > There must be progress. Bugs get fixed and new features added. Unless
> > one has a serious reason, upgrading to a new major release is acceptable.
> > If one requires an older version, it can still be obtained and installed
> > with a different PREFIX.
> 
> I agree that there must be progress, but I think we should let people
> upgrade at the leisure, instead of forcing them to (as long as doing
> this doesn't put any significant burden on us, which, at least
> speaking for my 22 eggs, it doesn't).  The “only release eggs for
> last Chicken release” policy forces me to force my users to upgrade.

Nobody is forcing anybody. The eggs for a major release branch should
just work. If someone wants new features, he can either upgrade his
chicken version or download the egg manually (and risk trouble because
of incompatibilities).

Alternatively, use "svn merge".

> 
> > >  All the 3 proposals I made still had this possibility.
> > 
> > Yes, but they introduce more work and we already have enough things
> > to do right now.
> 
> They may introduce more immediate work, as they require changes to the
> post-commit infrastructure.  However, I believe they will, ultimately,
> save us time by making the repository layout a bit more logical and
> easier to manage.  They would also, IMO, make it more pleasant to work
> with.

Ultimately it is more important to keep things working for the user.
Our pleasure as maintainers is not important. I also find nothing
illogical about release/N branches.

> 
> I am volunteering my time to work on a patch to the post-commit
> infrastructure (that —since you're saying you're not willing to let
> anyone other than you change it— you would have to review) to support
> any of the alternate schemes (HA!  I can do it to!) such as the
> /egg/branches/chicken2 and /egg/tags/chicken2/1.0/ or the, IMO
> preferable, supported-releases extension to .meta files.

My first impulse is to say "what the heck! let him do it." There are
10000 other things that I would enjoy doing rather than twiddling
with chicken code. But I still identify with this project and this
constant breakage, this eternal 
"hey-lets-add-a-new-feature-and-break-everybodies-code",
this futzing and fiddling and restructuring annoys me
to no end. Why can't we simply keep things working? Why can't we just
make this crap work reliably? Why can't we simply keep things simple
and transparent? Or at least not add more structure and bells and whistles
and options and...

Man, this is so frustrating. I don't know how long I'll put up with this.

(no offense - but software sucks because everybody
just wants to twiddle and enhance and whatnot)

> 
> So.  If you still think that the release/3/ idea is better than all
> the alternate proposals that I've made (while volunteering my time to
> implement any of them that we pick) and don't want to continue
> discussing this subject, I'll leave it at that. 

The release/3 idea is certainly not perfect. I'm completely aware of
that.

> I don't want to cause
> you to waste any time and I certainly don't want this to become a
> source of frustration for you (which, judging by your message about
> the dangling links and grep, I'm afraid it may be starting to become).

The link issue has nothing to do with this. It's just another "bad feature".

I apologize for sounding so harsh, and you have been (as usual) very
friendly and sensible. It's just that I feel that nobody understands me, even
though I'm right. :-)

> I am genuinously concerned about this change because I think it will
> make it a bit harder to create and maintain eggs, 

Debatable.

> it gives the
> chicken-eggs repository some unusual semantics, which cause confusion,

I don't think so.

> and it violates the assumption that a given version of some software
> (eg.  “egg v1.2”) umabiguously refers to one particular codebase.

A full version of some software must include the versions of all it's
dependencies. This is currently not done in general (unless you use
a chroot'ed build systems and cryptographic hashes to identify exact
versions, something we do at my workplace) and not applicable here.
So version numbers are ambiguous anyway.


cheers,
felix