[Fedora-livecd-list] [PATCH 6/6] Several Kernels

Douglas McClendon dmc.fedora at filteredperception.org
Tue Aug 7 05:05:27 UTC 2007


Jonathan Steffan wrote:
> On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote:
>> Jeroen van Meeuwen wrote:
>>> Douglas McClendon wrote:
>>>> I think your arguments Jeroen would be more valid if you had a little
>>>> more patience.
>>> Believe me, this has been going on for quite a while.
>> I've been on this list for years (jdogalt).  Believe me, I've got my own litany 
>> of issues.
>>
>> But from where I'm standing, it does look like you threw up 6 patches without 
>> much obvious design discussion beforehand, and you are getting too upset too 
>> quickly.
>>
>> Since the livecd-creator bits are what is used to build the official fedora 
>> releases, I do think there should be a fair amount of resistence to changes.
> 
> I'm not at all against resistance to changes that might not be quite
> ready. I am against hindering innovation, in any form, or minimally
> causing discouragement because we have taken on code that helps us do
> what what want to do with software, even when upstream is not ready for
> us to. :-D

It's a subtle thing, but I would take the lack of upstream merging as an 
absence of encouragement, and not the presence of discouragement.


> 
> 
>>>   I.e.  I don't remember seeing much design-debate over
>>>> the current contentious issues.  And it's only been a couple days since
>>>> you posted the patch.  *And* revisor appears to already be working off
>>>> of its own copy of pilgrim.py (as I figured out when I wondered why the
>>>> patches were still using that name).
>>> Right, that pilgrim.py is getting us ugly faces everywhere. Working with
>>>  us is a matter of principle for these guys. All we need is the '-' to
>>> be removed from the 'livecd-creator' command.
>> Can you explain this a bit more?  I am not a seasoned python programmer, but 
>> that sounds like a _really_ strange issue to me???
> 
> 
> It's a matter of livecd-creator not wanting to be imported and
> subclassed. Ignore that the sys.path.append() is more then nasty, but it
> does help to illustrate discussion we have had in the past around the
> time of the Fedora 7 release. The revisor team has wanted the livecd
> bits to be importable (in a similar way that pungi has allowed us to)
> and when that was denied we had to make the controversial decision to
> pull the full source into revisor. My understanding, at least this is
> what I took from the discussion, is that livecd-creator is just not
> ready to be imported and is offering nothing resembling a stable
> API/code base. This didn't bother us at all, we were willing to fix any
> issue that arises from changes in livecd-creator and the way we utilized
> the code in revisor. To just move on and start getting things done, we
> brought all of livecd-creator into revisor and named it pilgrim.py. When
> we move to do a release we try our best to rebase and then submit our
> changes upstream, hoping to help mature the API/code base far along
> enough where we are allowed to import and utilize it.
> 

It sounds like this is a perfect example of when forking works.


> 
> Consider the following:
> 
>>>> import sys
>>>> sys.path.append('/usr/bin')
>>>> import livecd-creator
>   File "<stdin>", line 1
>     import livecd-creator
>                  ^
> SyntaxError: invalid syntax
> 
> Now, without the dash:
> 
> Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ]

ln -s /usr/bin/livecd-creator /usr/lib/livecd-creator/livecdcreator.py

would be quite a bit less yucky.

> 
>>>> import sys
>>>> sys.path.append('/usr/bin')
>>>> import livecdcreator
>>>>
> 
> You could then continue on with:
> 
>>>> myubercoolliveimage = livecdcreator.InstallationTarget(options.more,
>                                                            options.yeah)
> 
> At this point you have access to the needed toolchain with your
> 'myubercoolliveimage' and also allows us (revisor team) to make our
> changes much more gracefully by subclassing or overriding functions
> almost as a proof of concept. Forgive my rudimentary example, but most
> of the reason why we have just brought all of livecd-tools into revisor
> is to not waste a *ton* of time on discussions just like this one. I'm
> not saying I don't find value in this type of good, open debate... it is
> more I personally work better expressing what I would like to see
> software do by at least getting some sort of code down. Some of the
> things we are doing in revisor might seem elementary and, also,
> underdeveloped but we are trying to work out a feature rich application
> that has both a fully functional CLI and GUI mode that puts an amazing
> amount of power right at the end users hands. I'm trying to not fuel the
> fire here as we all have much more productive things we can be working
> on. ;-)

+1 for forking.  Personally I'm sitting on a few thousand lines of bash 
code that duplicates the functionality of livecd-creator myself (they 
just run about 6 times slower, but have a few beneficial aspects that I 
think may eventually be worthwhile for a larger audience).

I'm quite optimistic that 2 years from now, fedora will have (at least 
one) really excellent livecd generation program, which uses great 
features pioneered by everyone on this list.

To quote some of the last lines of perhaps my favorite rock opera-

"we can walk our road together,
if our goals are all the same.
we can run alone and free,
if we pursue a different aim."

-dmc





More information about the livecd mailing list