On 11 March 2013 23:12, Thierry Carrez <t...@ubuntu.com> wrote:
> Robert Collins wrote:
>> A - an archive that we place a high friction change process on,
>> intended to eliminate regressions [the SRU]
>> B - a logical name that users can associate with a /large/ bundle of
>> changes. One can say 'Unity in Raring is fantastic' only because
>> Raring is a thing.
>> C - A set of APIs that work well together and which we commit to keep
>> working for the duration of the release (except where it is infeasible
>> [e.g. due to facebook dropping their support for the server side of an
>> API].
>> D - A mostly unchanging environment. No surprises.
>> [...]
>
> Today, it's also [E] an install media.
I don't agree here. There is [E] an install media in the 'what is a
release', but 'has unchanging install media' is not an important thing
in any user story I have seen so far. Dailies *from the released
archive* are fine *today*, if we chose to publish them. AFAICT there
are no use cases or user expectations to fail that are tied to how
often install media are updated vs the already covered aspects.
> About LTS mode ('keep my behaviour unchanged') I suspect every n years
> you'll have to create another LTS mode. For people who want their
> behaviour unchanged but from a reasonably modern starting point. How do
> you handle that ?
It is just a combination of options - feature flag values, so you
could name each LTS combination 'precise' etc.
Or you could take a less orchestrated approach and just allow saying
'give me the default behaviour new installs had on <date>'. Then
deprecation of support for a given thing is directly tied into that,
and the UI can show people who are lagging warnings without needing to
translate codenames.
>> - Stop doing fixed releases altogether.
>
> Once we adopt the rest of your proposal, what would be the added cost of
> actually still doing "releases", that could serve as reference points in
> time and install media ?
In my proposal you would not do reference points in time in the sense
of a distinct series with frozen packages. So it is a question that
doesn't apply. Install media should churn out daily (or more often if
there is a need).
> With a well-oiled release process, the cost is not high. And keeping
> that logical name to describe a point in time has benefits: reference
> install media, time-based cycle to focus development community, media
> attention, LTS mode starting point, easy way to describe a set of APIs
> and everything else you have in [B] above.
>
> If you think of a "release" not in term of upgrade and maintenance but
> in terms of a development milestone and a breathing rhythm, I think the
> benefits outweigh the costs. And it's certainly compatible with the rest
> of your proposal.
I don't understand what you mean by 'point in time' here. Could you
expand on that?
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Cloud Services
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
