I want to help!

[Erikina]

@Erikina:
I was not planning on using an IDE. I was reffering to Kompare. It's just pointing at two files, hit <enter> and it visualises the difference. Nothing fancy...

Well, you did say KDevelop -- which is an IDE. But anyway, make sure to give meld a go (even if you use a KDE desktop as I do). I work with a lot of patches and it's got to be my favourite tool. (Going back to a tool where you can't inline edit will make you go insane )[/QUOTE]

As I said before: I understand that my efforts can't be heroic. First it's just cloning/pulling/downing the latest git, compiling, testing and filing bugs.

That's a good start and shouldn't be too hard to use.

And also: no harm can be donbe by learning anything, no matter how complex.

Sure, but I just mean it might not be a productive use of time. But by all means, you should know how to clone a repo, grab updates, make a local branch, apply patches and revert them again. Just don't get hung up trying to be a git expert.

Sure I first need to learn C. Hello World I can do. I also made some basic calculator apps and alike in different languages at school but nothing fancy.

What C should I learn? GNU C?

C is C really. When possible I try use c99, but the additions are pretty minor (especially when learning the language).

[curaga]

IMHO small personal projects are really where git excels. Just think of setting up a svn/cvs/etc server, or running git init in a directory..

It really beats anything with tarballs.

[whizse]

The reason for learning git would be because all the projects (Linux/Mesa/Xorg etc) all use it, but mastering every aspect of it isn't necessary of course, you'll get pretty far with the basics.

I agree that git is probably overkill for small, personal projects, but it might also be an opportunity to learn more.

V!NCENT, while you're getting up to speed, it's not a bad idea to get involved doing simpler stuff. Bug triage is good starting point, reproducing bugs, asking submitters for more details, capturing good backtraces, bisecting regressions and so on.

(But be sure to ask the devs if that sort of help is welcome before you begin!)

[curaga]

git is pretty useful to learn. I myself started with it some months ago, and once I got the hang of it, wondered how I ever did without.

[V!NCENT]

I use emacs.

Eight megabytes and constantly sw-... *ducks and runs* :P

[agd5f]

I use emacs.

[rob2687]

What IDE do the people that work on the open source driver and stuff use?

[V!NCENT]

@Erikina:
I was not planning on using an IDE. I was reffering to Kompare. It's just pointing at two files, hit <enter> and it visualises the difference. Nothing fancy...

As I said before: I understand that my efforts can't be heroic. First it's just cloning/pulling/downing the latest git, compiling, testing and filing bugs.

But in the process it is awesome to learn about a lot of things on the surface. Just to start 'getting it'. I already learned a lot about what I actually need to test. I also wanted to get a better understanding of the techy jargon. I mean: how can I file a bug, if I don't even know what to file. I'm not so sure if "OMG version x,y is causing... that thinbg to go... black"

And also: no harm can be donbe by learning anything, no matter how complex.

Sure I first need to learn C. Hello World I can do. I also made some basic calculator apps and alike in different languages at school but nothing fancy.

What C should I learn? GNU C?

[Erikina]

I read the diff/sdiff/diff3 info page. Just to compare file differences... KDE has a nice file differences compare app as part of Kdevelop, which might be easyer for me (I think in visuals and not in a logical order, if you know what I mean ).

First up, KDevelop is currently a waste of time. KDevelop3 is a pain, and Kdevelop4 is still in beta and (I find) way too unstable for any serious work. If you need an c IDE Qt Creator (personal favourite, even for straight c) and NetBeans are the two best Linux ones (imo).

Secondly, you don't want to do your diff/patching with an IDE. The best visual thing by far is meld. It's much better than the KDE ones (and I say that as a Qt dev / KDE user). After making changes in your working directory, type "meld ." for an awesome view/editing/cleaning.

And thirdly, start small. You're wayyyyyyyyy jumping the gun. Start small. Make some X11 apps. Make some OpenGL ones. Learn C. And learn the public api's well first.

And lastly, (and i know this is going to start a flamewar) but I wouldn't start with git. I've been using it for four months (its our version control system at work, and I still get surprised issues with it. (Compared to svn which I learn in an hour ;D). If you need to version/branch your stuff just use copy and paste, or use something simple like svn for now. You should be focusing on the real stuff (code). Once you start doing more serious coding (with people) you'll see the real advantages of it.

Good luck.

[V!NCENT]

Well, the HowVideoCardsWork page hasn't been updated yet and isn't complete. PCIe and aperturesbare missing. But that doesn't mean I can't learn it. Would it be wise to learn it, or only of I wanted to study history?

I read the diff/sdiff/diff3 info page. Just to compare file differences... KDE has a nice file differences compare app as part of Kdevelop, which might be easyer for me (I think in visuals and not in a logical order, if you know what I mean ).

I have 'studied' some history of X (x386, xfree86, accelerated-x, xsun, X.org) and wondered if I, next to OpenGL and Gallium, have to worry about the Open Group X spec? Or is that X.org today?