2010/9/21 Tim Bunce <tim.bu...@pobox.com>: > 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.
Two souls, alas, are housed within my breast and each will wrestle for the mastery there And providing high quality OSS (cpan) modules is one of them. I made the bummer, I had to correct it. And with a look to Septermber, 23th, I wanted it fast, too. That's why the personal decision: Need rule to protect my weekends (and of course to blame the others ^^) >> 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. I try to say: even if I had branched, I would have merged, too. I meant to say: I strongly need a responsible person who would take that merge tasks (and probably hears when I cry out: "This must be included into the release"). >> 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). Yes, but switching will be difficult... sorry guys. >> 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.) No, my problems are, that git find conflicts during merge tries where it should fast forward. I need Merijn for some hours to dig deeper, currently I can only guess ... Branching wouldn't help me out, except I always throw away the old branch and start a new one after Merijn pushed the commit of my changes. But doesn't lead those way of working an scm ad absurdum? >> 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. I think, when we (I) tell you the branch to merge, it should be ok, shouldn't it? >> 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. I just was a bit thinking around (loud). Jens
