Re: [opensuse-factory] OpenSUSE, bugs and some considerations
Il giorno sab, 03/03/2007 alle 13.05 -0600, Rajko M. ha scritto:
Well, both is an extension, just one is fine for fast responses, and the other allows more asynchronous work that will group more people that might be not familiar with bugzilla and/or IRC, can't attend at the times that are scheduled, but still can help. Sorting out to one medium will do just opposite from what is wanted.
Yes and no. The goal is to work together on specific, serious problems. So doing asynchronous work seems pointless to me.
I can use IRC in the most basic form. That and time constrains will prevent me from attending antibug fest.
This is sad. Would a forum be better?
What is the best can be decided on the run. I don't see the need to insist on one communication channel that fits for some purposes, and not for the other.
In my opinion with multiple communication channels we risk to have a lot of duplicates and a significant loss in time/efficiency. For example different groups working on the same problem on IRC, on ML, by mail... Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Alberto Passalacqua wrote:
In my opinion with multiple communication channels we risk to have a lot of duplicates and a significant loss in time/efficiency. For example different groups working on the same problem on IRC, on ML, by mail...
no. we should have only one channel for bug assignation, then the group that work on it can use any medium he wants :-) it's not always posible to use for bugtest the very machine we communicate with or an other machine nearby. in most case I have to disconnect, boot the given version, test, reboot and reconnect... and don't you think we should begin with the olders bugs, that is 10.1 ones? I see the things like this: * take a bug * read the logs * If the bug is old, but was studied, write a note on it to ask the owners if they still intend to work on it (if not, close it as fixed or wontfix) * for remaining bugs write on the wiki a summary showing mostly what HW/SW configuration it needs. this anybody can do. then if you have the necessary HW and with the last distro version (10.3) try to reproduce the bug. If you can, go on and try to fix, if you can't, log this and close the bug... In my opinion _no old bug should stay open_ if they are not worked on for fixing. and we know this will only happen for security ones. please edit and enhance this todo list :-) jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello all, I read the last 89 entries at one sitting and I have formulated an opinion that I have sort of posted b4. I think a radicle change to release theory should be entertained. I think that since 10.2 was a December release we had the opportunity to change to an annual release cycle. With this change we could . have both repository and bugzilla quarterly change cycle. I.E. January: 10.3 ao: would be a new repository with 10.2 code and it's goal would be just to include bugfixes found in the first three months of 10.2.. nothing else, using this repo as a repair location for things like the current ZMD issue, this could be an "edge" update channel with scripts\rpm's to effect repairs. sort of an annual remastering. April: 10.3 a1: move code with bugfixes in the first quarter and include program updates that have been voted on as stabilized in the build service during the the first half of year July: 10.3 b0: move code with bugfixes from second quarter\first half. as well as mods to first half program updates as stabilized by the buildservice. Announce all testing requirements and start all testing. September: 10.3 b1: move code w\updates begin code freezing processes. December: 10.3 final: Move frozen code to release repo. This would stabilize peoples expectations as to when they will need to start testing and give a full 5 months to stabilize(release could be 12\20 every year! Happy Holiday ) This would as a minor side effect slow down the adoption of "cutting edge" packages and technologies but also give the whole linux community time to create stability in those packages before OpenSUSE uses them officially. Consider that the buildservice would handle most of the testing and stabilizing work on the cutting edge, not the factory. i.e. kde4\gnome 2.x Most importantly any update service changes could be Add-ons! I think it is important to state that the Buildservice is an entity of it's own, with the responsibility of generating packages suitable for the main distro, therefor having the main distro slow down isn't a bad thing. The main distro factory should only concern itself with functionality updates and YAST expansion. i.e. printer discovery and more Yast modules like one for building a proxy server and adding a filtering service or expanding the choices in the DHCP config module. The BS should be the place where all community and cutting edge work gets done in a download it at your own risk "add-on" fashion, taking the risk out of using the main distro. This would likely reduce the cost of including the 18 months of security patches to OpenSuSE and 5 years support to SLED by minimizing the base distro changes. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
James Tremblay wrote:
change to an annual release cycle.
notice that Mandriva went back to a 6month release cycle... jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Il giorno lun, 05/03/2007 alle 10.51 -0500, James Tremblay ha scritto:
Hello all, I read the last 89 entries at one sitting and I have formulated an opinion that I have sort of posted b4.
I think a radicle change to release theory should be entertained. I think that since 10.2 was a December release we had the opportunity to change to an annual release cycle.
I think an annual release cycle is too long. Linux and related applications change fast and a long release cycle risks to make users unhappy. If the release cycle is made longer, the release of updated applications through an official channel (not additional repositories or OBS) becomes necessary. If not done, we risk to have an obsolete distribution soon. In my opinion, if we want a stable distribution, the use of the build service or of additional repository should be considered an occasional event for the common user, to get only what is not / can't be provided in the distribution. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Alberto Passalacqua -
James Tremblay -
jdd