[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: release.sh - I cannot do it.



>>>>> "Ben" == Ben Collins <bcollins@debian.org> writes:

    Ben> On Tue, Mar 07, 2000 at 06:48:47PM -0800, Karl M. Hegbloom wrote:
    >> >>>>> "Ben" == Ben Collins <bcollins@debian.org> writes:
    >> 
    Ben> On Tue, Mar 07, 2000 at 03:05:14AM -0800, Karl M. Hegbloom wrote:
    >> >> 
    >> >> I am not going to be able to finish what I started on that script.
    >> >> It's a total kludge to have to move the files into place like that.
    >> >> The Makefile ought to put them where they belong to begin with.
    >> >> 
    >> >> Revert it, fix it, do what you will with it.  I'm not for this.
    >> >> `release.sh' is a crock.
    >> 
    Ben> Are you saying you broke it and are leaving it for some one else to mess
    Ben> with?
    >> 
    >> Useing a script to move the files into a release stage tree like that
    >> is a crock.  The Makefile and scripts that build the images should
    >> put them where they belong to begin with.
    >> 
    >> I have to look for work this week.  I will not have time to work on
    >> boot floppies anymore.  I'm behind on my bills and have to do
    >> something about that or I'll be living out of a backpack by spring.
    >> 
    >> As far as `br_woody_exp' goes, if you don't like it lump it.  I think
    >> that what needs to be done in `boot-floppies' is that the build
    >> system needs to be overhauled and that's what I've started in that
    >> branch.  I could not do what I did on the trunk right now since it is
    >> being used for Potato.  It was a choice between starting a repository
    >> of my own and vendor tracking, or creating a branch in the shared CVS
    >> repository.  If you don't want my help or don't like my work, say so
    >> and I'll split.

    Ben> What we don't want is developers coming in and changing things so
    Ben> drastically at the expense of delaying release for no real gain in the end
    Ben> result. What we had worked, and now it doesn't. The fact that you are now
    Ben> telling us you wont have time to fix it, is irresponsible on your part.
    Ben> THe entire release hinges on working boot-floppies, and leaving it in this
    Ben> state is simply wrong.

 It would be irresponsible to sit here at home all day working for
 free when I should be out earning money to pay my bills and save for
 college.

 You were not on IRC yesterday when we decided that I should check in
 what I had, broken or not, so that the others could help get it
 working.

    Ben> I don't personally like to refuse help, but if you continue to lack the
    Ben> responsibility you have to fellow developers, then I would just as soon
    Ben> not ask for help. You breaking this and running out on the problem is not
    Ben> our fault. Heck, the whole idea of CVS is so you can develop locally, then
    Ben> not screw up everything else in the mean time, and on top of that Adam
    Ben> asked that we revert to fixing bugs to stabalize the boot floppies, not
    Ben> change the whole system around to satisfy somes ones pet peaves.

 Mail me a check, and I won't have to "run out on the problem".

 It had to be changed because `dbootstrap' was looking for a
 nonexistant file.  It was looking for a file like `rescue-2.2.14.bin'
 rather than for plain `rescue.bin' because of the "kver_suffix" and
 the hard coded KVER that it had before I performed the minor surgery
 on "main.c".  The /proc/sys/kernel/osrelease did not match the KVER
 built into `dbootstrap', so it added the suffix.  Perhaps it only
 showed up in the CD-ROM I built?  It was when installing into a
 vmware from my second try CD burn that I discovered this bug.  Please
 browse http://cvs.debian.org and look at what I did with "main.c" and
 "dbootstrap.h".  Read the spec I emailed to the debian-boot list a
 few days ago, and see how the files are to be named and such...  Is
 that a destabalizing modification???


Reply to: