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: Peter Bex
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Fri, 22 Feb 2008 12:49:03 +0100
User-agent: Mutt/1.4.2.3i

On Fri, Feb 22, 2008 at 11:59:27AM +0100, felix winkelmann wrote:
> 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?

It applies for that egg in which the meta file is, whatever the version
you're looking at.  You'd only need a simple indexer that looks inside
meta files and can produce a list of chicken <-> egg version matches,
just like you currently need a simple indexer that can produce a list
of release subdir <-> egg tags.  The more release you'll get, the
slower the current one will get as it will need to traverse more
directories.  The other one will not need to do a lot of extra work
because it will need to read one more s-expression from the same file.

> 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 think Alejo's solution is a much better one.

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

I doubt this will be too much trouble to do.  This can be done pretty well
by writing a little script that checks for each egg in what trunks and
branches release dir they exist and then write that to the meta file.

This will still have to make assumptions as to the exact version of the
2 release eggs in toplevel require, but this is no worse than the current
situation (there is no minor version encoded in the release dir, which
causes real problems as I have personally experienced -- see my other
post).

> That's not important. Consider the older releases obsolete. Forget
> about them.

If you are making simple changes it's a lot better to have these propagated
to an older version for people who are still on that version.  In the
current situation you'd have to copy it over.  In the situation Alejo is
suggesting it would 'just work'.  Whenever you start making major changes
of which you're not sure they'll work in the older version (_or_ you start
making changes of which you are sure they _won't_ work in the older version)
you can delete that version from the meta file in trunk.  When you push
a new release of the egg, that version of the egg will only be available
for the latest chicken.

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

Minor bugfixes should not require a lot of manual work to backport the fixes
to the older chickens *and* make a new release on all those older chickens
if you know it will still work.

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

See my remark above.

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

Obviously that's currently not possible, but I'd much prefer to keep
a complete checkout (I actually do have a complete checkout of toplevel,
on my development machine)

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpe1EHNzExTV.pgp
Description: PGP signature


reply via email to

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