> thanks for the update for automatic binding of loop devices Mark. Until now
> I've been using the stable tree (xen-2.0bk). I've just cloned the unstable
> tree, and would *like* to work with this if I can (better for you guys too
> in terms of bug reports maybe). May I ask how the stable and unstable trees
> are managed?
Right now the 2.0 tree is a time shifted copy of the unstable tree. We put
new changes into unstable and they get into 2.0 a bit later if they look OK.
After the 2.0 release, only bug fixes and the odd minor feature will get into
the 2.0 tree, whilst the unstable tree diverges with larger changes occurring
as part of the development of the next release.
> Do you commit everything to the unstable tree as you work, or
> do you only commit new code after some reasonable degree of testing?
> Historically, how often have things become badly broken in the unstable
> tree?
Thanks to the magic of bitkeeper, developers can stabilise their code in
private copies of the repository, then merge all the changes in later on,
when they think it's working OK.
During periods of very large, rapid changes (such as the new IO world a few
months ago) things sometimes got broken for a period but most of the time
things probably worked OK for the "average user" - indeed I know of at least
one person using unstable on his systems in preference to 1.2.
> I've been experiencing some unstability in the 2.0bk code, particularly
> when I use ReiserFS formatted LVM partitions with the 2.6 kernel. I have
> yet to get the serial console working (ttyS0) yet, so I have nothing for
> you as of yet, but I am working on that as time permits.
That's not something I'd expect to see problems with, unless you're seeing the
RAM-related problems with LVM mentioned recently on this list.
> Another thing I've been wondering is whether you have a more fine-grained
> to-do list somewhere, so I can make calls on whether to experiment with the
> unstable tree according to the seriousness of any unresolved issues.
Nope :-) I think most fine grained information of that sort will be in the
developer's heads! Unstable should always boot, should always (mostly) work
but there will be bugs - it's unstable ;-)
> I'm not a developer, but I am willing to submit bug reports, so in your
> opinion should I work with just the stable, or the unstable? What is most
> useful to you?
I guess right now if you find bugs in unstable we get reports sooner than if
you waited for them to arrive in 2.0... Even after release, we obviously
definitely want to hear about anything in 2.0 which doesn't look right!
Post-2.0, things will change more rapidly in unstable but I guess it's nice
to have someone sanity check the current state of things...
> Thanks as always for your time. I really appreciate the great feedback I've
> had from you guys.
No probs ;-)
HTH,
Mark
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home