From: PCMan <pcm...@gm...> - 2012-05-21 02:10:53
|
Hello, As the LXDE components are deliberately kept independent of each other so they can be used easily outside LXDE, we previously use a "rolling stone" release model. Each component gets updated independently. This works great initially. However, as the project grows, some components more or less became more integrated with others. In addition, owing to the rolling stone model, components are updated randomly. It may be more difficult for distribution makers and users to track all of the changes. When a release will be available is always unknown and unexpected. It's not possible to fix all the bugs all the time. So when is a component good enough and ready for a release? Having a regular release cycle and fixing as many bugs as we can before the release date might be a better approach. I'd like to propose a regular release cycle synchronized with the release cycle of major distros. Set a release date, fix as many bugs as we can, and then do the release as scheduled if there are no major blockers. Any comments or objection on this? Thank you! |
From: Mario B. <mb...@ma...> - 2012-05-21 02:29:59
|
Hi, this is an excellent idea. What release cycle do you have in mind? It could help us to improve and speed up development and fit together with an idea Christoph came up with last time I met him - the organization of code sprints or bug sprints over a weekend with people already contributing. We could try to bring a group of a few contributors together who work for a weekend on solving issues and getting ready for the next release. It is a lot of fun to work together in one spot and enjoy each others company some time. These sprints could be easily organized regionally and as the groups are small, it is not very difficult to set up. In Europe for example we have some known contributors e.g. in France, Germany and Sweden, who could meet easily in some spots. I would be happy to help. Decentral sprints are possible too. At the moment I am playing around with some people with lxlauncher in Vietnam and we hope to be able to contribute soon. There were also some former contributors in Singapore, who might be interested. We can discuss about other regions in a separate thread as well. So, I think your idea can really give a push to the project and I am looking forward to the time you implement it. All the best, Mario On Mon, May 21, 2012 at 9:10 AM, PCMan <pcm...@gm...> wrote: > Hello, > As the LXDE components are deliberately kept independent of each other > so they can be used easily outside LXDE, we previously use a > "rolling stone" release model. Each component gets updated independently. > This works great initially. However, as the project grows, some > components more or less became more integrated with others. > In addition, owing to the rolling stone model, components are updated > randomly. > It may be more difficult for distribution makers and users to track all of > the changes. > When a release will be available is always unknown and unexpected. > It's not possible to fix all the bugs all the time. So when is a component > good enough and ready for a release? > Having a regular release cycle and fixing as many bugs as we can before the > release date might be a better approach. > I'd like to propose a regular release cycle synchronized with the release > cycle of major distros. > Set a release date, fix as many bugs as we can, and then do the release as > scheduled if there are no major blockers. > Any comments or objection on this? > > Thank you! |
From: Alexis L. Z. <azu...@es...> - 2012-05-21 02:34:31
|
Hello: I guess that having a regular release cycle will be helpful for those that use LXDE. But this means that we will have to coordinate better our work, and define in each cycle what is going to be done. Also the user will expect more from us and we will have to follow an schedule. I'm had no problem with it, but what about the rest of the LXDE developers ? Cheers. Alexis López Zubieta Nova Light Project University of Informatic Sciences 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci |
From: PCMan <pcm...@gm...> - 2012-05-21 05:08:59
|
For a new release, it's not necessarily to have great changes everytime. Actually, dramatic changes like KDE3 -> 4 or Gnome 2 -> 3 is not that welcomed. We just need a clear schedule to make the existing improvement available to the users periodically. A new release without much UI changes is less exciting, but improvement in quality deserves a new release as well. In our current release model, nothing can be expected since nobody knows when will there be a release. Coordination won't be too big a problem since most of the core components do not rely on each other. But we really need a "schedule" to define what should be done and when should they be done. If we cannot do all of them before the deadline, we can discuss about whether we should drop some of the items, or delay the release. Either way, things are done in a well-defined manner and changes happen in an expected way. Some friends in our community already suggested a regular release cycle in the past, but we did not do it. Maybe it's time for a change to a better release model. It's not possible to fix all of the bugs and it's unknown how much time will be needed to fix them all. We, however, still need to have a timetable about when to make a release when things are good enough. A 6-month release cycle synchronized with Gnome and major distros IMO is acceptable. We may not have exciting new features everytime, but at least the fixes and small enhancement done by the contributors should be available for the users. Packagers no longer need to package git head code. So, I think changing the release model helps. Thanks On Mon, May 21, 2012 at 10:34 AM, Alexis López Zubieta < azu...@es...> wrote: > Hello: > I guess that having a regular release cycle will be helpful for those > that use LXDE. But this means that we will have to coordinate better our > work, and define in each cycle what is going to be done. Also the user > will expect more from us and we will have to follow an schedule. I'm had > no problem with it, but what about the rest of the LXDE developers ? > > Cheers. > > Alexis López Zubieta > Nova Light Project > University of Informatic Sciences > > > 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS > INFORMATICAS... > CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION > > http://www.uci.cu > http://www.facebook.com/universidad.uci > http://www.flickr.com/photos/universidad_uci > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Martin B. / b. <br...@bs...> - 2012-05-24 09:52:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-05-21 07:08, PCMan wrote: > We just need a clear schedule to make the existing improvement > available to the users periodically. Yes. > In our current release model, nothing can be expected since nobody > knows when will there be a release. This depends on the above one. > But we really need a "schedule" to define what should be done and > when should they be done. Absolutley. > It's not possible to fix all of the bugs and it's unknown how much > time will be needed to fix them all. Make a prioritized list and mix "fun" with "boring". Complete the top most task first and then move on down the list. Skip the time estimates and all that time schedule things, that will lead to stress and overhead. Reprioritize the list on a firm interval (once per month? every two weeks? something like that) to catch newly surfaced bugs. > We, however, still need to have a timetable about when to make a > release when things are good enough. No. > Packagers no longer need to package git head code. And they should never do that either. It has lead to pain before and will probably do that again in the future because somebody doesn't understand better. I am happy to support minor releases just to get minor docs or l10n updates out there. Hs this really been a problem? > So, I think changing the release model helps. I think you are trying to solve the wrong problem in many was. People should focus on doing great software and clearing out the patch tracker, thinking about elaborate release processes will not gain more releases. Probably the opposite given the small team we have at hand. More code. More releases. Better code. Better releases. More contribution. - -- brother http://sis.bthstudent.se -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPvgTJAAoJEJbdSEaj0jV7wQYH/3mk5Y+lZWhp26hAYsbRWFRQ +IX/mCxd+FOB8bzgynGnZAZFcmZTzugV7xu9hHOFcjuhgt7TiCvBUOKyPaO53gbN HDY+g7Bi7XvP5IPfwhjJBgCdcnRfcp+MbkgVqsECiLJwdled9bAljuPYFwMV/b2W zxin/V5td/ZjLKAzo0mPxANQ1sOh/+fYqLrZiHmAN3XzVxrPnyTU3ZRnIuW09AOI wfetPyqu13VJbSyX+rVvxKux1g9GIMUSVp6Uts12s56F9cDQT4ZeUy9LStIdupc2 AAp5+2eYkKWEDP0WbEri/Fdp/aGsOA0LVPfAw7OmP86qbyKGqcvmCXd+MQSgyy4= =h81f -----END PGP SIGNATURE----- |
From: Martin B. / b. <br...@bs...> - 2012-05-21 06:02:57
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 21 May 2012, PCMan wrote: > In addition, owing to the rolling stone model, components are updated > randomly. > It may be more difficult for distribution makers and users to track all of > the changes. Well - is it? Andrea? Andrew? Daniel? Christoph? Julien? Whoelse? It's about tracking the git repos and discovering the new tags (or staying close to the community, or at least reading the blog. > It's not possible to fix all the bugs all the time. So when is a component > good enough and ready for a release? Release early, release often. The latest commit in master should always be releasable. Use branches for experiment and special things. > Having a regular release cycle and fixing as many bugs as we can before the > release date might be a better approach. But we don't have the manpower so this is just a dream and a burden on the project. > I'd like to propose a regular release cycle synchronized with the release > cycle of major distros. > Set a release date, fix as many bugs as we can, and then do the release as > scheduled if there are no major blockers. > Any comments or objection on this? I don't think this will be the winning strategy. Better release planning will but dates and promises to people will not. As much as I hate the SF.net tracker we have lots and lots of issues posted there. I hope distribution people will forward things to our tracker when they get reported in their respective tracker. These things serve as a release planning foundation. Make a prioritised list of things in the tracker and begin working from the top most important thing. Decide that when the first 10 or 15 or X tracker items are done there will be a release. Intermittent releases may still happen but you promise to make a release when things are DONE. No dates, no promises but clarity in what is planned for the component. This comes to manpower, who want to take the hat to always read and poke reporters about updates to the tracker items to make them into workable items? Not necessarily the same person who does the prioritisation of the items but most likely. If we had at least one dedicated developer per "component bundle" (pcmanfm+libfm need each other) this work would probably be easy to spot but given the situation where each component is more or less in the hands of one person, the same person for all of them, this release planning is going to be the only thing that person can do. And I don't think we want you to drop development and start doing bureaucracy. My wish. Use the wiki (and/or the blog) to tell people about your plans for the components. Try to base that work on the tracker items that are submitted. Use public branches to do the work, don't hide it in your own computer for weeks and then surpirse everyone with a super change to the master branch. The releases will still be sporadic and on a need to happen basis and the main developer can be in charge on when there MUST be a release and I (or maybe somone else) can do the intermittent releases when we see fit. Like the last weeks where Daniel and Andrew have reworked the Debian packages warranting new releases for some components. Release early. Release often. Release when done. Be open about plans. Don't hide code. - -- /brother http://martin.bagge.nu Bruce Schneier reads RFID cards with the knuckles of his clenched fist. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJPudTJAAoJEJbdSEaj0jV7NFkH/R8tExZ4TMGGetKVJT8nnEWP Eacyt4dFe3VvJLlzzjJ9KCZ0N9/pOnhM8r4LUeoKmrTLC/57wdsfhKizynf73Y6c 7ysmv1G9ubvsxVw9uShAhx1qXAcZDLl4e9RBioGDjzBJEI3sDDi9xejbR7kgrwHo eJ+nDbd7wQzm9rkX7CrtpnKH4oIEILwvBYaO8BeFEtTPS8Fp6XMmHqnSnaErSWri JW0SteS0h9QapEGloBHd9DaP1blXxBN+3jiTycJsAyXkgpscco1lesdQkfGUAv3f sFh3Kpg+d2YRjSOWpS7lUHbRQgY13QGT7DBnjL+wt26P5EDVcXI6gKQk0W7XGHY= =0tkF -----END PGP SIGNATURE----- |
From: Daniel B. <dan...@pr...> - 2012-05-21 09:24:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/21/2012 07:38 AM, Martin Bagge / brother wrote: >> It may be more difficult for distribution makers and users to >> track all of the changes. > > Well - is it? doesn't matter for me. > It's about tracking the git repos and discovering the new tags (or > staying close to the community, or at least reading the blog. exactely. > Release early, release often. The latest commit in master should > always be releasable. Use branches for experiment and special > things. yes, that's much more important to release 'often' than to release at a 'predictable' schedule. > As much as I hate the SF.net tracker we have lots and lots of > issues posted there. looking through the the reported issues, some for trivial things like typos and stuff.. even with patches attached for that.. they do not get applied and are just rotting.. that's demotivating and sad (which kind of also kills my mood of submitting patches from debian too, guessing that they never be applied anyway and the going though the hassle of sf tracker will be in vain). before thinking big and overengineering a release schedules and such, i'd prefere to to see actual issues getting fixed and patches applied. > Release early. Release often. Release when done. Be open about > plans. Don't hide code. amen. :) - -- Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: dan...@pr... Internet: http://people.progress-technologies.net/~daniel.baumann/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+6Cb4ACgkQ+C5cwEsrK57bpQCfXh3l9bC5uicgaijLiroHYt6h M/QAnAlihCUYGs5Vvawa4Ro2/nCi2ik8 =5C69 -----END PGP SIGNATURE----- |
From: Stephen S. <eco...@fa...> - 2012-05-21 12:50:00
|
On 05/21/2012 04:10 AM, PCMan wrote: > Hello, > As the LXDE components are deliberately kept independent of each other > so they can be used easily outside LXDE, we previously use a > "rolling stone" release model. Each component gets updated independently. > This works great initially. However, as the project grows, some > components more or less became more integrated with others. > In addition, owing to the rolling stone model, components are updated > randomly. > It may be more difficult for distribution makers and users to track > all of the changes. > When a release will be available is always unknown and unexpected. > It's not possible to fix all the bugs all the time. So when is a > component good enough and ready for a release? > Having a regular release cycle and fixing as many bugs as we can > before the release date might be a better approach. > I'd like to propose a regular release cycle synchronized with the > release cycle of major distros. > Set a release date, fix as many bugs as we can, and then do the > release as scheduled if there are no major blockers. > Any comments or objection on this? > > Thank you! > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list Even if i'm not really involved in LXDE, i'm totally for it. Stephen Smally |
From: Julien L. <gi...@ub...> - 2012-05-22 18:39:11
|
Le 05/21/2012 04:10 AM, PCMan a écrit : > Hello, > As the LXDE components are deliberately kept independent of each other > so they can be used easily outside LXDE, we previously use a > "rolling stone" release model. Each component gets updated independently. > This works great initially. However, as the project grows, some > components more or less became more integrated with others. > In addition, owing to the rolling stone model, components are updated > randomly. > It may be more difficult for distribution makers and users to track > all of the changes. > When a release will be available is always unknown and unexpected. > It's not possible to fix all the bugs all the time. So when is a > component good enough and ready for a release? > Having a regular release cycle and fixing as many bugs as we can > before the release date might be a better approach. > I'd like to propose a regular release cycle synchronized with the > release cycle of major distros. > Set a release date, fix as many bugs as we can, and then do the > release as scheduled if there are no major blockers. > Any comments or objection on this? > > Thank you! If I'm right, we tried it in the past, and the result was no release at all during a very long time. Considering that some components are not touched during a long time, IMO no need to force a release every 6 months in this case. Personally, I'm quite happy with the current way, doing regular releases for components when there are ready. We are sure now to have stables releases, which is for a distribution, essential. Regards, Julien Lavergne |