[Bioperl-l] "progress": useful changes vs. "shiny new thingie"

[Chris Fields]

On Nov 16, 2006, at 3:04 AM, Nathan S. Haigh wrote:

> ...
>> If Build.PL can coexist that'd be great. That would give you the
>> opportunity to have Makefile.PL print out a message right at the
>> beginning that if the installation process messes up one should try
>> Build.PL. This would spare you from fixing any problems in
>> Makefile.PL that are fixed in the Build.PL approach.
>
> Good idea, for anyone downloading the .tar.gz from CPAN if they issue
> "perl Makefile.PL" without knowing Build.PL was there it should
> hopefully work, but if not, issue a comment at the end  to say try  
> "perl
> Build.PL" if anything seemed to go wrong.

That's amazingly similar to the suggestion I made ;>

Seriously, when we make any changes in Bioperl they should be made  
with the community in mind.  If I were to download RC3 directly from  
the website, it uses the old Makefile.PL.  Therefore I would expect  
the new RC and the final release to have a similar installation  
procedure.  Same with CVS.  And I'll note that the CVS docs and wiki  
still state that Makefile.PL is the one to use.

If we can redirect them to the current way, all the better.  But  
sudden dramatic changes, even in a developer release, are probably  
not the way to go.

> If we go for short release cycles, and regular bug fix release, we  
> will
> no longer have to say to users:
> "This is a known bug/issue in release x.y.z, it has been fixed in CVS
> HEAD so get it from there"
> we can roll out fixes in regular releases. This way CVS is then used
> solely by developers and those really wanting to live on the bleeding
> edge code. Therefore, it is important to get Build.PL in place to let
> the release cycle and CPAN packages built quickly, easily and without
> hassle - which I believe is the problem with Makefile.PL as it  
> currently is.

Shorter developer cycles are definitely better.  Like Hilmar  
suggests,  they don't have to be perfect (though relatively bug- 
free).  If you look back through the old releases I don't think  
you'll find many with all tests passing on all OS's.

I would like to get a 1.5.3 out by spring, then start towards  
cleaning up for a summer-fall rel. 1.6.  Maybe that's wishful thinking.

>> Implementing changes like this do require a lot of energy. I very
>> much appreciate that Sendu invested the time and energy to make it
>> work, even though unfortunately at the last hour. Who knows who would
>> have had the energy after the release. If Sendu hadn't put in the
>> work now, the next release master may have been stuck with an even
>> messier Makefile.PL system. Instead of Monday morning quarterbacking
>> after no-one stopped him when he asked about it, we should all help
>> him make the release - and the build change - successful now that he
>> has done most if not all of the migration work already.
>>
>> 	-hilmar
>>
>
> Here, here - well done Sendu on all your hard work!
> Personally, I think the move to Build.PL is a good one - it may be a
> little late in this particular release, but I think that the  
> problem is
> not that it is a late change, but that it wasn't picked up sooner. It
> fits well with the goal of making releases and big fix releases more
> regular, and if these are made available via CPAN, then the use of CVS
> is for developers and those wanting to live on the edge. Build.PL  
> helps
> all this by making is easier and quicker to make CPAN packages. It  
> also
> means we have a while before the "stable" 1.6 release to ensure it is
> working effectively - better than dropping it in on the 1.6 release
> isn't it? I think it's work the delay and an extra RC!
>
> Anyway, my 2 pence worth!
> Nath

I don't think anyone is knocking Sendu for his effort here.  I will  
remind everybody that this was discussed in a previous thread and a  
decision was made (and agreed to by Sendu) to wait until after this  
release to implement Build, hence the backlash.

Brian summed it up quite well.  We all support this; the timimg was  
just bad.  That's all.

Christopher Fields
Postdoctoral Researcher
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign