On Wednesday 28 October 2009, Øyvind Harboe wrote: > I would like to see: > > - 0.3 out of the door. Shut down sf master for anything but > bugfixes as of friday 30. to wed 4.? Cut release nov 5.?
As of Friday 12:01 AM UTC? Making it Thursday 5:01 pm PST? Sure. In fact, tag it as 0.3.0-rc1 ? The "shut down" is maintainer discipline, obviously, nothing technical. But ... I'm not sure "bugfixes only" is 100% the right metric. That's the basic mindset, yes. But new drivers are examples of things that can safely merge pretty late, since they won't break any existing users and are at the worst partial bugfixes for the "hardware X won't work at all" bug. And there might be other examples. (I'm just pointing out that the line isn't quite that hard.) > - that we can agree that major features are developed in public > branches on repo.or.cz and then applied to sf when they > are as ready as they are going to be. Communication can be > via the mailing list and explicit posts. We don't need branches for everything; just large related groups of patches. And we don't need to store branches at that site, either. (Separate discussion to be had about branches and when they're wanted, but I just wanted to make those basic points.) > W.r.t. testing I believe that we have to push changes to sf master > before they are tested beyond the few developers working on > a particular feature branch. Yes. And that's true for minor "features" too. > How does that sound as a first tiny step towards improving our > process & getting 0.3 out of the door? I'm all for getting 0.3 out in a week. If Wookey can report that one patch of mine makes XSVF work for him, that'd be great and I'd want to merge that bugfix. But otherwise I don't know of anything that'd make me want to hold back from 0.3 going out tomorrow.... - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
