Hi Michael,
I've downloaded the patch, but it is too unwieldy to apply! It's 418
kB in size and includes an innumerable number of changes! This is
insane!!! For example it includes:
new dialogs,
cross-platform compatibility fixes using os.sep,
numerous GUI changes,
T1 to R1 renaming,
bug fixes,
expansion of exec_model_free(),
addition of comments,
removal of the "from xxx import *" notation,
a shift from running a script to hooking into the relax API,
and many other changes.
Such a large change would in most software projects be instantly
rejected, and with good cause. It is too big to review, to check, to
test, and to suggest improvements, how to better integrate into relax,
etc. The proper way (actually the only way!) to code in a software
project is to have a separate commit (or patch) for each item listed
above. Each commit must correspond to one type of change. This is a
golden rule that needs to be followed. One of many benefits of this
standard is that, for example, if the expansion of exec_model_free()
is later decided to be incorrect the commit can be reverted in one
simple SVN operation. If you have difficulties with the slow speed of
this initial stage of me applying the patches, then maybe you could
have a look at the GIT interface to SVN that Gna! provides. This will
allow you to have a local repository copy and make commits out of each
of your changes. Then you could go back through the history and
submit each change as a separate patch, with an appropriate commit
message.
So to synchronise the branch to match your current code, there are a
few options. The ideal would be to separate out this massive patch
into its individual components. Some of these will be quite simple.
Either you or I could do this, and then your copy synchronised each
time. For the GUI changes, I would need your help in identifying
which sets of related changes belong to one commit. Alternatively, as
a once off, you could write a huge commit message detailing every last
change (possibly with reasons and links to archived mailing list
messages) and I let this one massive patch through. Note that this
solution is very far from perfect and would in all other projects be
instantly rejected. For example see what happens in Linux
development. A good explanation is given in reason "a" for patch
rejection in the post to the Linux kernel mailing list at
http://lkml.indiana.edu/hypermail/linux/kernel/0009.2/0599.html. In
the end to be granted commit access to the repository, you will need
to demonstrate that you can create individual commits corresponding to
single concepts with appropriate commit messages.
Regards,
Edward
2010/1/7 Michael Bieri <NO-REPLY.INVALID-ADDRESS@xxxxxxx>:
Follow-up Comment #11, task #6847 (project relax):
Another patch.
There was a error with my coding. It is fixed now. Everytime when another
window was opened, an application stacked on each other.
-> patch_II
cheers
(file #7620)
_______________________________________________________
Additional Item Attachment:
File name: patch_II Size:418 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?6847>
_______________________________________________
Nachricht geschickt von/durch Gna!
http://gna.org/
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: [task #6847] The Bieri graphical user interface.