PDA

View Full Version : Jumping In



JJZolx
2005-07-05, 15:19
Is there a how-to on how the checkout/checkin process works for contributors? Or maybe some practical pointers on how to work with the code during development/testing on one's local system?

Are there any general guidelines on how more (for a lack of a better phrase) "advanced" design changes are effected? It strikes me that I see relatively few philosophical discussions regarding implementation on this list. Given that most developers are actually employees of Slim Devices, I'm guessing there's quite a bit of behind-the-scenes discussion taking place via email. Should I gather from this that outside developers are expected to just contribute plugins, bug fixes and "smaller" changes?

Dan Sully
2005-07-05, 15:30
* JJZolx shaped the electrons to say...

>Is there a how-to on how the checkout/checkin process works for
>contributors? Or maybe some practical pointers on how to work with the
>code during development/testing on one's local system?

Jim - the best way to get started is to check out the code via Subversion.

http://www.slimdevices.com/dev_resources.html#subversion

You can grab Subversion binaries from here:

http://subversion.tigris.org/project_packages.html

>Are there any general guidelines on how more (for a lack of a better
>phrase) "advanced" design changes are effected? It strikes me that I
>see relatively few philosophical discussions regarding implementation
>on this list. Given that most developers are actually employees of
>Slim Devices, I'm guessing there's quite a bit of behind-the-scenes
>discussion taking place via email. Should I gather from this that
>outside developers are expected to just contribute plugins, bug fixes
>and "smaller" changes?

Usually by bringing it up on the list. You are right in general about the
large decisions are made here at the office. But there have been some sizable
ones that people have done, such as Adrian's display changes, and kdf's
importer reworking. Those are sometimes pre-announced/discussed, but other
times a large patch shows up on the list, and we accept it.

I started out as a contributor to the code base 5 years ago - and only became
an employee in the past 6 months. :)

There's no hard and fast way to do it.

Let me know if you have any more questions.

-D
--
Sir, are you classified as human?
Uhh, negative, I am a meat popsicle.

kdf
2005-07-05, 20:36
Quoting JJZolx <JJZolx.1rpwfb (AT) no-mx (DOT) forums.slimdevices.com>:

>
> Is there a how-to on how the checkout/checkin process works for
> contributors? Or maybe some practical pointers on how to work with the
> code during development/testing on one's local system?

As Dan suggested, subversion and subclips is the way to go for windows platform.
Don't forget activestate perl, since compiling your own exe isn't economical.
Initially its read only for subversion, but you can post diffs to the list, or
gzip them as needed and beat on someone with write access to test it and merge.

> Are there any general guidelines on how more (for a lack of a better
> phrase) "advanced" design changes are effected?

IF its a bug/enhancement report, drop the patch there and let ppl have a look.
Some of the users can test and give feedback. Other stuff can go to the dev
list, where everyone will be a critic and you wait for Dean, Dan or Vidur to
give final say.

> It strikes me that I
> see relatively few philosophical discussions regarding implementation
> on this list.

and a good thing too. it would get very long-winded.

> Given that most developers are actually employees of
> Slim Devices, I'm guessing there's quite a bit of behind-the-scenes
> discussion taking place via email. Should I gather from this that
> outside developers are expected to just contribute plugins, bug fixes
> and "smaller" changes?

plugins, bug fixes, new features long left stagnant for lack of resources.
Smaller, mostly, simply due to the part time nature of us third-party types.
Then again, you can sometimes end up finding things tossed your way. Each
developer tends to stick to certain areas of the code, so it can happen that an
'outside' party is really the best person to tackle a given task.

welcome to the fishbowl :)
-k