[Server-devel] XSCE | Proposing a quick turnaround 0.4.5 release

[Anish Mangal]

On Mon, Oct 7, 2013 at 9:51 PM, James Cameron <quozl at laptop.org> wrote:
> Don't number it 0.4.5, instead number it 0.5, and push any plans you
> had for 0.5 out to 0.6.  The sooner you get to 1.0 the more acceptable
> the version number will become.  0.4, based on the descriptions I see,
> is already 1.0 fodder.
>

I am okay with whatever version numbering scheme that is acceptable to
the majority.

> Ansible sounds fine, but you haven't said what it is for; no apparent
> benefit to the end user.  If it is an internal reorganisation for
> developers, won't you need to find which developers are in favour, and
> will the publication of a feature page expose those developers or not?
> If it is for a web user interface for end-users, are there others you
> might use instead, such as Webmin?  What process led to the
> recommendation to use Ansible?  Which developers will find it hard to
> migrate their neural maps to Ansible?
>

=Short answer=

http://lists.laptop.org/pipermail/server-devel/2013-September/006755.html

=Longer answer=

Perhaps it is best given by Miguel or Santi. (cc'ed)

It is an internal reorganization for developers, with no impact for
the end user (the end user being a teacher or a student). It is meant
to make the XS platform easier to:

* Add features to as a platform
* Deploy at small and large scale, online or offline
* Make the XSCE cross platform
* Make the XSCE more approachable to a potential developer. One of the
great things about Sugar is that it is written in python, which is so
much easier to learn and get started with. I hope ansible has the same
effect.

This is not the first time Ansible has been discussed in the context
of XSCE. Here are some previous discussions
* http://lists.laptop.org/pipermail/server-devel/2013-September/006767.html

* From another email in the non-archived xsce list:
"About ansible, it a powerful tool, with lower learning curve than
puppet, and can achieve almost the same results imho."

In terms of experience with ansible, we have so far:
* Updated the XSCE software offline thru ansible in Bhagmalpur once,
went flawlessly.
* Based Dextrose Server on ansible. Code: https://github.com/activitycentral/dxs

Still, you are probably going to get better answers to specific
technical queries from Santi or Miguel. The feature page linked in my
email before is still an early draft.

> I don't see any sign of failure to scale with the existing developers,
> so I'm surprised you would want to go all formal with feature pages
> and an approval based development process.  The community you have now
> is still young, and probably hasn't even finished settling in to the
> processes you already have.
>

Incidentally the idea behind a feature page is to answer exactly the
kind of questions you asked about ansible your email :-)

The other reason I proposed it was that we seem to have accumulated a
lot of great ideas that can go into 0.5 (or 0.6), and we need to start
moving from fuzzyness to form so a decision about working on them can
be made.

http://producingoss.com/en/producingoss.html#bikeshed

I am okay with any process that accomplishes the same. In the last two
IRC meetings, we have thrown about many ideas, but I would want more
resolution when discussing them :)

For a bit of background, the 0.2 featureset was decided in the toronto
sprint where ideas were written on post-it notes, pasted on a piece of
paper and discussed by everyone present.

http://www.flickr.com/photos/tiayiti/8475348302/sizes/c/in/photostream/

About some of the other ideas, like posting notifications to mailing
lists, I believe it is not a "process change", but simply an effort to
make things more transparent.

- - - - -

In sum, all these are just ideas to make XSCE a more fun place. I
would love to see them refined/adopted/rejected after due discussion.
:-)

> --
> James Cameron
> http://quozl.linux.org.au/