On Tue, 2009-11-24 at 13:06 +0000, Mirco Müller wrote: > > > Not so fast folks... notify-osd trunk is behind notify-osd/karmic > at > > > the moment. > > > > This makes it very hard to figure out where to do work. I presume > there > > is a good reason for this. Can we figure out how to avoid that in > > future? > > Isn't this the normal procedure? Do feature work in trunk during > Alpha-period. Once Beta-period starts branch off for bug-fix-only to > mature the code-base. After final release merge fixes back to trunk. > > That merge back has not happened yet, because jumping on Lucid for > helping to work on unity became highest/only priority.
There are multiple ways of doing this. If you branch for karmic and stop changing trunk, its identical to just being careful about what you put on trunk. The thing to avoid is adding a buffer for contributions to trunk while doing stuff for karmic - and branches are great for that. I got confused by the comment that *this patch* can't land on trunk because of something happening elsewhere. > Even now I don't have explicit "green light" for the merge-back yet. > But this is meant to come during the week, once I've send David my > fixes-list for the notify-osd Karmic-SRU. In bzr there is a 'free merge' policy for merges from release branches to trunk. So generally they are Just Done immediately - we want trunk to always have the latest and greatest code. Would something like that work here? If not why not - what are we achieving by having an approval process for incorporating already reviewed changes from a previous release. > > It also implies that the karmic changes didn't get code reviewed, if > > reviews are happening only on trunk. > > No. From the branch off for Karmic code-reviews happened on the > karmic-branch of notify-osd. So far nobody complained about the way we > go about our code-review targets. Well, I also did TDD on notify-osd > as good as I could, once it was demanded, which was - according to > your remarks from the Montreal-sprint - not reasonable to do as an > afterthought. Excellent! > It looks like there are still differences in the applied "best > practices". I'm eager to learn about a better approach, but so far > didn't feel I was doing something wrong. You're not doing anything wrong; I'm just encountering your process here with fresh eyes, which will sometimes find things we can make better, and sometimes just things I didn't know ;). > > > What's test-support.am doing exactly? In particular how does Xvfb > work > > > and what are all those XIDs good for? > > > > Its just machinery to get an X server up and running without linear > > probing for available server slots. > > Is that something I can easily test locally on my box here?... As Ted says, ssh in, or hit ctrl-F1 and log in from console. We still need to get the withlib tests to exercise an isolated notification daemon, but the tests that directly render stuff render on xvfb quite happily AFAICT. -Rob -- https://code.launchpad.net/~lifeless/notify-osd/tests/+merge/15182 Your team ayatana-commits is subscribed to branch lp:notify-osd. _______________________________________________ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
