Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Fetching contributors…

Cannot retrieve contributors at this time

162 lines (126 sloc) 7.587 kB
For developers assisting on pyjamas, a laissez-faire attitude is taken:
if you want repository access, all you have to do is ask. Follow the
rules below, and you'll do ok with this multi-project project:
* break stuff in latest repo, it gets reverted. the prime rule of pyjamas
is that the latest repository code MUST work, for production environments
to be able to use it.
* other than that, please feel free to announce on the list "i'm going to do
xyz, any objections or input" but otherwise just happily take the initiative.
if however you are not an experienced developer then feel free to ask at
each stage before proceeding.
* obey PEP8 where it's sensible to do so. there's a program called pep8.py
which automatically checks stuff. one rule we have to break is to remain
consistent with GWT function names - it's just... tough luck :) that,
and properties in pyjs are too expensive, we have to use the silly
get{Property} and set{Property} function names. oh well.
* please add yourself to copyright and CREDITS. if kindly committing someone
else's patch, please add them rather than yourself, of course.
this is IMPORTANT. the copyright file is crucial for the acceptance of
pyjamas into debian: each and EVERY single copyright holder MUST be
recorded. please note that the copyright file is in the format specified
by debian DEP5 (which is pretty blindingly obvious, but just... please bear
it in mind that the copyright file is in a machine-readable
standards-compliant format)
* please ONLY ADD SOURCE CODE and ONLY ADD PYJAMAS-RELATED source code.
on no account add the source code of an external project to pyjamas:
create a download script which fetches and unpacks a stable revision
of that code.
on ABSOLUTELY NO ACCOUNT add any binary-object files, executables,
fonts, external images that were written by and for other projects,
or anything OTHER than pyjamas source code.
if however an image is required for example as part of CSS styling in the
examples, and the image's Copyright is your own, or the License on the
image can be established to be a compatible Software (Libre) License, then
it *may* be added to the repository.
also please remember that the javascript that is auto-generated by
the pyjamas compiler is also considered to be "object code", and as
such should NEVER be added to the pyjamas repository.
anything that is needed must either be downloaded or it must be
compiled (or both). there are at present three download.sh scripts
(in the examples) which can be used for inspiration and guidance.
if in doubt - ask on the developer list BEFORE committing because it is
a royal pain to permanently destroy-delete files in git.
* pyjamas UI development: follow GWT source code as closely as possible.
make use of java2py.py (in contrib) to do 95% of the conversion work for
you. don't just follow the GWT API: do _literally_ "blindly" follow
the GWT source code, trusting it pretty much 100%. _don't_ try to
second-guess it; _don't_ try to "rework it"; in fact, don't _think_ at
all: just "go with the flow". the reason is simple: the GWT team have
far more resources than we do, and if you want to re-learn all of the
"browser tricks" that they've spent man-decades finding and working
around _go ahead_ :)
if GWT source doesn't exist: try to find some. if you _really_ can't
find anything, then find something that's pretty close to what you want,
subclass it if possible, and go from there.
also: make DAMN SURE that you are aware of the __browser__, __{engine}__
and the platform/* overrides systems BEFORE messing with UI code.
* before pyjamas UI committing:
check as _many_ engines and browsers as you can using as many
examples as you can stand, using both --strict _and_ -O for browsers.
if you don't have certain engines or browsers, TELL PEOPLE and ask them
to test on your behalf. preferably before committing.
* non-UI-related stuff (compiler-related) make damn sure you run libtest
with --strict and with standard http://python.org; and do consider running
under pyv8run.sh as well (./pyv8test.sh --strict). as there's a 64-bit
version of libv8, now, that's not as hard as it used to be: pyv8
now compiles native on 64-bit.
also: compiler-related additions and changes _must_ be accompanied by
a unit test (hence the reason why libtest must be run, under so many
different environments).
* commits must be "single purpose". if you're thinking of using the word
"and" in the commit message, STOP and think. see very first rule as
to why this is important: i.e. if you break something, the WHOLE commit
will be reverted; NO effort will be spent "dividing" the patch, when that
should have been done by you in the first place.
* special version of the above: please _don't_ do major whitespace
reorganisations at the same time as coding patches. keep them separate,
and commit whitespace patches with a commit message mentioning "whitespace".
duh.
* commit messages must describe the patch not the action being taken!
"added this"; "removed this" are NOT ok.
* commit messages should really include the bugreport number of the issue
being fixed. if there isn't a bugreport number, you should consider
raising one. it's just good practice.
* please try to keep discussion of bugs to the bugtracker, but also make
sure that the pyjamas-dev list is alerted when a bug is raised. it might
not always work out that way, and if it doesn't, that's fine: it's just
nice to be able to know what the hell's going on with a particular bug,
without having to hunt through the rather obtuse pyjamas-dev google group.
that's about it. the rest - do what you like! make sure you keep
people informed, engage them to help do testing.
DEVELOPER GIT BRANCHES
as it's probably well know, git makes branching super easy and cheap.
individual, public-facing branches should be in the form of:
<username>/(bug|feat)/<module>/<issueid>-<description>
username = SourceForge user
bug|feat = whichever appropriate
module = the affected module, if any, or bootstrap/builtin/etc.
issueid = the issue corresponding to this branch, if any
description = a small description of the branch's activities/purpose
this will assist anyone testing/observing.
example (developer):
# git clone git://pyjamas.git.sourceforge.net/gitroot/pyjamas/pyjamas
# git config remote.origin.pushurl ssh://<username>@pyjamas.git.sourceforge.net/gitroot/pyjamas/pyjamas
# git config remote.origin.push "refs/heads/<username>/*:refs/heads/<username>/*"
# git checkout -b <userXZY>/bug/101-default-stylesheet
# ...working/commiting/building...
# git push
(branch get reviewed/tested/accepted)
# git checkout master
# git pull
# git rebase -i <userXZY>/bug/101-default-stylesheet
(remove any merge commits)
# git push origin master
the remote.origin.push config option will enable pushing all your
branches by default. when you want to push to master (public), you must
specify explicitly.
exxample (user):
# git clone git://pyjamas.git.sourceforge.net/gitroot/pyjamas/pyjamas
# git checkout -b testing <userXYZ>/bug/101-default-stylesheet
# git merge master
# python bootstrap.py
(build apps/examples/etc.)
the checkout command will create a new branch, "testing", based off
the remote branch "<userXZY>/bug/101-default-stylesheet". you can
switch between branches (testing different builds) without re-running
bootstrap.py. for each new branch, merge "master".
Jump to Line
Something went wrong with that request. Please try again.