[Bioperl-l] How to handle bugs in bioperl 1.4 on CPAN?
Jason Stajich
jason at bioperl.org
Mon Jun 26 14:13:00 UTC 2006
fair enough - we can certainly merge fixes onto the branch - I am
not sure why that is such a big deal.
once the changes are made to the branch, If someone then wants to
update to the latest code on 1.4 branch, they would to volunteer
to do the last step of:
cvs export -r branch-1-4 -d bioperl-1-4-1 bioperl-live
then validate it, then make a tar ball, we can submit a 1.4.x to
CPAN, but honestly a lot of other fixes have accumulated since the
1.4 branch and I don't think we want to keep merging back to it, we'd
rather move forward. the not-so-compatible changes that got checked
in after the 1.4 branch (having to do with Annotateable) has been
part of the problem as this has not been fully fixed to make things
backwards compatable.
Nathan asked earlier on the list about how to get a list of modules
added since 1.4 and I can only say how to generate a diff to the
current version of the code which might be more than what he is
asking for. read the docs on cvs diff where you specify the two tags
you want to diff between.
We certainly have a problem of meeting the needs of several different
user groups - developers who need latest code, and users who want
stable releases. We either get funding to support stable releases
more deliberately, things that don't seem to be on the main radar
screen of primary developers or people who are tied to working with
older stable releases. Since most of us who are coding and making
changes are just working from a CVS checkout we don't have a lot of
pressure to make a release -- and we don't want to dump newly buggy
(or broken interfaces) into CPAN on purpose. It also seems like many
reported bugs have already been fixed on the latest branch but people
are less interested in back-fixing on the old branch.
Our hope is that 1.6 would be a good replacement for 1.4 - presumably
API consistent for the most part, but we are suffering from lack of
time of people willing to do the work to make this happen.
I have mentioned in the past that I cannot be the release master for
the project and it is time for someone else to step up and make this
happen. Chris Fields has done a phenomenal job answering questions,
fixing bugs, and helping run the project as some of us have started
to have too busy of a schedule to keep daily tabs on Bioperl. But he
too will probably have to cycle off as his career responsibilities
(and job search) takes more time. I don't have a good answer for
anyone on how to make this happen more smoothly, I am hopeful that
the gmod mtg will spur some more commits and a roadplan for releasing
the next dev release and seeing what can happen with 1.6. If we
funded a Bioperl coordinator I am sure that would help things more
and manage the different sets of priorities of the user groups.
I think a dedicated hackathon to bioperl work could get 1.6 out after
one week of solid work with some bug squashing followup.
Barring that we'll have to see what everyone else wants to see done
to get the next release out. The person leading the release doesn't
have to really program things they just need to organize people
around a time-frame, a set of features that need to be tested and
fixed, and commitments from people of what they will do.
Much of the release process is documented on the bioperl wiki site,
if this is not clear enough please make a note on the page/talk page
and we can start . My hope is that the wiki can be a good repository
of the thought process behind the project. right now too much of it
is floating in the minds of former and current project coordinators.
...just some of my thoughts as I get ready to be off-line starting
next week for 4 weeks...
-jason
On Jun 26, 2006, at 8:47 AM, Fernan Aguero wrote:
> +----[ Hilmar Lapp <hlapp at gmx.net> (26.Jun.2006 07:22):
> |
> | We did not and will not deposit 1.5.1 into CPAN due to the API
> issues
> | in some (rather central) interfaces. These issues are changes over
> | the 1.4 API and some of those changes are going to go away. Once we
> | deposit it into CPAN we would sanction the changed API as the new
> | 'official' API and would open a huge can of backward liability
> worms.
> | If you just continue to use the 1.4 API on the 1.5.1 release you
> | don't need to be concerned about an API method you're using going
> away.
> |
> | As I said, the people from the core group of developers who have
> | traditionally shepherded releases all think that doing a 1.4.1
> | release wouldn't be the best investment of their time. You are most
> | welcome to disagree and volunteer your time to coordinate the 1.4.1
> | release, and a lot of people will appreciate your efforts -
> including
> | the bioperl developers and 'core'. It shouldn't be much work
> | theoretically.
> |
> | -hilmar
> |
> +----]
>
> I understand that, being a volunteer project, people can
> decide where to best invest their time. If core developers
> are no longer using 1.4 in their production setups, it is
> reasonable to expect that they invest all of their time in
> 1.5 or any other bioperl version that they're using.
>
> However, when view as an issue related to the setting of a
> policy for the whole project, then it makes sense to have a
> policy saying for how long a stable release will be
> supported, and when and in which case bugfixes that are committed
> to and tested in the development branch (as it should be)
> will get merged back to stable.
>
> 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.
>
> But you only get this by setting and enforcing a policy.
>
> After a number of these fixes has accumulated, then making a
> new release shouldn't represent too much effort, nor it
> should be expected that the tests that passed before would
> break now. And in the worst case (no tarball release),
> people can be directed to obtain the most current 'stable'
> code from the repository, containing all bugfixes.
>
> I guess that this is what was meant by Phillip.
>
> Fernan
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
--
Jason Stajich
Duke University
http://www.duke.edu/~jes12
More information about the Bioperl-l
mailing list