Re: [ECOS] Re: Replacing CVS - decision time

[Alex Schuilenburg <alexs at ecoscentric dot com>]

Daniel NÃri wrote:
> [...]
>>> I'm not sure what you mean by "official forks", but there are plenty of
>>> options for those who can't or don't want to host their own
>>> repositories:
>>>
>>>  http://mercurial.selenic.com/wiki/MercurialHosting
>>>       
>> What I want is a way for forks of eCos to be organized in a way that
>> they are available to everyone. Does using hg mean that we get
>> this feature?
>>     
>
> Yes, it's a DVCS so anyone can create a fork/clone/branch and publish
> it, e.g. using one of the services on that wiki page.
>   
I don't like the idea of just anyone creating an "official" public
fork.  One of the most important aspects of eCos IMHO is that it is
fully attributable and has proper assignments in place.  Neither the
maintainers or ourselves wish to find ourselves subject to a lawsuit
brought on some organisation who thinks they have been robbed either of
IP or code or both because there has been a lack of code assignment and
licensing.  As I have mentioned several times before on this list, users
should be able to pull code off the official site confident in the
knowledge that they can use the code freely, subject to GPL+ex of course.

Of course one of the main reasons for switching to a DRCS is to enable
better collaboration of eCos projects and ports. DRCS' provide this,
allowing users to easily exchange changes and keep in sync with each
others developments, all the while maintaining a hook back to the
official repo such that the work can be contributed back easily and that
the project can easily be kept upto date with official developments.  I
thus envisage these developmental repos to be shared more between the
developers rather than being made an "official" repo,with the final
intention of contributing the work back to the official repo and hence
dissolving any further need for the developmental repo. I would not like
to end up in a situation where you have to go to site x to get support
for target y or feature z, and so on, and never knowing exactly what the
quality of the port was. It would be far better to see target y/feature
z being contributed back to the official repo since the maintainers
provide a high level of coding standard for contributions and ensure
that compatibility is maintained and do a fine job minimising risk of
changes breaking the world elsewhere. And of course it keeps the
assignment policy in place.

I also dont see any advantage moving off sourceware.  Maintaining a DRCS
site is certainly not as hard as you think (well, a hg site anyway - I
cannot comment on git) and IMHO the maintainers will have far greater
control over the DRCS behaviour than they would by the other sites on
offer.  For example, the ecos website is kept in CVS (yes, cvs commit's
push out live web pages) so it simply makes sense so switch that to the
same DRCS system. This kind of relationship on the same host brings with
it a lot of benefits. Of course you could also argue that the site
should rather be in a wiki, but that discussion is for another time ;-)

-- Alex Schuilenburg
Managing Director/CEO                                eCosCentric Limited
  
  ** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  ** 27-29 April 2010, Booth 640, San Jose McEnery Convention Center **



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss