LXDE - Lightweight X Desktop Environment

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 <pcman.tw@...> 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!

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

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

-----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-----

-----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:          daniel.baumann@...
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-----

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

Even if i'm not really involved in LXDE, i'm totally for it.

Stephen Smally

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

-----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-----