bear wrote: > Heikki Toivonen wrote: >> bear wrote: >>> Heikki Toivonen wrote: >>>> We haven't been able to provide a satisfactory answer to this problem >>>> since we split into external/, internal/ and chandler/, so I am not so >>>> sure it would be a simple fix. >>> The reason it breaks now is because the external process does an install >>> step that puts the generated tarball into the Chandler's download >>> directory. What I am imagining is that the external build place the >>> tarballs into a directory named something like external_downloads and >>> runs all of the Chandler tests pointing CHANDLERARCHIVES at that >>> directory. This will test the new tarball. >>> >>> When the next step (the new one that also would run Functional Tests) >>> runs, it would remove the CHANDLERARCHIVES def and that would pull then >>> from the stable downloads directory. >> >> I don't see how this would help. Any chandler/ tests run with >> external_downloads/ would risk failure if there was an API change. This >> is what we used to have when we originally moved to the externa/ vs >> chandler/ build system, but changed to current system after complaints. >> >> Pulling anything from the stable downloads directory means that the new >> code in external is not tested. > > Gah! now I remember why I hated trying to solve this problem :)
Heh. But having pondered this still some more, could we live with our current way of doing full build? In other words, you check in a change to external/, the change won't be tested until you make the corresponding change to chandler/. We need to ensure we don't make any releases or checkpoints or the like in this state, but otherwise I think it is reasonably well understood by our developers. For example, we don't mark bugs fixed until we checkin to chandler/ dir. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
