On Thu, Oct 01, 2009 at 10:14:23AM +0200, Michel Dänzer wrote: > On Thu, 2009-10-01 at 11:59 +1000, Dave Airlie wrote: > > So I feel locking down master is going to get messy fast, I agree > > all major developments should be done on branches, but we have many > > incremental improvements in areas like EXA where we have no fulltime > > developers working on it and the only real way for it to get tested > > across drivers is to shove it into master. Also having things in master > > means you get indirect cross testing, so if I want to add something new > > I end up having to test all the new stuff other people have merged. > > I share your concerns, though branches in the main repo might be a > little better than hiding stuff in personal repositories.
We can hook up commit notifications for personal repos, they're there in cgit, or even (god forbid) someone could actually publish some kind of status update on their personal repos. :P The only concern I have with putting them in the primary repo is that it's going to get very messy very fast, and you don't actually know the full status, because is it the input branch? Is it daniels-input? Is it daniels-input-hey-ignore-the-other-one-and-just-merge-this-one? Or was that from last week? It's reasonably easy inside personal repos -- and you have a lot more latitude to delete/modify/etc branches -- but I'm mildly terrified of the explosion that'd cause within the master repo. The idea is that we get broader testing for master, by being able to make regular snapshot releases, by being able to point users to it and having them able to build it consistently and reproducibly, as well as developers not being scared to run it. The point at which someone asked who was actually running master, and my hand was one of the very few in the room, was pretty troubling. A few people said 'I never touch master because it's always broken and difficult to build'. At the point where X developers are running away because the build's difficult and the code broken, we're doing something quite badly wrong IMO. > > \o/, I got the shit shot out of me for suggesting that last year, > > wonders whats changed. > > This took me by surprise as well - when/where/how was this decided? I > didn't have the impression that there was 'broad consensus' for this, > and I certainly can't say I like the idea. No-one in the room disagreed. I don't like the idea as we do it now -- as I said, it's predicated on getting a more sensible master. As it is now, nothing will be bisectable ever, because even if the core server works, will your input work at all? How about modesetting? Rendering? Doubt it. However, if we can go through a cycle or two where we actually have a broadly stable master, then we can think about adding drivers into the mix; definitely not before. Also we have to prove that we can do releases on time, and then the need for separate releases diminishes. There were a couple of different motivations for this, one was to make building things a great deal easier (jbarnes was pushing for it quite strongly and agd5f was in favour -- personally I'd expected the driver guys to disagree, but apparently even the ones who'd feel it the most don't). It's a bit of a shambles at the moment. The other was to finally fix the horrific abortion we call an API. Have you looked at a ScreenInit lately? We've no chance of fixing most of these unless we pull drivers into the core -- doing it incrementally is next to impossible, and the insane ifdef city will probably lead to driver authors just having a flag day anyway. What're your concerns? Cheers, Daniel
pgp3hDVKyNN8z.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel