[Biopython-dev] Quality scores (and per-letter-annotation) in a SeqRecord?

[Giovanni Marco Dall'Olio]

On Mon, Feb 23, 2009 at 3:24 PM, Peter <biopython at maubp.freeserve.co.uk> wrote:
> On Mon, Feb 23, 2009 at 1:50 PM, Giovanni Marco Dall'Olio
> <dalloliogm at gmail.com> wrote:
>>
>> I suggest you to use github or any distribuited source versioning
>> system to test the changes you are describing in this discussion.
>>
>> ...
>>
>> I think that it is easier to discuss over this if you can show how the
>> code would look like instead of only describing it.
>
> Or we can stick with the old fashioned approach of uploading patches
> to bugzilla.  This proposal only requires additions to
> Bio/SeqRecord.py to define the new property, and won't change much
> existing code at all.

Of course you can stick with bugzilla, but let me explain why I think
using a drcs would be better :-).
Basically, you should consider that with a drcs you can create forks
very frequently, even for three or four commits, and when you have
finished you merge the changes back and nobody will ever know that
there it was a fork.

If you want to change an attribute to SeqRecord, this doesn't imply a
single commit: you have to test various solutions, provide tests for
each of them, see which one is the most comfortable, and only then,
push it in the official release.

Basically, what you do now is similar to what you would do with a
drcs: each one of you will probably have a modified copy of biopython
on his computer, and when he will have finished he will create a patch
or commit to the cvs system.

However, the problem is that these local copies are on local
computers, and for other people it is very difficult to evaluate them
and to give good feedback. Moreover, these copies can become out of
synchronization with the official branch.
You can post some code snippets via mail, but you probably won't post
the tests and many other things.

If you create an experimental branch to test the new attribute to
SeqRecord, along with its tests and all the separated commits for
every change, and post it on a publicly accessible web site, then it
will be possible to discuss a lot more over the changes, and I think
this could improve the biopython's development process.


>
> I can see there are benefits to using a distributed source version
> system for  more complicated patches touching lots of files, but it
> isn't needed here and (if you don't have git installed) using github
> might it actually make it harder for people to try the code on their
> local machine.
>
> Peter
>



-- 

My blog on bioinformatics (now in English): http://bioinfoblog.it