>> The hard part from my point of view is deciding as a project what we
>> want to define couplings for, what the couplings should be, and what
>> gets priority generally.
> the python stack, the php stack, and others might be loosely coupled, but
> throwing a few library transitions makes them highly coupled. couplings are
> dynamic, not static.
> Then you need to define "getting priority" as well. I currently spend most of
> my time fixing autopkg tests for transitions which I'm not interested in.
> However it's necessary to fix these or you don't get any transition done.
If nobody defines a coupling for a specific package/set it would be
fine to sync it or update it at any time (Sorry that should have been
in original email, I do mention int the doc "We would still need a
policy similar to the current microreleases policy for items that
aren’t tightly coupled to anything else and have great test cases
allowing them to be released at any time." but worst case an SRU would
>> I definitely don't have all the answers - but I believe this would
>> reduce the workload generally rather than make it worse. I'm willing
>> to do a lot of work to get this done (including changing roles), but
>> in the end it will be up the various teams..
> "up to the various teams". That currently doesn't work, and I don't see how
> will work in the future, given that teams are now more "focused", and leave a
> lot to the "community". We have a lot of unowned stuff, and usually it the one
> who sees blocking issues who has to clean up.
> In your "Example Usage", you reserve one month for "Misc" and everything else,
> and the remaining five months for everything else. So you may be more recent
> for 1% of the packages, but more out-of-date for 99%. Is that what users want?
I only focused that example for the Ubuntu desktop, but they don't get
to claim the month of Gnome for just them.
(It also occurs to me that I meant this to be more of a one
directional coupling, maybe better described as "generally waits for"
- still need a better word)
As an another example, lets say for OpenStack we define the following couplings:
OpenStack -> Kernel
OpenStack -> Apache
OpenStack -> RabbitMQ
OpenStack -> MySQL
If RabbitMQ, Apache and MySQL aren't coupled up with the kernel they
can land on the same month.
Then OpenStack can land on any month that doesn't have one of those
other major updates.
And it could be that OpenStack -> MySQL doesn't makes sense as we've
only ever seen that break in non-obvious ways.
And if we don't define a coupling for (aka MySQL ->) then it doesn't
need to wait for anything else.
The key thing for users is we publish these couplings so they can
understand how much testing of packages they would need to do in any
one month (and we give them warnings when coming).
If they depend on things that aren't defined in the couplings, users
should expect updates for them at any time.
> What we are currently doing continuously would be stuffed into one month,
> coupling 99% of the packages even more. I predict that the outcome of this
> would be a mess and not a stable basis that you can build upon.
> Ubuntu-devel-discuss mailing list
> Modify settings or unsubscribe at:
Ubuntu-devel-discuss mailing list
Modify settings or unsubscribe at: