[MiNT] Bugtracker

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

Dont appoligise for the length, it is important that we know whats
happening, and what you are upto

2010/1/1 Mark Duckworth <mduckworth@atari-source.org>:
> On 12/31/09 2:22 PM, Paul Wratt wrote:
>>
>> (see previous mentioned thread)
>>
>> Thanks for that Rob, it might be an idea to add web frontend that can
>> interface with CVS so the website can be updated without CVS access,
>> secured of course, and it can be path limited to the SpareMiNT Website
>> only (extra secure)
>>
>>
>
> Typically when you go CVS that is the only way you go.  For instance, if you
> have web content that is in CVS and someone starts making peacemeal changes
> without committing them to CVS then you lose all of the benefits and
> features of using CVS to begin wtih.  It should either be used religiously
> or not at all.
"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.

>>
>> Vincent was right, you just need a captcha plugin, its also works well
>> for anonymous stuff too
>>
>> DONT got the wiki route, for one reason, portablity, web site contents
>> cant be easy moved or ported to another interface, unless it can
>> access plain text files, or db text (which can be dumped, manipulated,
>> and re-db'ed)
>>
>>
>
> The wiki format is actually fairly portable.  There is only basic formatting
> blocks that can be stripped out to get a text format.  Wiki offers the
> benefit of loose control and anyone can make changes.  This is something the
> atari community really needs as we regularly have people that control
> important projects disappear either permanently or for years at a time.
>  There should be no one person that holds the keys because people die
> unexpectedly and that's just how it goes :(

The entering of data is not hard, but there are known issues when it
comes time to move the wiki content. As long as there is at least
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.

>>
>> I dont mind updating any web stuff, especially id it means "typing up
>> docs".
>>
>>
>
> wiki and docs are synonymous.  Almost all freemint docs would be best housed
> in a wiki.
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

>>
>> A couple of questions:
>> 1) is SpareMiNT site the home of FreeMiNT. I am thinking about road
>> map, TOS5, and other OS related stuff also (most of which is present
>> in CVS)
>>
>
> Sparemint is the home of sparemint.  Freemint has no official home though I
> guess you could say sparemint is the home of freemint since it has the only
> source of info about freemint cvs and other docs.  But technically sparemint
> is just one most commonly used flavor of freemint with others being gentoo,
> debian, kgmd, etc.

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

re: http://freemint.sparemint.org and you next comment
Alan already has Freeming.org. So in theory it would just be a matter
or getting some content up. I am presuming tho, that his url is NOT on
the current servers, which would mean a standalone system of CMS (or
simple text editing and upload). I have a really light online editing
and file upload system that can be secured, and the original of which
is only 87Kb in size. I does not have to use db, and multiple installs
can be used for various parts of CMS type management, web site
maintenance can be different from
freemint CVS build upload, which can be different from custom user build uploads

http://navphp.sf.net  - and I do have a IE7/8 compatible proto-type
available (the one with Atari interface and Editor S&R)

>>
>> 2) should sparemint site just need a makeover/update, and add new
>> http://freemint.sparemint.org
>>
>
> For every person that agrees with this, there's someone that disagrees but
> my vision for sparemint is at http://dev.sparemint.org.  It is to be a
> dynamic site that is php powered and all data is stored in back end
> databases.  There are different variants of sparemint called repositories
> and they can be optimized for 060, coldfire, etc.  There is a program called
> sum that operates in both text and gui gem mode and updates from this new
> sparemint database using a basic http api.  It will work similar to yum on
> fedora, etc but will be less featureful (it has no dependency checking which
> is largely useless for statically linked sparemint).  When a user wants to
> contribute to sparemint, he/she simply builds the source rpm file on their
> own.  This requires the package to build successfully in order to get the
> srpm output.  The server will then extract the srpm, glean metadata about
> the package and build binary rpms for all the different available
> repository.  Once the rpm is build it will be provided to
> <repository>-testing.  Any users who are using the testing version of that
> repository will automatically get the package updates.  People who test the
> package and can confirm it works properly for them can then login to the
> sparemint website and submit an approval.  With X number of approvals, say
> 2, from different users + the original package uploaders implicit approval
> we then push the package out to the rest of the population.
>
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

> This vision is about 90% complete.  I need to push to finish the build farm
> daemon which is currently shell scripts but I want it to be a c++ program, I
> need to completely build sparemint with gcc 4.x for each variant, and I need
> to fix a few bugs in the sparemint update manager.
>
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 reason I did all this is because right now you upload packages to
> sparemint incoming and I believe only Frank Naumann approves packages but he
> disappeared and didn't approve or disapprove of some rpms I spent lots of
> time building.  I decided there must be a better 100% community driven way.
>  (nothing against frank of course).
No, Frank is just not around at moment, and "holds the keys" which is
painful under certain circumstance, the current work being one of them

>>
>> 3) Can we get a OS specific website up, that covers all things needed
>> to get up and running from current CVS, but also make room for TOS5,
>> ACP/v4e, and current CVS development roadmap
>>
>
> Much of the docs are completely obsolete.
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.

>>
>> 4) Can we get website for Current OS Fluff, like what atari forums
>> had, for XaAES skins themes, custom builds, and other related "fluff"
>> (sound, MyAES themes)
>>
>>
>
> Really we need an official XaAES and MyAES home.  Really ideally these
> should all be projects on gforge running on atariforge.  It's really the
> best place to independently manage these separate projects.
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

>>
>> "websites" can come under single site, and I dont mind putting its
>> together. It can use a CMS if need be, so others can manage it as well
>>
>> For Mantis:
>> 1) Helmut should have developer status (can close)
>> 2) Is there a way to "second" a closure, and can closed bugs be reopened.
>>
>> Something needs to be done regarding bugtrakker actions, and also CVS
>> actions. For example, once a month it MiNT-list gets a CVS-changelog
>> for that month, and Bugs-closed/Bus-open for that month
>>
>> That would help everyone who is not a CVS dev, or mint/xaaes dev to
>> keep up to date without overloading anything. It would also allow
>> another way of tracking and searching for CVS issues, and patch/bug
>> related issues, and may actually improve problem resolution..
>>
>> For developers, is it a good idea to allow "nightly patches" (or
>> weekly?) through Mantis, as oppossed to single CVS patch commits. Can
>> Mantis do this? Also for those developers who dont have CVS commit
>> access, should there be a group of people who are willing to test the
>> patches first, taking some of the patch duties off Alan shoulders (at
>> least so he can commit without question, or use Mantis to do it)
>>
>>
>
> Something you seem to miss is that there is not a lot of active development.
This is one of the point I have been trying to get accross (in other
threads) the IS a lot of development, is it more that it is not
publicly know unless stated

>  There is no release cycles.  No need for nightly anything for the most
> part, etc.  Nightly cvs builds are fine because all they waste is cpu
> cycles.  In fact one idea I had is to enable my nightly cvs builds and
> forward build failures to the mint list.  Then people can easily see when a
> change committed to cvs breaks it at least for me.
I was not thinking of Nightly Builds, but about keeping CVS static for
set periods, and only updating the patches every 24 hours. If mantis
can handle some of the patch load that Alan is currently responsible
for (simply for lack of others I would say), especially if there was
patch evaluation process (as mentioned elsewhere) to speed up commits.

Nightly builds would be good, and the submission of failures to the
list would be beneficial. As I said some where else, submission to the
list of monthly patch lists, bug closures, bug opens and current bugs
would also allow non-cvs dev users to keep up to date, a allow more
fixes and problem solving.

Again a profiling upload of users systems would help with any testing
including trouble shooting successful installs and tests

>>
>> Again, I dont mind doing the web stuff, including additions to Mantis
>> if required
>>
>> Paul
>> PS I think Mark said he has some GCC 4 RPM builds, and others need RPM
>> building to be documented (for SpareMiNT compatibility, the is a doc
>> somewhere) and CVS patch commits (as per thread)
>>
>>
>
> I don't have anything current but I did it before.  I decided to make a push
> to do this again but I ran into the malloc bug and gave up.  If I can't
> escape the bugs of the platform that are supposedly fixed then I can't help
> much with packaging.  RPM needs the build to go uninterrupted with no random
> problems.  Because of this in the last couple weeks I have been learning
> assembler to help work on freemint itself as well as firetos for m5485evb
> with lynx and usb drivers.
>
> I don't mean to sound bitter but my atari life has been a lot of hard pushes
I dont think there are many people in the Atari ST world who do not
experience this

> involving lots of my time followed by many unsolvable letdowns which push my
> work aside.  Right now though I am working on bootstrapping a fresh version
> of sparemint 100% with newest mintlib, gcc, binutils, etc.  If I still have
> malloc bug then it is most definitely not me using a tool statically linked
> against an old mintlib.  But I have to get past these gcc 4.x.x builds which
> have problems with limits.h and syslimits.h.
Some of the above mentioned would help you get this solved quicker,
and allow more people to assist at the same time

>
> Btw, I also vote for a mintlib and freemint release so that we can update
> the sparemint packages for these. Sorry for the long winded msg. Happy new
> year guys!
>
I think it is just a matter of time, especially with those patches
recently supplied by Vincent et al, it is crucial. the main issue at
the moment tho is "the lack of Frank", for main trunk release, so it
would really come down to Alan being satisfied by the community to
allow this to happen sooner rather than later.

I believe that ACP's development is currently hindered by this, simply
because of a lack of a static starting point, which is what this
thread and others would fix, and at the same time allow for a
consolidated display of "where things are now" and allow for "where we
will go in 12 months" to be designed, outlined, and then fleshed out

The work you are doing will assist in this process, but I hope to
include any other areas that are also currently in need of inclusion,
with the specific target being ACP, allowing preliminary design and
outlines before even the hardware is ready, as this directly relates
to ARAnyM and other Coldfire OS development, not to mention CT6x/CTPCI

OK, now I would appologise for the length of the post, but the more
that gets said, the quicker decisions can be made, and the quick they
can be put into action. In this respect I expect to have something
people can use within the month, and fully usable and contributable
within 2 months at the ABSOLUTE outside

I feel the ned to remind people that there is not one single way to do
this, or to provide usability, "different strokes for different
folks", so I am also saying that what is already available and being
done (ie Marks SpareMiNT effort) needs to be accessible for one point
(at a minimum) and that new things should not be exclusive in there
operation, but simple one option that you may or may not use, but that
is documented and proven for what ever task it is that you with to
achieve

> Thanks,
> Mark
>
Yes Happy New Year