coordinating on pdd30 branch

[Allison Randal]

The fundamental point here, and it applies to every single change: you 
need to develop your changes as separate patches. Each patch needs to be 
able to apply cleanly to trunk without depending on any other patches.

We give a lot of grace to new developers. I created a development branch 
to make it easier to recover from your first set of overly dependent 
patches. I've extracted most of the value from that original set of 
patches and applied it to trunk. But, that's not a sustainable 
development model. I spent twice or three times as long extracting those 
changes from the branch as you spent making them in the first place. We 
need to take your skills to the next level.

Reini Urban wrote:
> 
>> - I left out src/library.c because "this still crashes" means it doesn't
>> get merged into trunk. More info about how and why it crashes would be 
>> helpful. When you develop the separate patch for this, eliminate the 
>> ENABLE_PARROT_LIBRARY_INSTALLED ifdef's, and just develop the patch 
>> straight. Several files depend on the src/library.c changes, so also 
>> remain unmerged (tools/dev/install_files.pl, 
>> config/gen/config_pm/config_lib.in, runtime/parrot/library/config.pir, 
>> runtime/parrot/library/parrotlib.pir).
> 
> Please check out the recent fixes for src/library.c because I fixed "the 
> crashes". Every change has a corresponding ticket and testcase.
> 
> And all these config and library patches you left out are critical.
> How should people work outside the builddir? How should packages be 
> made? Should it be the same as vanilla and strawberry perl forcing 
> packages to be installed into a fixed location?

Please create a single patch for the most up-to-date revision of 
src/library.c and the files that depend on it. If you need guidance 
creating the patch, I'm happy to help, and I imagine others in the group 
are too.

>> - Moving a bunch of files from languages/WMLScript/runtime to 
>> languages/WMLScript/WMLScript seems odd. The 'runtime' directory was a 
>> more meaningful name. But mainly, the move isn't related to the 
>> install process, so should be taken to the language maintainer 
>> (François Perrad) rather than included in a branch with 
>> install-related changes.
> 
> But this apporach works. Currently it doesn't work.
> I wrote up pdds/draft/pdd30_install.pod and gave several variants to be 
> decided upon, but apparently nobody read it.

I did read it, but you're right I didn't make the connection between 
that proposal and this directory rename.

So, to address the draft PDD: rejecting directories named like 
'languages/WMLScript/WMLScript' to store language libraries.

>> - Please submit the MANIFEST.generated changes as a separate patch. 
>> (One important skill about submitting patch files to Trac, they should 
>> always apply cleanly to trunk and not depend on other patch files 
>> submitted in other tickets. It can be a tricky skill to master, but 
>> once you've got it, your patches will be accepted far more frequently 
>> and rapidly.)
> 
> Chicken - Hen: With such big changes I can either split it up 
> individually to have corresponding tickets and for easier review,
> or - the conflict - pack into one big patch which applies cleanly and in 
> parallel to trunk. Nobody wanted the big patch approach, so I read the 
> above paragraph as lame and meaningless.
> Since the important patches were not applied in July, I had to split up.
> 
> It's not tricky for me to have many small patches because I have to 
> tools to work with them, quilt. But since I'm the only one using it, its 
> tricky for you getting the dependencies right.

Enormous patches with many unrelated changes are bad, and are pretty 
much guaranteed to never be applied.

A large set of patches that all depend on each other (also with many 
unrelated changes) are also bad, and are also pretty much guaranteed to 
never be applied.

Small patches (with nothing but changes important to one particular 
feature) are good, and are very likely to be applied. Simple patches are 
often applied with no changes, but more complex patches that touch on 
core systems may be applied with changes to make them fit better with 
the overall design or architecture of Parrot.


>> That wraps up pdd30install_stage3. I'm ready to delete the branch when 
>> you confirm that you've extracted any outstanding patch files from it.
> 
> I vote against it. There are a couple of important patches still in,
> Leaving the language to the language developers, will not gain anything.
> This is at least a start for the poor languages, so that they can live 
> alone.

So, extract the patches. Again, if you need guidance, we're happy to help.

I'm still working my way through the list of individual tickets you 
posted on the wiki page, and am adding comments to each one as I go.

Allison