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

[Jonathan Steffan]

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


> 
> > 
> >   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.


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 ]

>>> 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. ;-)

Jonathan Steffan
daMaestro