[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Bugtracker
On 1/1/10 4:04 AM, Paul Wratt 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.
"frontend that can interface with CVS" - note the interface part. PHP
and Perl (and others) can interface with CVS, so any upload or online
editing can be legitimate CVS. In this respect a staging area would be
better, to minimize CVS actions. I am thinking "online only", for
those occasions when you cant use the local machine to test you web
pages first, but with upload for those who can.
In this cae I (or others) who dont have normal CVS access can then
update the website as need be. Since its on the same server as
Bugtracker, that user db can be used as a basis for allowing the web
dev stuff, limiting the need for extra login usernames etc.
plain text file access, and any formatting can easily be scripted out,
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.
then this should not be a problem. But the other point about wiki is
that you could not (simply) integrate current non wiki content, ie
I do agree with the "holds the keys" issue, and that is something that
any CMS I use or develop, caters for, there is still a master system,
but its it is a keyless entry, and is secure simply by not making it
publicly know. Technically it is NOT keyless, but rather does not use
username& password combos.
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.
Again I would prefer a system that can integrate current non wiki
content as well, for changelogs, roadmaps, searches, catalogs etc.
I am thinking about maintenance and updatabitity, and the fact that
although wiki formating is simple, a lot of people wont edit content
in the same way people wont build or test.
Also its about getting content into web space, the less typing the
quicker the dev process. I have not problem running scripts to adapt
non-wiki content, but it needs to be dynamic, and allow only one point
of change, one that can be used and viewed with or with out the web
(ie, non wiki), on any platform
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.
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
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.
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
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.
You would be better off stick with the scripts to build, if for no
other reason that what you say above "people die"/"one hold the key",
and as a proof that they can handle 1000's of packages, including
build errors, various build sources, and various cross-build
packaging, see "src2pkg". (I was intending to add MiNT support to
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 ;)
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.
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.
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