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
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,
On Mon, May 21, 2012 at 9:10 AM, PCMan <pcman.tw@...> wrote:
> 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
> 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!