[Bioperl-l] bioperl-dev or branch?

Mark A. Jensen maj at fortinbras.us
Fri May 22 02:02:12 UTC 2009


Also wanted to chime in briefly here--for me as a new developer, commit
access to The Trunk is a little scary, but bioperl-dev seems friendly,
so I find I'm more comfortable putting my hare-brained schemes there
where I know I won't break anything, but experienced folks can monitor,
comment, ignore, get excited, emit raspberries, etc. the whole time. So I'm
committing and developing where I might otherwise have shied away. In
this way bioperl-dev may be an encouragement to the liberal tradition you
describe.

also:
> When a bioperl-dev module graduates to the core, then the usual  support 
> mechanisms kick in."
>
> I.e., there is a possibility, but no expectation to graduate to core.  I think 
> that's important.

Not "If", but "When"! I had expectation and not possibility in mind!
(My perennial optimism...)

cheers- MAJ
----- Original Message ----- 
From: "Hilmar Lapp" <hlapp at gmx.net>
To: "Mark A. Jensen" <maj at fortinbras.us>
Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>; "Chase Miller" 
<chmille4 at gmail.com>
Sent: Thursday, May 21, 2009 5:00 PM
Subject: Re: [Bioperl-l] bioperl-dev or branch?


> To quote from the thread:
>
> "The idea behind bioperl-dev, as I understand from Chris, is to  provide a 
> sort of sandbox for experimental code. Adventuresome users  should feel free 
> to play with the code there, but not expect much in  the way of support, bug 
> fixes, and the like. There be dragons there.  When a bioperl-dev module 
> graduates to the core, then the usual  support mechanisms kick in."
>
> I.e., there is a possibility, but no expectation to graduate to core.  I think 
> that's important.
>
> My sense is that we all agree that we don't want to abandon svn  branches (or 
> do we?). To I'll state the question again: what  disqualifies a development 
> project from going into the main trunk  (thanks to Sendu for keeping this on 
> the table), and what disqualifies  it from going onto a branch, with the 
> remaining resort being bioperl- dev.
>
> I'm worried about fragmentation here - historically we've been a crowd  that 
> has been rather inviting of new contributions into the main code  base and 
> tolerant of those additions needing time to mature, and we  have been lazy on 
> committing on behalf of other people (which merging  patches, branches, and 
> separate repositories on behalf of someone else  is) and hence liberal in 
> giving out commit access, and commit to main  trunk access.
>
> -hilmar
>
> On May 21, 2009, at 4:26 PM, Mark A. Jensen wrote:
>
>> These are key points. I do believe (and think in these terms) that 
>> bioperl-dev modules are intended for the trunk, as soon as they are  not so 
>> broken as to be testable by users. (my interp). See this  thread to refresh 
>> memory: http://lists.open-bio.org/pipermail/bioperl-l/2009-March/029661.html
>>
>> ----- Original Message ----- From: "Hilmar Lapp" <hlapp at duke.edu>
>> To: "Chase Miller" <chmille4 at gmail.com>
>> Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>
>> Sent: Thursday, May 21, 2009 4:00 PM
>> Subject: Re: [Bioperl-l] bioperl-dev or branch?
>>
>>
>>> Moving this question to the BioPerl list, which is where we need  to 
>>> discuss this I think. Can someone refresh my memory on what  the 
>>> Bioperl-dev repository is or was meant for? It doesn't seem  documented  on 
>>> the wiki.
>>> My (admittedly vague) recollection is that bioperl-dev is  basically  for 
>>> highly experimental changes or functionality.
>>> I'm not clear why everything else shouldn't go either into the  main  trunk 
>>> or into a branch. If there is a realistic expectation  for  something to be 
>>> folded into the main trunk sooner or later,  what would  be the reasons for 
>>> not putting it into a branch of the  main  repository? If we are putting it 
>>> into a separate repository,  we're  waiving a lot of svn's support for 
>>> merging and resolving  concurrent  edits.
>>> I would also go actually go a step further and suggest that even  if  this 
>>> GSoC project starts out on a branch (which I can see good  reasons  for, 
>>> such as eliminating fear to disrupt something), there  should be a  plan to 
>>> move to main trunk before the end of the  project. We've had a  good 
>>> tradition in BioPerl of developing  directly on the main trunk. It 
>>> sometimes leads to occasional  disruptions when lots of tests seem  failing, 
>>> but it also  encourages development discipline and make new  code to melt 
>>> into  the BioPerl code base without requiring any extra  steps by someone.
>>> Any and all thoughts or comments welcome and appreciated!
>>> -hilmar
>>> On May 21, 2009, at 11:26 AM, Chase Miller wrote:
>>>> This brings me to a question about where I should have my code 
>>>> repository.  Originally, I was going to use Bioperl-dev, but it  was 
>>>> brought to my attention that that repository does not  normally  receive 
>>>> daily updates and it might not be the right  place for my day  to day 
>>>> development.  An alternative would be to  use something like  google code 
>>>> on a daily basis and commit to  Bioperl-dev on a weekly  basis.
>>> -- 
>>> ===========================================================
>>> : Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
>>> ===========================================================
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
> 




More information about the Bioperl-l mailing list