[Queue-developers] new project admin for GQ? [was: Re: GNU Queue]

[wernerkrebs <wer...@ya...>]

Hmmmm, what you say sounds good, but I think this
discussion should be moved to queue-developers, as I
think it might be taking place in a vacuum.

----------------------------------------------------------------
Werner G. Krebs, Ph.D.,
Technical Specialist           
 
Personal website: http://www.wernergkrebs.com
----

--- Koni <mh...@co...> wrote:

> Hi Werner,
> 
> Thanks for your response. I guess I should clarify
> for Mike here that I
> don't mean to sound like I want to take things over.
> What I do want to
> do is make it work like it must have at one time, as
> outlined in my
> previous email. This is all primarily motived by
> needs I have right now,
> as well as another group here on campus that may be
> interested after
> those goals are accomplished.
> 
> I am undecided as to whether its worth the trouble
> for my own needs here
> given that there are other options out there. I must
> say I just really
> like what I've read from the online docs for GQ, and
> I don't really like
> what I read for condor and other options I've
> encountered so far. What
> would tip the balance for me is if my efforts to do
> this could feed back
> to the well known project named "GNU queue" as
> opposed to totally
> unknown and probably never to be discovered GQ
> derivative under a
> different name, or something that is just used
> locally by myself and my
> collaborators but not publically released.
> 
> That I guess depends on whether there is a
> perception that there are a
> lot of people like me out there using small but
> dedicated linux-based
> clusters, and whether or not what I'm proposing is
> compatible with
> existing plans. I don't mean to barge in, just
> trying to figure out
> whether or not I should keep trying to make GQ work
> here or not. What I
> would do would probably totally break any existing
> attempts at
> checkpoint support as I don't think its worth the
> trouble to do this.
> Perhaps it could be attempted again on a new code
> base using what was
> learned from before.
> 
> Cheers,
> Koni
> 
> On Fri, 2005-04-22 at 13:23 -0700, wernerkrebs
> wrote:
> > Hi Koni,
> > 
> > Nice to hear that you're interested in GQ!
> > 
> > Yes, I formally signed off on the project some
> time
> > ago as a result of working for the University of
> > California, whose polices on IP created by
> employees
> > is famous for being less than GPL-friendly. (And
> now
> > I've changed jobs again.)
> > 
> > Mike is the current project admin.
> > 
> > Last I heard --- which was some time ago --- he
> was
> > still very interested, and doing all sorts of cool
> > stuff in the CVS tree. 
> > 
> > (I think he was doing most of the work in the
> > queue-development branch, which should have the
> latest
> > versions. One problem with SourceForge is that it
> is
> > impossible to rename a CVS branch, so if you start
> to
> > deposit stuff in a branch whose name is
> > less-than-ideal, it tends to stay there. You can
> ask
> > the SourceForge admins theoretically, although
> tend
> > not to process those type of requests.)
> > 
> > I think standard Open Source is etiquette is to
> first
> > write the authors privately (which you've now
> done),
> > then wait some reasonable period of time for a
> > response. If there's no response, then you can ask
> > publicaly, in, say, queue-developers. If there's
> still
> > no response after, say, 30 days, then it's yours.
> > 
> > However, please be patient with Mike. I know he
> has a
> > full-time job (jobs?) as well as growing family.
> So,
> > give him at least a week before posting the
> question
> > publicaly, and don't be offended if he doesn't get
> > back to you right away. 
> > 
> > Mike will probably write back in a week or so
> saying
> > he's still doing work on GQ, but would really
> welcome
> > your help on GQ as a developer.
> > 
> > However, if Mike is agreeable to your taking over
> the
> > project, or doesn't get back to you after you've
> > posted publically for a month or so, then you can
> just
> > write RMS (with a CC to me), and it's yours.
> > 
> > You could probably get some developer admins
> (e.g.,
> > write access to the CVS tree) faster than that.
> Ask
> > Mike first, though. If he's agreeable, or if we
> > haven't heard back from him in a week or two, I
> can
> > probably set you up with some write access.
> > 
> > BTW, It's "Werner" to everyone except
> telemarketers
> > and such ilk, who are required to use "Dr. Krebs."
> > 
> >
>
----------------------------------------------------------------
> > Werner G. Krebs, Ph.D.,
> > Technical Specialist           
> > 
> > Personal website: http://www.wernergkrebs.com
> >
>
----------------------------------------------------------------
> >   
> > --- Koni <mh...@co...> wrote:
> > 
> > > 
> > > Hello Mr. Castle and Mr. Krebs,
> > > 
> > > If that should be Dr. for either of you, my
> > > apologies. My name is Koni,
> > > alias cryptopup on sourceforge. I am writing to
> > > inquire about what
> > > either of you are planning to do with GNU Queue.
> I
> > > know Mr. Krebs has
> > > formally signed off from the project, but I am
> > > sending this your way
> > > anyway since you are still listed as project
> admin
> > > on sourceforge.
> > > 
> > > I encountered GNU queue through a google search
> and
> > > was immediately
> > > seduced by the documentation I found at
> > > http://www.gnuqueue.org/queue_man/queue.html
> which
> > > comes up first at
> > > google. By the way, this is way better than
> > > sourceforge, don't take it
> > > offline, point sourceforge back to there.
> > > Sourceforge is so busy with
> > > adds and irrelevent links. 
> > > 
> > > Anyway, files as given for release at source
> forge,
> > > or the queue-stable
> > > cvs checkout do not compile on modern Linux
> systems
> > > (specifically fedora
> > > or RHEL here) and from the postings there it
> looks
> > > like this has been
> > > the case for perhaps up to 4 years.
> > > 
> > > I have succeeded in correcting both compile and
> some
> > > runtime bugs and
> > > posted a patch, FWIW, to sourceforge in the
> patches
> > > section. Check that
> > > out to gauqe my abilities. I apologize for the
> > > reformatting changes in
> > > the diff, using -b didn't make very much
> difference
> > > from cvs diff. 
> > > 
> > > There are still serious problems though which I
> am
> > > trying to work
> > > through. I want a system that can be used by
> > > non-programmers as easily
> > > (?) as it is to use simple job control of a UNIX
> > > shell. Nothing too
> > > fancy, just take a job, execute it when and
> where
> > > there are resources,
> > > and that's it. Don't care about accounting,
> process
> > > migration, or
> > > anything else. I actually found queue by
> searching
> > > for rsh replacement. 
> > > 
> > > >From working through the code to track the
> bugs, it
> > > seems clear to me
> > > that a substantial overhaul/rewrite is badly
> needed.
> > > What I would like
> > > to know from either of you is the following:
> > > 
> > > 1 - Is there an active known user base out there
> for
> > > this, or is GNU
> > > Queue gone defunct by lack of user interest
> and/or
> > > development? <another
> > > story> I know how this goes. If you hit my
> > > sourceforge account you'll
> > > find SLAN, a product which works (but not the
> > > sourceforge copy) and I'm
> > > using right now actually, but I can't be
> bothered
> > > maintain because there
> > > is no interest now that IPSec is built-in to
> modern
> > > operating systems
> > > and you can buy an IPSec VPN server at Staples
> for
> > > $60. </another
> > > story> 
> > > 
> > > 2 - If it worked as documented, is there still a
> > > niche market for it?
> > > Ie, has sun GRID, condor, openmosix, and
> whatever
> > > else covering the
> > > range of interest out there?
> > > 
> > > 3 - Do either of you want to do anything else
> with
> > > this, and/or can I do
> > > my own thing?
> > > 
> > > I am thinking about rewriting gnu queue to root
> out
> > > the bugs, simplify
> > > the code, clean it up, and add a few features
> that
> > > users in my lab here
> > > will probably need. 
> > > 
> > > If there are (active?) solid development plans
> and
> > > things are just
> > > happening beneath the radar, then I'll fork off
> and
> > > do my own thing if I
> > > decide its worth the effort for just the local
> group
> > > here. Otherwise,
> > > based on the empirical evidence at sourceforge,
> it
> > > seems both of you are
> > > more or less done with this project. I apologize
> if
> > > I'm being
> > > presumptuous in that conclusion.
> > > 
> > > It may be worth mentioning that I do not plan to
> do
> > > anything with
> > > checkpoint support, and probably never will.
> Condor
> > > addresses this need
> > > in the case of non-dedicated systems. For small
> > > dedicated cluster
> > > systems, which is my perception of the proper
> market
> > > for GNU queue,
> > > checkpoint is something that is either not
> necessary
> > > or something that
> > > is better handled at the application level in
> > > whatever special cases. It
> > > seems safe to me to presume that those special
> cases
> > > are custom
> > > development apps anyway. I think its a
> complexity
> > > nightmare the code
> > > base in present form (as per cvs queue-stable)
> can
> > > not sustain. I have
> > > not looked at the development branch. 
> > > 
> > > Thus, if I put serious effort into this, my
> primary
> > > goal will be to
> > > clean up the code and try to create a stable
> system
> > > suitable for any
> > > current linux small cluster system and add tools
> to
> > > allow users to see
> > > the queue list, remove or kill jobs. 
> > > 
> > > This email is way longer than I thought it would
> be.
> > > Sorry 'bout that.
> > > brevity is not my skill. :)
> > > 
> > > Cheers
> > > Koni
> > > 
> > > 
> > > -- 
> > > mh...@co...
> > > Koni (Mark Wright)
> > > 233 Biotechnology - Cornell University
> > > Graduate Student - Genomics / Plant Cell
> Molecular
> > > Biology
> > > 
> > > 
> > > 
> > 
> 
>