[Bioperl-l] How to handle bugs in bioperl 1.4 on CPAN?

Hilmar Lapp hlapp at gmx.net
Mon Jun 26 09:59:00 EDT 2006


On Jun 26, 2006, at 8:47 AM, Fernan Aguero wrote:

> I'm not knowledgeable enough about the bioperl release
> engineering process, nor about the internal development
> process, but just guessing I'd expect that whenever anyone
> submits a bugfix, it should be the responsibility of
> the committer to check (against the project policy,
> (written or implicit) or with the core developers in a
> difficult case) whether the fix should be committed to more
> than one branch.
>
> A patch like the one that started this thread, should have
> been committed to the 1.4 branch without too much thinking.
> And it would have cost the committer only a few seconds more
> of her/his time.

Sure. But for some reason he or she forgot. So what do you suggest we  
do - and I mean as a community, because this is a community project.  
Come after the guy  until he commits it to the branch? Or post an  
email to the list saying what you think is the right way and then do  
it (yourself)?

>
> But you only get this by setting and enforcing a policy.

Man, this is not a company. Take a step back and think again. What do  
you suggest we - again we as a community - do to enforce a policy?  
Take increasing levels of disciplinary action if someone keeps  
forgetting to commit to the branch?

While there are clearly some rules everybody needs to follow and if  
you violate them deliberately and repeatedly you will get your CVS  
privileges withdrawn, by and large we as a community need to accept  
some responsibility for making the project what we think it should be  
- and do so not by invoking disciplinary action but by living by  
example and by taking action yourself when you think action is due.

If Bioperl were a company and you asked for a 1.4.1 release and the  
customer service rep told you nope there's a 1.5.1 that you should  
use instead and that will do just fine, what will you do? Argue with  
him about the company policies and whether they are properly enforced  
or not?

Obviously doing so will be a waste of your time. In Bioperl it is at  
the bottom of it no less waste of your time, because instead you now  
have the opportunity to make happen what you believe needs to happen.  
We have had a history of rapidly and un-bureaucratically putting  
people in power of what they wanted to do. We have also had a history  
of not listening much to people who don't want to put their feet  
where their mouth is.

I'm sorry if what I'm saying puts people off, but really this is an  
open-source project and if you ask me it's one with the least  
barriers of entry for new developers or 'activists' that you can find  
in the open source arena. This doesn't come without some degree of  
anarchy, but really IMHO that's more of an advantage than a  
disadvantage.

	-hilmar
-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================







More information about the Bioperl-l mailing list