[Bioperl-l] How to handle bugs in bioperl 1.4 on CPAN?
cjfields at uiuc.edu
Mon Jun 26 16:18:40 EDT 2006
> | >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.
Right, you didn't say that. But you didn't clarify your statements either.
I think you're treading into dangerous waters when you come in and criticize
something w/o bothering to read up on how things have been done here. As
you say yourself below, it's 'something that I know nothing about (the
devleopment of bioperl), given that I'm just a bioperl user'. It's akin to
"I don't think you're coding things correctly, here's the right way to do
it" w/o knowing what the code is used for.
> | 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'.
You will get a polite email when you respond politely. I actually agree
with many things you say, but you sure aren't making any friends here by the
way you consistently take the opposite stance and judge what other people
do. I think you have a point about having a stable release be supported for
a period of time. My point is, how long? We didn't really get an idea of
that from you, did we?
> 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.
And others here also volunteer elsewhere (GMOD, DAS, Ensembl, etc). Don't
presume we don't have experience in open-source. That's being pretty
> | >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 ...
You know, okay, forget it. This is completely non-productive. We'll all
agree to disagree, argue, whatever. The points made here, as I see them:
1) Commits should be made to stable releases (as well as to the main branch
in CVS) to fix bugs as long as that release is supported. I agree with
this, but someone has to volunteer, and the length of time a release is
supported also worked out. Almost would be better going to a regular
release schedule (once every 3-6 months or so) where the code is given as is
to CPAN, whether it passes tests or not.
2) More communication about the direction Bioperl is heading; personally I
haven't see a problem with this as much as there is no information about a
roadmap. That is being alleviated soon I believe, thought people out there
need to be patient.
3) Volunteer. If you have something you believe needs to be done and you
believe so fervently, then put up or shut up. Make (nice polite)
suggestions otherwise. Don't judge code or "the way things are done" and
don't presume what kind of experience people have that you don't know and
haven't met. End of story.
More information about the Bioperl-l