Re: [Chicken-hackers] Re: repository branching

[Alejandro Forero Cuervo]

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.

> >  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'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.

> 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?

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.

> >  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.

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).

> >  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 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.

> >  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.

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.

> >  On the other hand, we shouldn't duplicate the size of the repo when
> >  there are other solutions.  I currently have a checkout of the entire
> >  repo in the 5 machines (my laptop, my home directory in the NFS server
> >  where I work, freaks-unidos.net, galinha and fsfla.org).  This is
> >  clearly harming me.  That said, the main reason I oppose this change
> >  is *not* the size of the checkout.
> 
> If we have 5000 eggs, would that harm you? Are you expecting the
> repository to grow and always would want to have keep a complete checkout?

If we have 5000 eggs that provide useful code, I will probably still
want to keep a complete checkout in my 5 machines (but I don't know if
I'll be able to, we'd have to wait and see).  But if we have 5000 eggs
and 5 major releases, I will probably be unable to have the complete
checkout (but, again, I don't know).

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.  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).
I am genuinously concerned about this change because I think it will
make it a bit harder to create and maintain eggs, it gives the
chicken-eggs repository some unusual semantics, which cause confusion,
and it violates the assumption that a given version of some software
(eg.  “egg v1.2”) umabiguously refers to one particular codebase.

Thank you for your attention.

Alejo.
http://azul.freaks-unidos.net/