[Kolab-devel] Debian Updates Repository, and Development repository

[Jeroen van Meeuwen]

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 
K:3.1:U.

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 
useful.

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 
for testing.

> Another question regarding Updates: If I was to make a request on OBS
> for example for package
> https://obs.kolabsys.com/package/show?package=roundcubemail-plugins-ko
> 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 
back.

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.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08