On 01/22/2012 06:13 PM, Karanbir Singh wrote:
> Hi Guys,
>
> I was pointed to this thread by someone, am glad they did. I'm keen on
> helping and can push some resources this way.

I'm not speaking for ScientificLinux (nor could I), nor even Ascendos, 
but personally I thank you for this attitude and any future help, as 
amongst the pool of potential contributors to solving this problem, you 
are clearly right at the top as far as relevant abilities and experience go.

>
> On 01/21/2012 11:39 PM, Douglas McClendon wrote:
>> First, where I alluded to 'choice b' I meant 'decision b' as a couple
>> sentences later I define an actual choice b.  Second, the bit about
> ...
>> build all of the 6.0 packages.  So rebootstrapping the minbuildroot as I
>> described, while sounding good in some ideal theory way, probably won't
>> work without significant alternate workarounds to the issues that
>> currently require F12/F13/RHEL6Beta for various package build deps. Thus
> ...
>> likely you'd modify them such that you don't need all those
>> F12/F13/RHEL6beta initial bootstrap binaries (thus reducing your input
>> complexity/threat surface).
>
> The fact that multiple bootstraps are needed are by far the easiest of
> the issues to resolve. And actually, that's not true. Multiple Distro's
> were not needed to achieve the desired result, but was the easier option.

This was near to my own understanding as well, though having you voice 
it certainly instills confidence in the path, and likelyhood of wider 
buy-in.  But for the first pass, getting something down that had been 
done, and known worked for SL6, clearly made sense.

>
> The larger and more difficult issue to solve is the in-time-root-traversal.

That seems like a cryptic short single sentence comment.  I can make 
some guess as to what you refer to, though in my guess I don't consider 
it a large issue because I don't see even a quadrupling of total build 
time to be a 'large' issue.  Though quite likely I'm not thinking of the 
same, or precisely the same thing you are.

>
>> Anyway...  again, just trying to give people a feel for the real scope
>> of the issues at hand.  My own engineering strategy is to get _any_
>> deterministic process laid down and producing remotely-reasonable output
>> first, then to easily go and tweak the fully automated/coded build
>
> Firstly, what/where is your assert() going to take place ?
>
> Secondly, what/where is your assert() going to take place without
> inheritying legal liability ( both internally and downstream to userbase )

These both go beyond cryptic toward me wondering if anyone (or 
everyone?) else here has any idea of what you are talking about.

>
>> process towards a more optimal/puritanical path iteratively after that.
>>   Ideally such that by the time EL7 comes out, the turnaround time for
>> updating the deterministic buildscripts is really short, because all
>> these issues have been tackled and solved in code for EL6 already.
>
> EL7 is again going to be a different ballgame, however we are taking a
> few steps in the CentOS side of things to try and get a few bits further
> automated.

Of course, but I think you're overselling it more than I undersold it, 
but no matter...

>
> ( I need to catchup with some of the links mentioned in the thread so
> far, lots of things that I've never come across before + time is in
> short supply, but will try to keep up )

I'm kindof not in a hurry myself.  Or rather, getting you involved like 
this I consider sufficient to call a good months work on the project*.

* Now for my core reply to this good news and opportunity to decide on a 
collective general direction for further development/progress-

More disclaimer- I'm just a guy whose trying to get certain things done. 
  What follows is just my advice to those who agree with whatever 
subsets of those goals as are relevant and useful to consider.

So as a start, it seems we've got some buy-in from folks representing 3 
EL-rebuild groups amongst the list LWN reported.  As a start, to 
determine my own further path of contribution to the solutions we 
collectively seek, I'd like to hear both CentOS's and ScientificLinux's 
assessment of recent related work done by Ascendos and GoOSe (and 
others?) as it relates to these issues.  I'd also like to hear both of 
their stories as to how they would ideally envision such a solution, 
especially where that might differ from what I've done or planned to do.

And to confess/disclaim- my current

git://github.com/dmcclendon/Ascendos

'el-build' solution is very much an unpolished, hack and slash, barely 
working* outline of a solution.  * with a dozen line patch could 
probably actually produce working output up through 6.0 and 6.1 iso 
output and most further updates, with the 6.1-x64 installer output 
possibly being uselessly buggy.

But it is a solution to I think the core problem, and I still believe, 
with a bit further motivation/funding/community-buy-in, could provide 
exactly what I want, and what my humble or not opinion is of what 
RH/CentOS/ScientificLinux/Ascendos/GoOSe/... should want.

But if you want to scrap it, design and implement something else a bit 
more formally, my ego can handle that, as long as I really do come to 
believe that the new solution will actually get the problem solved 
sufficiently in a timely manner.

-dmc