Date:	Sun, 17 Nov 2013 09:44:38 +0100
From:	Jonas Bonn <jonas@...thpole.se>
To:	Olof Kindgren <olof.kindgren@...il.com>,
	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kevin Mehall <contact@...inmehall.net>,
	linux <linux@...ts.openrisc.net>
Subject: Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

Hi Olof,

I think this discussion is veering away from what's relevant for the 
linux-kernel and devicetree lists and did consider dropping them at this 
point... but let's leave them in the discussion a bit longer in case 
there's some sage guidance to be found there on the topic of doing sane 
versioning of open source hardware.

On 11/16/13 12:01, Olof Kindgren wrote:
> 2013/11/16 Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
>> On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
>>>> +
>>>> +    i2c0: ocores@...00000 {
>>>> +            #address-cells = <1>;
>>>> +            #size-cells = <0>;
>>>> +            compatible = "opencores,i2c-ocores";
>>> Version number needed.  OpenCores wanted "projectname-rtlsvn###"
>>> where ### is the SVN commit number of the RTL directory in the
>>> project's source repository.
>>>
>> That will also require a change to the driver.
The drivers in question aren't upstream so it's not a big deal. Making a 
change to get sane revisioning would be worth it anyway.

>>
>> Using svn commit ids as version info seems a bit too fine grained to me,
>> but if that's what's agreed on, then it should be the commit id from the
>> projects official repository at opencores.org I think.
The DTS version tells the driver what feature set it can expect to find 
in the HW core and thus how to go about driving it.  Normally, the core 
won't change features much, but if you add something new you'd want the 
driver to see a new 'compatible' tag so that it knows which features it 
can/should enable.  New features will always entail driver changes; and 
a driver can always be compatible with both the old and new HW versions 
by just enabling the feature set appropriate to the HW in question.

>>
>> Stefan
>> _______________________________________________
>> Linux mailing list
>> Linux@...ts.openrisc.net
>> http://lists.openrisc.net/listinfo/linux
>
> I agree. I don't like doing versioning with revision numbers. It's too
> closely tied to the currently used VCS. The problem is that no one has
> bothered to do proper releases of the cores for the last ten years or
> so.
>
> But since we are talking about a relatively small amount of cores
> here, I think it could be worth to take a quick glance to see if the
> latest SVN version is compatible with the latest tagged release. I
> would suspect that is the case for the majority of the cores and the
> we can just use the latest tag as version. For the other cores we
> could
> 1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
> 2. Take over maintainership/fork and just release what's in the trunk
> (taking over maintenance is preferrable here to avoid  more repo
> confusion)
> 3. Use SVN revisions
>
> option 2 would be my preferred choice here, given that we get someone
> to do the actual work. I could probably help out with a few of the
> cores

My suggestion:
i)  Move the primary source of these cores to git (doesn't matter 
where... github is fine)
ii)  Use a shortened git commit ID (6 chars) as the version number

Why?

i)  The commit ID is independent of the repository; whether the repo is 
opencores, github, or olof's computer, the commit ID is constant
ii)  Tag names are arbitrary labels; they don't contain any more 
information than the commit ID
iii)  The commit ID,  being a hash of the source and repository history 
itself, contains information that makes it effectively impossible for 
someone to attach the same label to an incompatible core
iv)  I think everyone actively working on these cores today are doing so 
via git already... via orpsocv2/3, presumably

NB: you might do named releases of a core, from versions 1.2 to 2.5, but 
if the underlying feature set remains the same and the same driver 
applies then the DTS 'compatible' tag would remain constant across all 
these releases.  This means that the HW feature set is decoupled from 
the arbitrary version numbers that people like to use when doing releases.

> Jonas, you said that opencores wanted projectname-svnversion. Do you
> know where that comes from? My proposal here would conflict with that
It came out of a private conversion I had with Marcus Erlandsson (who 
spoke for OpenCores at the time).  The OpenRISC project hadn't really 
moved on to git back then (as it has today) so it was the best we could 
come up with.

/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists