AROS68K development methodology and bounties

[wawa]

Originally Posted by Kalamatee

IIt is tedious for sure - until you fix some really annoying bug that's been impossible to pinpoint, and suddenly the whole system seems to feel more stable/stuff that you didn't expect starts working also ;D

true.. tonight is a big aros night in my book. a lot of stuff i have thought broken works, as if all the sudden. i dont know how this comes to be.

[Kalamatee]

Originally Posted by amiwolf

My contribution to the kickstart bounty wawa mentioned wasn't much but hey, every bit helps yeah? Got the impression Toni didn't enjoy the experience that much though I guess deadlines are never fun. Motivation for any Amiga developer is more than just money, I think.

While I cant comment on Toni's experience/enjoyment - Your comment on deadlines and motivations hits the nail on the head for me.

You have to keep in mind, that most of the developers in the "AmigaOS" community are not professionals despite what they might think (and that's not saying there aren't any in the community - since there are of course some amazing people out there across all the platforms). For many coding/AmigaOS/AROS is a hobby, so having to work to a deadline is definitely something that doesn't appeal right off the bat. And lets be realistic, the sums of money aren't massive by any means considering the work that can be involved in some cases - certainly nothing to what a real professional coder can make.

Which leads onto motivation - obviously depending on your confidence/interest the previously mentioned things will heavily affect your motivation. Most of the bounties that have been done have been completed because the sums involved have reached a point where capable devs, who are somewhat interested, have their curiosity peaked. The other case is the dev was interested/wanted to see that "goal" implemented anyhow so just took the bounty along the way, or did it as a friendly gesture =)

As someone who has done some of the bounties, and watched/listened to what goes on for a number years - my observations/recomendations would be -:

# Some of the bounties are not properly thought through/discussed prior to being made a bounty. The goals may be unrealistic or at odds with what the devs actualy want to achieve - or set too many constraints. This is something we try to avoid but some people insist on making a bounty even when told it wont get done, and others will also donate to it.

# Many of the bounties would be more achievable/likely to get done if they where broken into smaller units of work with clearer goals. Sometimes people expect too much, or don't realise that if one person does some of the work, another is likely to finish the bits they can handle/do.

# Even though the bounties should be in as small a unit of functional work as possible - there needs to be some scope to work on a few of them as a larger "bounty"

To help explain - imagine we have some bounty for e.g. a new tcp stack, but could also do some of the parts of it as individual bounties (such as adding ipv6 support). Some people may want to just donate to see those parts achieved (ipv6), others may want to donate to see the "whole" thing (complete stack) completed -: so it should be possible to donate to the larger project or the individual parts.

If someone takes the "larger" bounty, they would then also get the sub bounties in the process - but if someone was to take on the sub bounties the money for the "larger" bounty should also be proportionally assigned to the part the work they have done, which they should receive on completion of their part. Anyone taking on the larger bounty when the smaller parts are already being worked on must be made aware that they would not get the total sum - but the amount less the work done in the "sub" bounty.

[grelbfarlk]

Don't take this as dropping a turd in the punch bowl, but does AROS work with Mediator or does it have any PPC support like WarpOS?

I realize the thread is AROS68K but if one were to take the assumption that AROS was to be the one Amiga-like OS to rule them all, wouldn't native (not linux hosted) PPC support be a good thing for the NG Amigas as well?

[Kalamatee]

Originally Posted by grelbfarlk

Don't take this as dropping a turd in the punch bowl, but does AROS work with Mediator or does it have any PPC support like WarpOS?

PPC support as a coprocessor - no, I don't believe anyone has ever looked into it even since there has been such little interest in that regard, but it isn't something that would be impossible to implement if someone where interested.

Mediator - I believe there is code on SVN for it and Prometheus but if they compile/work at all, I do not know. Certainly no drivers have been adapted to work (that would need to change e.g. the window) but again that's not that big a job for anyone seriously interested in seeing them in usable shape.

I realize the thread is AROS68K but if one were to take the assumption that AROS was to be the one Amiga-like OS to rule them all, wouldn't native (not linux hosted) PPC support be a good thing for the NG Amigas as well?

m68k has more interest than PPC it seems.

[Samurai_Crow]

Re:PPC
AROS works on the SAM 460 and Efika. It does not work on the AmigaOne XE, MicroA1, SE, and so on due to missing cache coherence in the support chips (Articia S series northbridge paired with a Via southbridge).

[wXR]

@all

Off-topic but apparently inspired by the movements here -- Apollo team to open source the SAGA core!

http://www.apollo-core.com/knowledge.php?b=1&note=5768

@ross / @wawa

I guess you guys were right; unfortunately I misunderstood the 68K/AOS compatibility there. I will amend the post.

[wXR]

Just to clarify what I am saying about git. I do not have any particular obsession with one version control system over another (although git is clearly superior in a lot of ways). The main point I am making is that GitHub provides a very useful unified environment for community-based development. There is no SVN/CVS-based equivalent of GitHub, and GitHub is where most of the developers of the world seem to congregate in any case.

[Samurai_Crow]

GitHub hosting has been rejected by the AROS team in the past due to the servers being in the United States. US laws regarding reverse engineering border on lunacy sometimes.

I think there is a mirror on another Git based host in Europe. I'll see if I can find it.

http://repo.or.cz/AROS.git

[wXR]

Again, it is not about the version control system, its about the integration of the whole: discussion, development, bounties. It really needs to be on GitHub, because GitHub has the best user experience integrating all three, and the largest number of developers. I seriously doubt that there will be any issues.

[wawa]

Originally Posted by wXR

Again, it is not about the version control system,

but it did sound in your initial poas as if you were insisting on git, so this thing should be discussed to be starightened up. personally i dont thisn the choice of version control should be a primary issue.

but also:

Yes, my offer requires some initially uncomfortable changes, and perhaps a grumbling abandonment of certain intellectual investments, but I make this offer with a sincere belief that it will be better for everyone in the long run.

you make it sound a but threatening. what are these "uncomfortable changes", you demand, then? you have not mentioned anything precisely.

[wXR]

@wawa

I have made one specific demand actually: the use of GitHub. GitHub is a social network for developers that integrates with a version contol system. The reason its featureset is important was stated in my original post: The current "user experience" of getting involved with the AROS development community is extremely poor, because the different aspects of it are spread across many domains, all running ancient software. Moving the whole development community (discussion, issues, bounties) to a platform like GitHub effectively solves that.

Finally, as I've said numerous times, I am less pushing a specific version control system than I am strongly encouraging a unified place to work and discuss development. It would be nice if GitHub supported SVN and CVS, but alas, it doesn't. However, as also mentioned earlier, strim has made some kind of nice tool chain for Hedeon already, which allows native development using an older version control system. I've invited him to come here and comment about that.

[wawa]

Originally Posted by grelbfarlk

Don't take this as dropping a turd in the punch bowl, but does AROS work with Mediator or does it have any PPC support like WarpOS?

I realize the thread is AROS68K but if one were to take the assumption that AROS was to be the one Amiga-like OS to rule them all, wouldn't native (not linux hosted) PPC support be a good thing for the NG Amigas as well?

aros has prometheus and mediator boards specific code in the repository, but i think a number of things must be missing for it to work. interrupts? i can volunteer to test with my mediator a4kdi mk1 board if anyone wants to pick the task to complete it. here are the hidd sources:
https://trac.aros.org/trac/browser/A...68k-amiga/hidd

now i know im raining on your parade a bit, but i dont think warpos support is something parrticularly necessary on aros. warpos applications are few. everything needs too be compiled against it. toolchain isnt up to date, is hard to find and receives a little interest i think. and i imagine programming a warpos application to be tricky, likely more error prone than regular 68k one.

i applaud your project, but i think to concentrate on faster 68k hardware is a better way of improvement. thats the reason im a bit indifferent about apollo core ammx extensions. but since they are inlined in the same cpu structure i am thinking they are easier to deal with in comparison with dealing with two different cpu architectures in one binary at the same time.

[wawa]

@wxr:
but isnt that better to hold on to what actual aros devs are actively using as we speak, rather than force another solution they need first to adaapt because of some potential contributors that might, just might, be attracted this way?

id say, lets keep a git mirror as an option, it shoudlnt be a problem, i think..

[Toni Wilen]

AFAIK problem with m68k PCI bridges is that there is no generic PCI bar initialization code, at least x86 port assume they are set up by the BIOS. This is too ugly solution for me

[wXR]

@wawa

No, I don't think it is. And I don't know how many more ways I can twist why I think that: My point is not about GitHub's role as a mirror for the code, its about its role as glue for all aspects of the development community. Wawa, I think you may wish to explore GitHub; I get the feeling that you don't really understand what it is.

Hopefully strim will illuminate us about the legacy-to-modern toolchain he made for Hedeon, so that this is less painful.

[strim]

Originally Posted by wXR

However, as also mentioned earlier, strim has made some kind of nice tool chain for Hedeon already, which allows native development using an older version control system. I've invited him to come here and comment about that.

Should the AROS team make a decision to host an official mirror of the development repository on GitHub, I can offer my expertise in the area of automated repository mirroring.

I have also noticed that Jason already has set up such thing on his personal account: https://github.com/ezrec/AROS-mirror . So it looks like the problem we are discussing here is not a technical one.

Everything else is just a matter of all AROS developers actually creating accounts on GitHub, then enabling the facilities that GitHub provides but are currently disabled for this mirror (issues, etc.).

[wXR]

Brilliant, thank you strim for pointing that out, and for offering your assistance.

OK, who is currently running aros-exec, power2people, and and the AROS sourceforge? I'd like to get everyone on board with the idea of depreciating at least some of those. If that doesn't happen, we'll end up with issues and discussion scattered across even more platforms, which will make an even greater mess.

Maybe one of you can tell me if the real action is on the mailing list, or?

[Locutus]

Originally Posted by Kalamatee

It has a long way to go. So far I have it compiled, but some of the code needs fleshed out still (e.g. in posixc), among other things. The binaries run but don't connect to anything yet.

Ah, thanks for the update :-) I was suspecting the recent posixc commits were for Git.

[wXR]

A collection of links, to illustrate what I mean about lack of continuity and the poor user experience of getting involved:

1. Issues (for some reason called "bugs" by Sourceforge)

https://sourceforge.net/p/aros/bugs/

Sourceforge is a platform that no developer these days wants to touch with a 10 foot pole. It has a poor, 10-year-old design which unforgivably doesn't serve what I believe is the the main purpose of such platforms: building community engagement around a project.

2. Mailing list

https://www.hepe.com/mailman/listinfo/aros-dev/

This list's archives are not open to review unless one signs up for the mailing list. Fundamentally this means that almost no one on the outside a small circle is going to bother. I see comments on various topics on aros-exec which say, "check the mailing list", and I just think, come on.

3. Bounties

https://power2people.org/

Nice try, but as an independent site, it fails by not being connected directly to issues, as described in my original post.

Lets do a little upgrade to some of this, for the sake of everyone's sanity. Now we know that we don't have to swap out the actual version control mechanism (yet, because we have a workaround for now in the mirroring), but lets at least centralize issues at GitHub, so we can begin to take advantage of what GitHub offers in terms of social mechanics.

I'd be glad to help with research and to assist in porting what is necessary.

[wXR]

Are all AROS architectures contained in a single repository? On the off-chance that they are sorted out, then it occurs to me that this is actually really easy.

Another half-measure is that we can port all m68k-related issues on Sourceforge to GitHub issues, and delete them from Sourceforge, insisting that they stay where they belong. There will of course be annoying moments where one has to go to Sourceforge to discuss something more general, but it is my hope that the glory of GitHub will make its superiority apparent in the meantime, encouraging everyone to switch.