-----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----- ------------------------------------------------------------------------------ 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 Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
