I think this is the proper time to convince Adobe and graphic leaders to target !

Ubuntu would be a better professional friendly environment and more independent
Thank you

Of course, the benefits of short cycles is that you see things work (or not work, so you can correct them). I have always been in favor of 15 minute (max) codking cycles, but I would not recommend a 15 minute release cycle.

So, what is the process that is in play driving long vs. short?

Big change == big unknowns;
Small change == predictable (stable) results;

How (naturally) do those two interact?

You will recall any college course you had as a prerequisite – there had to be some overlap for you to bootstrap to the next level. Can you do short cycles to accomplish big changes? (Yes, or course – but what will that natural process look like?).

Let me get back to the 15 minute coding cycle for a minute (or even, if you will, test-driven coding):

If I know what I want to do, I (lets say) write a failing test. The process forces me to work out little details that simple specification might miss. That is, it’s a discovery process.

How do I build a group of 15 minute cycles into a short term (usable, complete feature) release?
I discover the shape of the test; I make parts of the test (incrementally) succeed; I may discover things along the way that the feature hadn’t considered about interaction; I maybe go update a collaborating part of the system with the new knowledge – that is to say, I work on the component, and on the interface.

Now, let me talk about the big change: I layout what new I want. I work out the big pieces of the problem. Things I don’t know how to do, I prototype (quickly) – that is, I instigate a discovery phase to feed the abstraction level I am shaping (this way I avoid “analysis paralysis”). Once the new function is worked out, I work out how it integrates, fits into something existing (system interface). Maybe I identify new technology that would be desireable (think of the first CD recorder, how that process came about). I use a “second choice” technology until then. I make tradeoffs. Once I have the big-system plumbing (interfaces and technologies) chosen, I might stub out a prototype for those interfaces (instead of making some connection or calculation for the user, I will print “this will make a connection”, etc.).

I structure my part of the system (that which I have control over), and I repeat the processes of structure & discovery, and stubing and functionality until there is something useful.

You see – with goals of discovery, the issue is not one of long term vs. short term – it’s one of integrating the two, and when (and to whom) you expose the short term at the state you’ve achieved.

If you have no overriding plan, no big bang happens. But, if you have an overriding plan, discover (or change of available technology) will modify your big plan – maybe a little, maybe a lot.

But the big unifying factor of BOTH events (to use KDE and Gnome examples) is that they fit into some plan; some part of a big new plan will not be ready for prime time; when they are, they will go thru the phase of discovery inevitable when exposed to an ever larger user base. This is where incremental an big-plan converge and overlap. I would argue, this is the new (higher abstraction) ever-ongoing incremental: it’s nothing new, it’s just a higher level view of the same things scaled differently and integrated differently.

There is a process for identifying the important things at the higher level of abstraction (call it Architecture, but it is more than that, and architectural rules alone don’t cover it). In fact, I think of 3 different layers, or kinds of architecture in designing systems.

The process is a complete parallel to team/social processes; human systems (how they operate) and big system design match well, and in fact must intersect / interact.

I would be happy to talk more about this, for anyone interested.

I’ll be at PyCon-2010. See you there.

- Yarko

I recently made the switch from the world of windows to Linux. Actually, I installed Ubuntu 9.10. Nice release, thank you! I just now stumbled across your blog, and this thread. Sorry for the belated post.

I would suggest an 18 month to Milestone / 18 month to LTS release cycle. These would be broken up into 6 month releases.
1) The Milestone: is the stable desktop/workstation type release. These are supported for the duration of the 18 months between Milestone, and LTS. This is also the staging area for the ‘upcoming’ major API type upgrades/updates.
1.a) Milestone +1 would be the time for a weighted % of major updates.
1.b) Milestone +2 would be the time for a weighted % of stabilization, but still include some new but somewhat less risky updates.

The third post Milestone release of course would be the LTS. The LTS of course would be heavily weighted % wise to Polish Polish Polish and more Polish.
1.c) LTS: This release is about stable API’s, stable package updates, and a development environment that fosters intermediate to long term ‘growth’ for its intended audiences. It’s security, and major packages should be maintained throughout its life of 3 years.

Happy Computing,
Gary

A. Switch concepts from “Software Repositories” to “Online Product Inventories” (OPI). OPI can contain products of all types, including software, music, or grocery items.

B. Create an online payment service called “Ubuntu Shopper Partner” (USP), which the online shopper can use to purchase products from OPI. This service will integrate with the package management software on the user’s PC so that stuff like product keys will be handled in a manner transparent to the user. USP will make money for Canonical through fees.

C. There will be a program offering to include OPI in default Ubuntu installations in return for monetary compensation. All products in such OPI must be fully compatible with the Ubuntu release in which they are included.

D. This obviously doesn’t come to exclude Free Software, only to add commercial options as well.

Personally, one key issue here is managing expectations. Ubuntu’s past releases have created for me the following expectations:

* Even numbered first iteration releases are Long Term Support releases. (6.06, 8.04)
* Even numbered second iterations are cleaned and more stable Even numbered first iterations (but are not LTS). (6.10, 8.10)
* Odd numbered releases are useable playgrounds that are used to collect information for the next LTS. (7.04, 9.04)
* Odd numbered second iteration releases are cleaned and more stable Odd numbered first iterations. (7.10, 9.10)

Wether or not the above is true, for some reason it’s the message I heard since starting with Ubuntu 5.04. It’s now what I expect from Ubuntu releases.

If Ubuntu decides to implement a new release cycle it should have a clear understanding of current customer expectations. Otherwise it risks putting serious strain on customer relationships with Ubuntu. I know I’ve stopped being loyal to company brands because of failed expectations. It’s totally fine to change things up, but it needs to be well communicated to users.