[Kolab-devel] Debian Updates Repository, and Development repository
Jeroen van Meeuwen
vanmeeuwen at kolabsys.com
Sat Nov 9 15:30:10 CET 2013
On Thursday, November 07, 2013 04:03:30 PM Timotheus Pokorra wrote:
> Hello Jeroen,
> Torsten and I talked yesterday about the repositories for Debian,
> Updates and Development.
> I assume, that we should not update the Updates repository to often,
> since that affects not only Debian, but CentOS as well, and could
> confuse people who rely on a stable CentOS release.
> Therefore, I guess as long as the debian packages are experimental, it
> is better to tell potential testers in the docs, to use the
> development packages.
The Kolab:Development packages though are to move forward towards what
will ultimately become Kolab 3.2. It is, as such, not for staging the
"packaging", but for staging the "product".
While it is not yet determined what kind of features we will be working
on for Kolab 3.2, and we have limited time available (due to the delay
in Kolab 3.1 finally being released as stable), they will likely not be
all that many / all that intrusive changes.
For as long as no features have been listed for inclusion in Kolab 3.2,
and therefore no enhancements to particular software is being pushed out
to Kolab:Development, the Development repository will largely stay the
same for as far as "upstream software versions" will be concerned.
After all, the addition of features triggers two considerations:
- if the feature is a compatible enhancement, in an $x.$y.$z
versioning schema the $y will be bumped.
- if the feature is not compatible, or a piece of software is
refactored, in an $x.$y.$z versioning schema the $x will be bumped.
You should therefore be able to judge from the version numbers (of the
software that Kolab is itself upstream for), whether or not a software
update is compatible with a particular Kolab release.
I therefore suggest that;
- Packagers do target Kolab:Development free of any concern it might
in fact break someone's installation,
- Successful packaging fixes in Kolab:Development are either;
a) selectively submitted (diff to only those files), or
b) wholly submitted (request "branch merge" if you will).
For example, if there is a Debian / APT specific packaging bug for
kolab-utils, then you would;
1) Fix it in Kolab:Development,
2) See if the version in Kolab:Development (you just fixed the issue
in) would be compatible with Kolab:3.1:Updates:
a) If K:D contains 3.2.0, and K:3.1:U contains 3.0.5, then you can
not just push 3.2.0 to K:3.1:U, or
b) If K:D contains 3.0.7 (because so far it has not needed any
enhancements for Kolab 3.2), and K:3.1:U contains 3.0.5, then you can
just push (request the "branches be merged") the K:D fixes on to
If the fixes involved are Debian / APT specific packaging bugs, you need
not have any concern about the effects on CentOS users.
If the fixes involved are patching, that you would also like to apply to
the *.spec variety of distributions (for consistency?), then of course
gathering some feedback / testing (w/ help of other people?) might be
For this, one can branch off K:3.1:U/kolab-utils in to one's home
project(s), and merge K:D/kolab-utils on top of it, then request people
use/install the home:$username:branches:* repository that'll be created
> Another question regarding Updates: If I was to make a request on OBS
> for example for package
> lab&project=Kolab%3ADevelopment, that would include a number of your
> changes to the CentOS packages too?
The merge will be executed by a human being (i.e. me), and so if your
updates conflict with mine, they will be resolved before being pushed
For your particular set of changes involve only Debian / APT packaging,
the CentOS packages will be unaffected.
> So will those go into 3.1 Updates eventually, or is that already for
> 3.2? Do we need to separate the packages for Debian and CentOS?
The update you mentioned now resides in Kolab:Development only. That
said however, it is (in this case) perfectly suitable for
Kolab:3.1:Updates as well.
You would do your proverbial equivalent of:
$ cd ~/devel/osc/Kolab:Development/roundcubemail-plugins-kolab
$ osc sr Kolab:3.1:Updates -m "Add empty directories for (...)"
Created request $y.
This request will appear in the queues of people that are members of the
group 'kolab-maintainers', and will need review (for we are updating
systems that are largely considered to need to remain stable and are
expected to continue to function), and provide feedback, reject and/or
accept the request.
So, that said, in principle you are free to submit requests for
everything under the sun to be included in Kolab:3.1:Updates.
Jeroen van Meeuwen
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the devel