chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Re: repository branching


From: Alejandro Forero Cuervo
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Fri, 22 Feb 2008 02:38:25 -0800
User-agent: Mutt/1.5.13 (2006-08-11)

> To keep egg sources for released but old versions, with the option
> of maintaining them. It's quite frustrating (as all of us know), that if
> I reinstall some eggs (say on a new machine), and those eggs
> use features that are only supported in newer chickens.

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?

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.

> >  This change is not only inconsistent with the way most svn
> >  repositories tend to be used and redundant with the standard practices
> >  of /tags and /branches, but it puts a burden on the maintainers, when
> >  I think we ought to be striving for the opposite goal.  Maintainers
> >  are short on time; we shouldn't waste it by forcing them to spend some
> >  of this sync'ing multiple directories and increasing the complexity
> >  associated with their eggs.
> 
> 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?

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 find it shocking to see that I now have:

  stream-wiki/tags/1.1
  stream-wiki/tags/1.2
  stream-wiki/tags/1.3
  stream-wiki/tags/1.4
  stream-wiki/tags/1.5
  stream-wiki/tags/1.6
  stream-wiki/tags/1.7
  stream-wiki/tags/1.8
  stream-wiki/tags/1.9
  stream-wiki/tags/1.9.1
  stream-wiki/tags/1.9.2
  stream-wiki/tags/1.10
  stream-wiki/tags/1.11
  release/3/stream-wiki/tags/1.1
  release/3/stream-wiki/tags/1.2
  release/3/stream-wiki/tags/1.3
  release/3/stream-wiki/tags/1.4
  release/3/stream-wiki/tags/1.5
  release/3/stream-wiki/tags/1.6
  release/3/stream-wiki/tags/1.7
  release/3/stream-wiki/tags/1.8
  release/3/stream-wiki/tags/1.9
  release/3/stream-wiki/tags/1.9.1
  release/3/stream-wiki/tags/1.9.2
  release/3/stream-wiki/tags/1.10
  release/3/stream-wiki/tags/1.11

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?

What percentage of the eggs in /release/3/ are currently different
than those in /?  5%?

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

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

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

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.
http://azul.freaks-unidos.net/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]