Changes between Version 17 and Version 18 of GitObjections

09/21/09 16:32:18 (5 years ago)

Feel free to format my comments to fit the style of the page.


  • GitObjections

    v17 v18  
    1818   * Answer 4.3: Git supports a workflow very much like the existing SVN workflow.  It's not the ideal Git workflow, but it's similar enough that retraining will be short.  (See also [wiki:GitCookbook-Pm].) 
    1919   * Question 4.4: How many existing active committers ~~and developers~~ might need retraining?  I suspect the number is small. 
     20       * Committers requesting training if we proceed: ... 
     21       * Committers offering to conduct training: ... 
    21235. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers) 
    2931   * Claim 6.1: Ensure that those projects are given sufficient advance notice of any VCS switch.  This includes HLLs and derivative projects such as mod_parrot.  A list of such projects should be maintained. 
    3032     * Counter-claim 6.1.1: According to Parrot policies, HLLs and other projects should not be dependent on the VCS but should restrict their work to released versions of Parrot.  Projects that choose to have a dependency on the master Parrot VCS do so at their own risk. 
     34As an HLL author, I can't track parrot releases exclusively by release. However, even when I do, I do not track it via svn, but by requiring the user to get their own copy and install it (So my issue is #7, below) --coke 
    3136   * Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch. 
    33387. Objection: HLL's that want to be able to say that they require a certain minimum version/revision of Parrot will have a harder time, since git commit SHA1's are not "linear." 
    3439   * Answer 7.1 : HLL's should be tied to a released version of Parrot. 
     41This may be reasonable for HLL '''releases''', but not for HLL '''development'''. That said, a harder time figuring out which versions are OK is fine, as long as it's not impossible. I can even remove the programmatic check and simply warn the user. If we do develop a programmatic solution, this cost can be shared among those HLL implementors that need it. --coke