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.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.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.
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.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.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.
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 ;)
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?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.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.....
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.
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.
Thanks, Mark