Re: [MiNT] MiNTLib / Kernel Future and also SpareMiNT.....

[Alan Hourihane <alanh@fairlite.co.uk>]

On Thu, 2010-05-27 at 14:50 -0400, Mark Duckworth wrote:
> On 5/27/10 1:54 PM, Keith Scroggins wrote:
> > Hi All,
> >
> > Well, not sure where to go with this conversation, but we need to 
> > start it.
> >
> Thank you for doing it.
> > First being, we need a person, or a group of people, to steer MiNTLib 
> > and the Kernel.  Mainly, I think, these people need to decide when it 
> > is time to do a release, maybe a little project planning, but I do not 
> > believe we need too much.  I think this needs to more or less be a 
> > decision by the group.
> >
> > It seems to me that it was more or less decided we should release 
> > MiNTLib at 0.59, should this be done now, or with a past build?  I 
> > know I agree with this since some of the modern tools 
> > (gmp/mpfr/mpc/gcc) need support from functionality added and fixed in 
> > the CVS/developmental branch of the MiNTLib.
> >
> Well 0.59 was "released" despite that nobody used it, so we should 
> probably just do a 0.59.1 release.  Just to be proper.  I don't think it 
> matters much though, we can call it whatever we want.  But if well 
> tested fixes are incorporated and necessary lets roll with it I say.

Yes, 0.59 was officially tagged but never actually uploaded. If someone
wants to create an RPM from the tag that'd be great.

> > I would propose that we do a release now, and then plan the 0.60 
> > version of MiNTLib to be released around the time of the Firebee 
> > release (possibly) in case things need to be fixed or added for Coldfire.
> >
> > As for the kernel, I can not speak to it's status for release.  I 
> > would recommend a road map or maybe a list of goals to prepare it for 
> > release, mainly bug squishing, and then expand that list to include 
> > what features, additions, etc, would go into the next revision.
> >
> But someone actually needs to prepare this roadmap.  And that person who 
> understands what is needed could be the decision maker anyway.  Who do 
> we give the authority to dictate the direction of our platform?  Who 
> even wants it.

Well the people who develop pretty much dictate the direction, and they
take feedback or feature ideas from interested parties and implement.
That's the way of open source development :-)

> > Now, the other question is Sparemint.  Where should it head?  Are 
> > people still willing to build RPMs and support the software, and do 
> > people still want the software supported?
> >
> My opinion is that there is a lot of easymint users.  Easymint uses 
> sparemint as foundation.  Therefore sparemint is the primary community 
> supported distro on our platform.  Keith, I don't think that our work is 
> for nothing or else I don't think we would be bothering to make rpms at 
> all ;)

Neither do I. In fact I encourage you to carry on with SpareMiNT and the
RPMs if that's what drives you to do this.

> > The other issue with Sparemint (well RPM), at least in my opinion, is 
> > architecture support.  By default, unless currently noted, RPMs are 
> > built for a 68000 target.  Should that remain the same, or should this 
> > expand so that packages are also target at 68020-60 and then later at 
> > the Coldfire? If so, how?
> >
> > I have my own ideas / thoughts for this, but not much point in 
> > executing it if it would be of no use.
> >
> > Remember, Alan is also working on a Gentoo MiNT distribution.  I just 
> > want to basically see programming resources not go to waste, and get 
> > some real 'direction.'
> >
> > Sorry for writing a book.  Back to working on MPFR RPM.....
> Well that's the problem with supporting sparemint.  I think probably 
> what we need is to generate a spec to ebuild generator and vice versa so 
> we can take alan's work (for patches and such) and push it right over 
> and vice versa.  Eventually one platform will have the critical mass of 
> users needed to make a choice about which ones should be done.
> 
> The real question here is Alan, why are you pursuing gentoo mint.  What 
> does it provide that sparemint does not?  A real honest dialog of the 
> merits of both systems will probably steer us in the right direction as 
> far as what to support and how.  I know ebuilds are fairly easy to work 
> with but I also know python is pretty big and slow whereas rpm is pretty 
> lean and fast.  Alan, how much dependency mapping have you done with 
> gentoo mint?  Sparemint largely seems to have dependencies unmapped in 
> the spec files but I've gone a long way on this and have about half done.

I'm pursuing Gentoo because I absolutely hate RPMs. I use Gentoo on all
my other platforms too. So for me, it's a natural choice. But certainly
feel free to pick patches etc, but I send all my stuff upstream so the
packages build out-of-the-box. So we'll all benefit regardless, but it's
merely a matter of personal choice for folks.

> Anyway, speak up, opinions guys.  I don't think any of us are used to 
> leading a project and I think somehow all of us are going to be leading 
> it so we have to have an idea of what everyone else wants.
> 
> PS: I vote for Alan as a new kernel leader.   He's already been 
> performing this role anyway.

I'm quite happy to do this and will certainly be making a release soon
of the kernel with our thanks to Frank.

The "daily binary builds" make this task much easier as we can have a
wider audience testing the kernels.

I've got a few things lined up for the kernel yet before making a
release though.

One final point, is Helmut has been driving a lot of XaAES development,
and I really encourage people to try out his branch. Ultimately, I'd
like to get Helmut developing on the trunk for XaAES and get his stuff
merged as he's very active. So please test his kernels and report stuff.
It's great to see all this work coming to fruition.

Alan.