Am 06.08.2004 um 08:45 schrieb Serge Stinckwich:
We already talk offline about the use of a BTS like Mantis with some of you. Can we try to make an experiment for example to manage the bugs in the stable 3.7 ? My vision is to have something like the way the linux kernel dev work : a very conservative stable version with a frozen API and only bug fixes, and an unstable version managed with the BFAV process.
Maybe, we can also have a maintainer for the stable version like Marcelo Tosatti is the Linux kernel 2.4 maintainer. We could have several stable release (3.7.1, 3.7.2, ...) at fixed time, for example every two or three months.
Yes, bugfixes for the stable version would be nice. I think we should try that. Of course, we would need somebody who steps forward as a maintainer.
But for mantis: I'd like to move all bugs over, even those from 3.8 and the old ones that are in BFAV.
Am 05.08.2004 um 21:44 schrieb Michael Rueger:
Back in the SqC days we had an internal and an external update stream. The internal one was pretty much unfiltered, living dangerous etc. EVeryone living on that stream was used to having backups of their image, ready to go back at any time. Then, when updates seemed ok for a while, they were transfered to the external stream. This way it was easy to retract updates, as they hadn't reached "everyone" yet, but only people who knew how to, and were actually willing to, roll back the changes.
Re-establishing that separation might help speeding up the harvesting process as it would spread the actual testing of an update across all internal stream users. Maybe naming these streams differently could help with acceptance ;-)
Yes, we should try that. This would work nicely together with HernĂ¡n's suggestion of non-checked submissions by "trusted" developers:
I agree with you about the danger of a faulty update, but... What about using this optimistic approach but restricted only to trusted developers. That is to Ned, Andreas, Tim and all the ones that in this list are considered as experts?
So taken together the new way for managing development would be:
- we have an unstable stream of updates - all "trusted" developers stuff will be added there, the changes will be made "official" after some testing. - bugfix releases of the stable version all 3 month - Managing of Bugs via mantis - BFAV process for community submissions (all trusted dev. are able to approve)
Oh btw, wouldn't Monticello help us if instead of submitting changesets we submitted mcz files? I mean for going back a version or two if something went wrong with an update.
Yes, we should move away from changesets and use Monticello.
Well, that were my two cents. Please treat me kindly. I am afraid of posting under this topic :)
No need to, realy!
marcus