developer protocols

[Iain Buchanan]

Hi,

I'm about to do some commits, but it got me thinking - I will most
likely not get a reply till later (which is fine) but what are the
unwritten rules you guys follow (if any)? eg. testing, QA, etc.

I was checking out how shiny my name looked here
http://sourceforge.net/project/memberlist.php?group_id=30550 and I
thought "wow, 30 devs". Then I thought "are they all active?". And
finally I thought why not take a leaf out of Gentoo's book and make some
notes for developers. Not necessarily "I want to be a dev", but more
like "I am a dev, and I forgot what so-and-so said about directory
structure" or something.

If anyone thinks this would be useful, reply by email and I'll happily
throw your notes together on the wiki.

thanks,

[David Eriksson]

Post by Iain Buchanan
Hi,
I'm about to do some commits, but it got me thinking - I will most
likely not get a reply till later (which is fine) but what are the
unwritten rules you guys follow (if any)? eg. testing, QA, etc.
I was checking out how shiny my name looked here
http://sourceforge.net/project/memberlist.php?group_id=30550 and I
thought "wow, 30 devs". Then I thought "are they all active?". And
finally I thought why not take a leaf out of Gentoo's book and make some
notes for developers. Not necessarily "I want to be a dev", but more
like "I am a dev, and I forgot what so-and-so said about directory
structure" or something.
If anyone thinks this would be useful, reply by email and I'll happily
throw your notes together on the wiki.

For a long time (pre-WM5), SynCE was pretty much a two-man shop with
Volker and me, while others made guest appearances of various magnitude.
We could either keep the membership list as "credits", or we could clean
it. (I'm still a member of the ScummVM project but my last commit was 4-5
years ago... :-)

By the way, I'm very, VERY, happy that SynCE development regained velocity
with the WM5 support!

Anyway, I have never tried to impose any rules on the development because
I was happy for every little contribution I could get! That's why there is
inconsistent spaces/tabs in source code, different licenses, etc. I did it
my way (two spaces for tab, MIT license, etc) while others did things
their way (GPL license, etc).

I'd say that this is a maturity thing for a project and it could be that
SynCE has reached a point where some structure would be beneficial.
However, I will try to not interfere in this more than with this mail...
:-)


Cheers,

David

[Iain Buchanan]

Post by David Eriksson
For a long time (pre-WM5), SynCE was pretty much a two-man shop with
Volker and me, while others made guest appearances of various magnitude.
We could either keep the membership list as "credits", or we could clean
it. (I'm still a member of the ScummVM project but my last commit was 4-5
years ago... :-)

I'm happy either way - it was just a tangent.

Post by David Eriksson
By the way, I'm very, VERY, happy that SynCE development regained velocity
with the WM5 support!

me too, esp since I have a WM5 device :)

Post by David Eriksson
Anyway, I have never tried to impose any rules on the development because
I was happy for every little contribution I could get! That's why there is
inconsistent spaces/tabs in source code, different licenses, etc. I did it
my way (two spaces for tab, MIT license, etc) while others did things
their way (GPL license, etc).

actually, I wasn't thinking about those sorts of protocols, although
that's interesting too. I was thinking about helpful stuff, like some
svn examples, ebuild QA checking (eg. making manifests), other distro
info (how to sign rpms or whatever), and whatever else people might find
useful.

Perhaps it's just me...

Post by David Eriksson
I'd say that this is a maturity thing for a project and it could be that
SynCE has reached a point where some structure would be beneficial.
However, I will try to not interfere in this more than with this mail...
:-)

Voicing your opinion is not interfering :) Anyway I wasn't thinking
about rules to follow, more just helpful hints.

Post by David Eriksson
Cheers,
David

Prost!

[Vasco Steinmetz]

Post by Iain Buchanan
actually, I wasn't thinking about those sorts of protocols, although
that's interesting too. I was thinking about helpful stuff, like some
svn examples, ebuild QA checking (eg. making manifests), other distro
info (how to sign rpms or whatever), and whatever else people might find
useful.

Doesn't SynCE have a Wiki? :>

Post by Iain Buchanan
Prost!

Cheers,
Vasco

[Guido Diepen]

Post by Vasco Steinmetz

Post by Iain Buchanan
actually, I wasn't thinking about those sorts of protocols, although
that's interesting too. I was thinking about helpful stuff, like some
svn examples, ebuild QA checking (eg. making manifests), other distro
info (how to sign rpms or whatever), and whatever else people might find
useful.

Doesn't SynCE have a Wiki? :>

There always was a Wiki. Best feature of the current wiki though is that
it is not locked ;)

Guido Diepen

[Iain Buchanan]

Post by Vasco Steinmetz

Post by Iain Buchanan
actually, I wasn't thinking about those sorts of protocols, although
that's interesting too. I was thinking about helpful stuff, like some
svn examples, ebuild QA checking (eg. making manifests), other distro
info (how to sign rpms or whatever), and whatever else people might find
useful.

Doesn't SynCE have a Wiki? :>

mezactly what I was going to use, however if I just make the wiki page
either no-one knows, or no-one wants it. Whereas if I discuss it here
first I can gauge interest and get ideas, then draft a page if
necessary.

