Re: [Chicken-hackers] Re: repository branching

[felix winkelmann]

On Fri, Feb 22, 2008 at 11:38 AM, Alejandro Forero Cuervo
<address@hidden> wrote:
>
>  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?

>
>  I can understand your frustration at having people complain about
>  failing to install a version of an egg that uses new functionality in
>  an older Chicken release, but I think you can find a *much* better
>  solution.  I would rather put up with people continuing to sometimes
>  complaining about this than with the current change.
>

I'm actually not frustrated about people complaining: I'm frurstrated
myself (and complain). I can't find a much better solution right now.

>  >
>  > Sorry, I may sound somewhat stubborn on this, but the whole machinery
>  > to automatically upload eggs on changes is already quite complicated and
>  > in place and working and I'm not going to change it (only extend).
>
>  What if someone else does?  What if I volunteer to change it myself?

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.

>
>  It does sound stubborn.  I think investing a bit of time *once* in
>  adding the logic for the optional "supported-releases" to this
>  infrastructure would make a lot more sense than having each maintainer
>  have to deal with having each version of a given egg copied all over.

I don't think it is that bad, really.

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

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

>
>  > While I admit that the current layout is a bit confusing, I don't
>  > think the complexity is "overwhelming": just don't worry about older
>  > releases.
>
>  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.

>
>  > But we still have the possibility to maintain eggs for old releases
>  > in a relatively simple manner, and this is crucial.
>
>  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.

>
>  > Repo checkout size shouldn't be a showstopper. Just checkout what you
>  > need or use svn externals.
>
>  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?

>
>  Alejo, who, very frustrated by this change, will probably be going
>  back to maintaining the code for his eggs in his own repository and
>  starting treating the chicken-eggs repos simply as a place to copy
>  stuff to to when he needs to make things installable by chicken-setup.
>

A possible working solution. I work with many eggs and find the
current layout acceptable in practice. This of course may be purely
because we have different way to work with the repository.

I grateful for your honest remarks, and I take them very seriously.
Please accept that my opinions differ for this particular subject.


cheers,
felix