Re: [Chicken-hackers] Distributed egg repo proposal

[Imran Rafique]

On 18 March 2011 10:08, Peter Bex <address@hidden> wrote:
> On Fri, Mar 18, 2011 at 10:02:17AM +0000, Imran Rafique wrote:
>> On 18 March 2011 09:20, Peter Bex <address@hidden> wrote:
>> > On Fri, Mar 18, 2011 at 09:00:20AM +0000, Imran Rafique wrote:
>> >> Dynamite is popular, and gets repeatedly forked on github.
>> >
>> > Forking's bad, mmmkay?
>>
>> Are you lecturing me, or the denizens of github?
>
> It's long been general wisdom that forking should be avoided at all
> costs, not because of technical reasons but because of social reasons.
>
> So yes, I think the way github's promotes rampant forking is bad.
> See also http://sheddingbikes.com/posts/1299555462.html  and
> http://producingoss.com/en/forks.html
>
> If a fork is made that's okay, but *only* as long as that fork is
> short-lived and integrated back into the mainline tree.  And in the
> long run that means you probably want to wait for that event before
> starting to use that code, generally.  If not, you will only have
> to use the "forked" repo temporarily.

Well, its all down to the social aspects of open-source, as you
pointed out. The key reason why I thought of translating something
portage-like to chicken eggs is I really think it offers maximum
flexibility (with not too much overhead in tooling - the original
portage tooling was a *lot* simpler than it is today). These points
regarding forking were just illustrations of just how much additional
flexibility it could give, if you really wanted to push it but still
stay within the confines of (as Felix called it) "The System" :)

They're not the main selling points of a portage-like architecture,
which really are:
* clean seperation between upstream sources, and the framework needed
to organise and distribute them
* but still have easy access to upstream repos (the tool just makes it
easy for you to clone, provided you have the necessary local VCS tools
to do so)
* require as little "bookkeeping" work as possible to submit eggs
* ensure no broken deps, once *pkgs* is seeded.
* make it easy to fix broken eggs at the global tree level, if we
can't wait for the fixes to be propogated upstream and then pushed
back in the normal manner.

But now I'm just repeating myself again, and clogging up this thread
from perhaps more closer debate on your specific proposal :)

(and btw, the generally accepted scenario where the main chicken devs
patch a number of eggs which are trivially broken by a new chicken
update - thats also a fork from upstream)