btw, none of this stuff is on the wiki yet I think... Correct me if I'm
wrong.

cya,

[Richard Alimi]

Post by Iain Buchanan
actually, I wasn't thinking about those sorts of protocols, although
that's interesting too. I was thinking about helpful stuff, like some
svn examples, ebuild QA checking (eg. making manifests), other distro
info (how to sign rpms or whatever), and whatever else people might find
useful.

If you want an SVN tutorial, the SVN Book (http://svnbook.red-bean.com/) is
actually _extremely_ well-written and provides very good examples for various
SVN operations, and explains lots of scenarios that arise in version control.

As for Gentoo ebuilds, what I had done was configure my /etc/make.conf with a
local overlay. Then before committing changes to SVN I could be sure that
the build worked and all the manifets/digests were correct and that things
were basically working. I'm guessing you've been doing something similar to
this already though :)

I seem to recall seeing QA tools that were done by Gentoo developers for
ebuilds, but I haven't used them. I guess I woudln't be surprised if they
found problems with our current set of ebuilds :) If its possible to
incorporate those QA tools, that would be pretty nice, but I don't seem to
see that as a large priority since we don't have too many ebuilds (in
comparison to the entire Portage tree).

[Iain Buchanan]

Post by Richard Alimi
As for Gentoo ebuilds, what I had done was configure my /etc/make.conf with a
local overlay. Then before committing changes to SVN I could be sure that
the build worked and all the manifets/digests were correct and that things
were basically working. I'm guessing you've been doing something similar to
this already though :)

yep :)

Post by Richard Alimi
I seem to recall seeing QA tools that were done by Gentoo developers for
ebuilds, but I haven't used them.

repoman

Post by Richard Alimi
I guess I woudln't be surprised if they
found problems with our current set of ebuilds :)

*heh* only over 100 QA issues... repoman is really fussy - but then he
has to be with over 25000 ebuilds in the official tree...

Post by Richard Alimi
If its possible to
incorporate those QA tools, that would be pretty nice, but I don't seem to
see that as a large priority since we don't have too many ebuilds (in
comparison to the entire Portage tree).

Having repoman report 0 (or few) QA issues will become a pre-requisite
to getting the ebuilds into the official source tree. But feel free to
leave that to me - I have to learn how to use it anyway if I want to do
any gentoo commits.

well it's after midnight... I need to get the 0.11 ebuilds in before I
fall asleep... No more from me for now :)

thanks,

[Richard Alimi]

From my personal standpoint, I just really care that the code is clean and
readable. I understand that the term "readable" is subjective, but someone
shouldn't have to sit there for an hour trying to figure out what a single
function is doing :)

Another thing that I always try to do before a commit to SVN is be sure that
the code at least compiles, especially if its under /trunk. Whether it works
or not is another story, but someone should be able to take it out of SVN and
build it without errors. This is a bit different when it comes to Python
where some errors (i.e., some undefined variables) aren't flagged until the
interpreter hits that line of code, but the interpreter should still be able
to load the files and start running them.

If there are massive changes to something (re-architecting, etc) it would
probably be easier to do the development in a branch instead of the trunk.
Then it won't impact those people building from SVN, and you can also have a
bunch of smaller commits during the development. To keep SVN clean with this
approach, things should be merged back in to /trunk when done, and the branch
should be deleted. Having code in a branch compile/run all of the time
probably isn't crucial.

Of course, this are just suggestions to hopefully avoid headaches down the
line. Like David I will stay out of the way and if something breaks, it
breaks. :)
--
Richard Alimi
Department of Computer Science
Yale University

Post by David Eriksson

Post by Iain Buchanan
Hi,
I'm about to do some commits, but it got me thinking - I will most
likely not get a reply till later (which is fine) but what are the
unwritten rules you guys follow (if any)? eg. testing, QA, etc.
I was checking out how shiny my name looked here
http://sourceforge.net/project/memberlist.php?group_id=30550 and I
thought "wow, 30 devs". Then I thought "are they all active?". And
finally I thought why not take a leaf out of Gentoo's book and make some
notes for developers. Not necessarily "I want to be a dev", but more
like "I am a dev, and I forgot what so-and-so said about directory
structure" or something.
If anyone thinks this would be useful, reply by email and I'll happily
throw your notes together on the wiki.

For a long time (pre-WM5), SynCE was pretty much a two-man shop with
Volker and me, while others made guest appearances of various magnitude.
We could either keep the membership list as "credits", or we could clean
it. (I'm still a member of the ScummVM project but my last commit was 4-5
years ago... :-)
By the way, I'm very, VERY, happy that SynCE development regained velocity
with the WM5 support!
Anyway, I have never tried to impose any rules on the development because
I was happy for every little contribution I could get! That's why there is
inconsistent spaces/tabs in source code, different licenses, etc. I did it
my way (two spaces for tab, MIT license, etc) while others did things
their way (GPL license, etc).
I'd say that this is a maturity thing for a project and it could be that
SynCE has reached a point where some structure would be beneficial.
However, I will try to not interfere in this more than with this mail...
:-)
Cheers,
David
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

[Mark Ellis]

On Wed, 2008-01-16 at 09:02 -0500, Richard Alimi wrote: