On Tue, Sep 21, 2010 at 11:37:33AM +0200, Jens Rehsack wrote: > Hi all, Hi Jens. [FYI Your email crossed with my "1.615 and onwards" one.]
> I'm a bit confused about the immediate requirement of a fix for RT#61445 > and not even a development release 2 days after the fix has been committed, > but I think this is just a result from the current confusion. At the time I thought RT#61445 was likely to cause many failure reports on OS X. That's not happened because none of the cpantesters, so far, are using "~/Library/Application Support/.cpan" as their build path. And perhaps the "whitespace characters in the current directory path" warning that Makefile.PL issues is helping those who build manually. > I decided for myself, that I don't commit to the DBI before we have an > agreement how to develop and how to communicate about releases. I don't > plan to immolate my weekend with the family more often. Background: I'm > on the road over the week for a project and see my family only at weekend. > So releases at Friday or Saturday can be poison for my weekend. Family comes first. Everything we do here is insigificant in comparison. Please not let this work spoil family time, ever. It's never worth it. > Tim suggest that Pure-Perl DBD development can happen in branches and > they should be merged into the trunk when they are ready. Well, I had > merged the state of r14409, because I rated it ready, but I hadn't merge a > day before a final release. I'm not sure what you're saying here, but let's not worry about the past. > On the other hand, are the git users able to use the svn branches? I don't know how updates work with git svn, but a fresh git svn clone will work (though it would wipe out any local changes). > Is it a suitable way to step further? I thought you were a keen svn user and not at all keen to use git. (Though on reflection I suspect your previous problems with git were due to working on the trunk rather than always working on personal/feature branches. With git you "branch early, branch often" and generally avoid committing individual to the trunk.) > For releases, I suggest a reasonable person (probably Tim) announces a > freeze date (around a week before the freeze starts), from this date on no > unreviewed commits to the DBI trunk are allowed. A freeze should take at > least one week, longer if required. Further development can happen in > branches which are merged back to the trunk after Tim unlocks the branch. > > If we use branches, we shall agree how to compute the branch names: > I suggest: branches/$(origin)-$(reason), e.g. > branches/trunk-DBD_DBM_Create_Table_Fixes > when branched from trunk or branches/DBI_1_614-Fix_whitespace_in_path_error > when branched from a tag. > > Does it sound as a way we can agree? I don't mind how the SqlEngine team chooses to organize it's own branches. But I'd like to only have to work with one primary branch, eg sqlengine, for integration into the trunk. > If those branches aren't a good way, svn supports externals (see > http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html). The Pre-Perl > DBD's can reside in an own repository and are bundled as released. I'm not keen on that because it would complicate the directory structure to arrange for all those files to live in one dir tree. Let's keep it simple for now and try using just one branch. Tim.
