[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:

"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.
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. 

plain text file access, and any formatting can easily be scripted out,


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
TosHyp

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.
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. 
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
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. 
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. 
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. 
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
this)
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. 

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 ;) 
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. 

Thanks,
Mark