The worry is that if we (Lenovo) did a 2.10.1 release, it may not be validated 
well on POWER.  Also vice-versa, that Lenovo's test schedule doesn't line up to 
the upstream releases.  The version numbers should indicate the provenance of 
the package, but not necessarily imply one is better than another 'upgrade' 
wise.

Analagous to running a 'distribution' kernel versus kernel.org kernel, but 
hopefully with less variation than they tend to do (no more than maybe a 
handful of commit difference).  Running kernel.org is a valid thing to do, but 
it's frequently just easier to run a distro kernel.

Note we are simply exploring the option at this point, but have had some 
difficulties and this is one thought that came up as a way to simplify.  We 
also are thinking we should set up a consolidated repository including some of 
the Lenovo specific/third party utilities that we offer support for, but 
currently require independent download of those tools.
From: Michael Robbert [mailto:[email protected]]
Sent: Friday, November 20, 2015 11:44 AM
To: xCAT Users Mailing list
Subject: Re: [xcat-user] Lenovo xCAT releases...

That sounds like it would be a support nightmare. Unless I misunderstand how 
you’re going to do this it sounds like there will be 2 different releases of 
2.10, and every version thereafter. If I’m running 2.10 from the ‘main’ release 
and you’re running 2.10 from ‘lenovo’ release we may see different 
functionality based on the fixes included in each 2.10. If you’re going to 
differentiate the name in the version string that might work, but why not just 
call it 2.10.1?

Mike

On Nov 18, 2015, at 3:49 PM, Jarrod Johnson 
<[email protected]<mailto:[email protected]>> wrote:

I wanted to get some feedback on opinions of how to manage a potential 
different set of releases….

Our testing group at Lenovo may not line up as well with the 'main' release 
cycle, so we were thinking of actually doing releases on a different cycle.  
Still use the same github repo, just test on a slightly different cycle…

For example, maybe we would release a 2.10 point release with backported fixes 
from 2.11 prior to release of 2.11.  Nothing too dramatic, just a relatively 
conservative way to get fixes into the most recent stable branch on our 
schedule….
------------------------------------------------------------------------------
_______________________________________________
xCAT-user mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/xcat-user

------------------------------------------------------------------------------
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user

Reply via email to