> Just another thought on this... although in an ideal world everyone > would test their code thoroughly before pushing it, we know that > doesn't always happen. I think we do need to distinguish at least two > levels of stability; the version that most external people use that's > been tested heavily (because most external people are using it), and > the "bleeding edge" of the repo where we're committing. Is there an > open source project that doesn't have "stable" and "development" > versions? We might as well set up this structure from day 1, IMO. BSD and linux don't work this way. There's only one real repository and people send patches upstream as they're tested. Mercurial doesn't work this way, there is a crew repository where people play with stuff, but the official repository is the stable repository.
I guess my feeling is that the main repo should be the stable repo. You shouldn't push unless you're confident in your changes. This seems to be the better model as the project gets larger and more spread out. People can maintain their own unstable repositories in separate groups that make sense. If we were all on the same sort of project, the way it was when we were all at UM, it would make more sense. > 1. Seems like there's no need for a separate repo; we could just have > a tag that's "latest stable" or something like that, and advance that > tag as needed (maybe leaving the rev tagged with some more specific > identifier like "stable of 2008-06-07"). Like what Nate did with > symlinks in the system dir on zizzer, basically. This would be > especially nice if the hg web interface that automagically generates > tarballs can take a tag in the URL (I'm assuming it does); that way we > can have a link for people w/o mercurial to just grab the latest > stable copy. I'd say that link should be the default download link. If we do it this way, I'm happy, though I do firmly believe that we need to raise the bar for committing. Now that we have tools like mercurial queues, there's really little excuse for committing things that aren't well tested. I have a years worth of changes separated into many separate patches in my tree and it's not awesome, but it's not terrible. I'd argue that the stable tag ought to move relatively quickly, and we should either have some automated rule about moving it (all regressions have passed including all long ones), or we should be very active in moving it forward. The only sorts of things that are going to be difficult in this model are very sweeping changes like my change to all instances of events being scheduled, but I can do that in a separate repository for the most part and by letting everyone know before the final merge that it's coming. > 2. When people point out bugs in the stable release that are fixed in > the tree and they don't want to upgrade to the bleeding edge, it will > still be easier to help them b/c instead of saying "search the mailing > list archive" we can say "look at changeset XXXXXXX", and they can > pull out just that changeset and apply it as a patch if they want. Sounds reasonable to me. We should look into the transplant extension. Hopefully people will use mq. > (And I can already foresee a FAQ entry on just how to do that.) If > they're smart they'll use mq to do that so they can kill the patch > once they upgrade to a later rev via the repo. Or if they're not > using hg at all, then that's their problem. Heh. agreed. _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
