Re: [MiNT] Bugtracker

[Paul Wratt <paul.wratt@gmail.com>]

On Sat, Jan 2, 2010 at 4:46 AM, Mark Duckworth
<mduckworth@atari-source.org> wrote:
>
> Well staging or temp directories don't seem like a big deal.  And typically
> with different php/apache/mysql versions you do need to test with the real
> server version.  But it does kind of screw with using CVS to commit web
> content and having the server automatically replicate it out...  No way to
> test.
>
It was only one solution to the issue of SpreMiNT web content being
inside CVS, and so be limited to who could update what, all tha would
be required would be a specific user for CVS access, the temp folder
or staging, was just to limit the CVS activity, especially if a
changelog is to be submitted to the list one a month, no point in have
extra "nuisance" commits, just because your testing or editng a web
page, again tho, it was just one solution.

>
> Hrmm regarding this, wiki is a good format to cut and paste existing text
> docs into easily, and also a good format for new docs.  It's just basic
> markup and if we wanted to move it's not like we'd have thousands of pages
> and they're all accessible in a database.  It's really not closed in any way
> that I can see but at the same time offers a lot of advantages.  I see
> nothing to dissuade me from using a wiki (we use them at work religiously).
>  Anyway, no you're not going to simply be able to upload a hyp and you'd
> have the exact same problem with a cms.  But you can at least store the hyp
> online somewhere and use libhyp to view and just link to from the wiki.
>  Seems no big deal.  http://phoenix.inf.upol.cz/~opichals/libhyp/  Right now
> I am viewing books stored on docs.atari.org or whatever that site is using
> libhyp.
>
This is another useful too (the libhyp work), and if most other feel
OK about using wiki, then that is fine (see other post), just remember
I was thinking about multiple uses, including offline..

>
> It sounds like you should do what nearly all of us have done - start our own
> site.  There's not going to be any out of box system that fits all our
> needs.  The freemint main site just needs to link to all these sites and
> show their reason.  If you make your site, rip all freemint content, and
> present it to everyone and it's good, then I don't see why we wouldn't
> change to your site.  That's what I'm doing with the package management
> site.  I'd rather it all be on the same page too but us Atarians seem
> awfully opinionated about exactly what we want to display and how.  Why else
> would we have 5 vdi's, 10 mail clients (all nearly useless), 3 aes's, etc.
>  Btw, I just tried litchi.  It's really good.

I already have a site, and I will maintain my own independent
developments and comment there, but I wanted to centralize some of it,
like and TOS5, skins, themes, dev docs, and cross-referencing, 99% of
which the raw content already exists in a single server, which would
make creating AES to XaAES referencing a reality (as one example)

litchi has been around for a while now, and has a good rep (If I have
not confused it with something else)

>>
>> which was why I asked. The is already an unused freemint.de that
>> should really just be updated, but I am presuming that there is no way
>> for this to happen
>
> That site is owned by Ralph (AltF4).  I don't think he is gone or anything,
> just not active.  If we wanted the domain he would probably give it up.
>
if we could get access to the current server it would be better,
unless someone want to do a new layout etc, I would just update the
content, and maybe add a french and Czec versionm, but basiclly just
update everything. Some of those dead link I have managed to find the
packages, copys of the web sites etc..

I would still want to do something specific for Alans Freemint.org,
presuming that to be specific to kernel development, test versions,
cvs builds, and other branch builds. If the wiki stuff comes up by
Sunday (so it can start to be fleshed out) I will put together a demo
site for Alan that can allow others to upload custom kernel & xaeas
builds, which will makes it easier to pretest patches and bug fixes

>>
>> This is REALLY good to know. I would say tho, allow the sum to submit
>> "make public" and "comments", like the wine assistant, and a couple of
>> other packages do, that way you can also use a % system to re-evaluate
>> is status, not just a min or max number for confirmations, where the
>> comments would help with problem solving. I might be an idea to
>> combine the submition process with a profiler tool, that would also
>> assist with issues, including trouble shooting successful installs
>
> I never thought of this at all.  Both comments and submissions of
> comments/approvals from the sum client.  Really good ideas.  I'll add them
> to the todo.
>
Yeah, i seem to have that affect ;) Thanks for taking it on board

I will look into this profiling idea, there were some posts with apps
named, I will see how much work is involved in db'ing there output for
uploads and cross-referencing

I would also start a profile list of AES and VDI functions to try and
speed up XaAES and fVDI compatibility levels, and for widgets for
XaAES. Hopefully OL wont mind if MyAES is cross-referenced too, but
we'll get to that later

> The C++ stuff would be open source of course.  It just offers a lot more
> processing flexibility than scripting, and it's what I know.  PHP would be
> even better but I'm not running something like a build farm with php ;)  It
> just seems wrong.  Python is most ideal but I don't know it.  gentoo is
> proof that python can be used to manage builds effectively.
>
I presumed when you said scripts, that you actually meant BASH
scripts. But as long as the source is available, there should not be a
problem..

>>
>> Which is why they need updating, including roadmap, and greater
>> (undefined) TOS5, which would help roadmap direction. TOS5 comes in 2
>> flavours, one is "legacy free", eg TRAP#2 replaced for AES/VDI.
>
> See you keep talking about stuff like this.  These are all ideas people have
> submitted, all good ideas.  I don't think anyone is actually implementing
> them though ;)  No need to document something that doesn't yet exist ;)
>
That is one of the reason I do keep bringing "stuff like this" up,
there is a clear need for a current roadmap in various parts of
FreeMiNT related OS, but with the idea of TOS5, and all that entails,
it would allow for better definition of where that roadmap will lead
to, and that my friend is ACP in 12 months, Full OS, and also for some
of us, Full Legacy Free OS.

Those last 3 points are moot (irrelavant), the point is there is not
even a clear understanding of what the roadmap might be, unless you
are say Alan, or Frank (re kernel), let alone somewhere anyone can
actually read it. Remember, you (Mark) are busy doing certain dev
work, others are doing there thing, but i am thinking as far as 12
months + down the track, and I am think kernel, AES, VDI, Desktop, OS
apps, OS setting, OS customization, customization tools,
multi-platform dev environments, user interfaces, package repos,
future undefined plaforms, just to point out the tip of my iceburg

>> I am not against this, but i was thinking more about non dev work, for
>> people to be able to contribute and get either custom builds of XaAES
>> (as per my Gradients patch), or to upload and download skins, themes
>> and textures, or provide new gradient sources
>
> Again, wiki is nearly perfect.  You can simply modify pages to add your
> builds, etc and upload them to a file area.   You don't need permission, you
> just make it happen.  Someone should just setup an "official" wiki and let
> it evolve.  I think you'd be surprised how well it would work.
>
As long as others are happy using the wiki, I m an experience internet
developer with some 12 years experience, and one of my specialities is
NON-dev users, user interface organics (including content management
and editing). Again as long as most others are happy to use it, and
other non-wiki related content can be added to the site quickly and
easily, I have no problem using it, but be aware, I was not quoting
non-wiki without foundation, but as long as there is no need ti move
to web content in the future, there will be no major problems..

> Thanks,
> Mark
>

thank you, some more knowledge was spread, and there seems to be
movement in getting something up and running ASAP, and now we know why
you are often quite on the list :)

Cheers

Paul