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

[Fernan Aguero]

+----[ Hilmar Lapp <hlapp at gmx.net> (26.Jun.2006 11:01):
| 
| 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? 

No, I never said or implied that.

| Or post an email to the list saying what you think is the
| right way and then do  it (yourself)?

Of course I could volunteer some of my time to
do that (that is, go over the commit history and see what
changes could be merged back to 1.4, if that seems to be
useful), provided I get a polite reply to my 'email
to the list saying what [I] think is the right way'.

I'm a volunteer in other open source, community projects,
and I do contribute regularly so I see no problem except the
obvious scarcity of free time in doing the same for bioperl.

| >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?

Seems like you were pissed off by what I said ...

What I was just trying to say is that merely by formulating
and communicating a policy you could be taking steps towards
making it a reality. Maybe 'enforcing' was an unfortunate
word to use here ... 

You don't have to punish anyone, just sending a polite email
to the list reminding people about the policy once in a
while, should be enough. It's OK if some committer doesn't
care, or just forgets about doing the right thing once in a
while ...

But of course, you might be pissed off by me talking about
something that I know nothing about (the devleopment of
bioperl), given that I'm just a bioperl user.

Perhaps my mistake was to bring here ideas from
other projects (in which I do contribute regularly) without
realizing that, not being a contributor, I could be
punished for suggesting how things could be done better.

| 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.

I completely agree. When I said 'setting a policy' I just
meant something along the lines of clearly stating what are
those 'rules everybody needs to follow'. My suggestion was
to add a 'merge trivial fixes back to stable' rule to that
list.

I agree with Jason: why is that such a big deal. 

| 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.

Right, but first i have to realize what needs to happen. I
realized it when I read your reply to Philips message.

I then proceeded to write my thoughts and send them to the
list, to see what kind of feedback I get. 

Hopefully, someone with commit privileges would think that
what I said makes sense and just proceed to doing it (saving
me from the task :)

Or perhaps, someone, as Jason did, would say that it's
not worth to try to merge back things to 1.4 and move
forward instead. In his message he even explained what the
problems and needs are (lack of man-time, need for
volunteers) and politely asked for help.

| 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 would call your reply (this message) a barrier of entry
for new developers. In the above paragraph I guess you are
referring to the bioperl motto: 'whoever codes it wins'.
That is true in any open source project. But at least to me,
that doesn't say that you should not listen to people just
because they haven't contributed a single line of code.

| 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. 


Let me disagree. The barriers of entry are not just the
giving away of a developer accounts and/or repository write
privileges. 

I'm a regular contributor in another open source, community
project (FreeBSD) that has more and higher barriers of entry
with respect to giving away privileges (for example for
committing changes to the repository). Nonetheless FreeBSD
has historically shown to have few and low barriers of entry
for incorporating people to the project (without the need to
give away commit privileges, making them responsible for
parts of the FreeBSD source code/documentation/ports/etc).

IMO, that comes from a very good communication of the
direction of the project, what needs to be done, how to do
it, and a tendency of privileged and older members to listen
to people's suggestions, inviting and helping people
to jump the fence and become part of the project. It's not
an untought occurrence that FreeBSD has ´mentors´ that
introduce new members, help them to get acquainted with how
the project works, policies, etc. and supervise their
actions.

| This doesn't come without some degree of  
| anarchy, but really IMHO that's more of an advantage than a  
| disadvantage.
| 	-hilmar
|
+----]

Fernan

PS: finally, let me just add that english is not my native
language. Although I'm quite familiar with it, once in a
while, an unfortunate choice of words might blur my intented
meaning or the strength I wanted to convey. In case that has
been the case, let me put clearly that it has not been my
intention to criticize the way the project does things, but
to suggest ideas for the future (merge back trivial changes
to a 'stable' branch as a policy) based on my experience
with other projects. Whether that fits bioperl or not was
what I would have expected as a reply.