[csw-maintainers] Integrating unstable→testing — handover

[Maciej (Matchek) Bliziński]

2013/7/11 Oliver Kiddle <opk at opencsw.org>:
> I'm replying to two messages here.
>
> Maciej (Matchek) Bliziński wrote:
>> We've kept the 'stable' dead for a while now. What do you think about
>> pointing the 'stable' symlink at dublin and the 'testing' symlink at
>> kiel?
>
> I'd definitely be in favour. The old stable release is way too ancient
> and it is a lot easier for users to understand if our naming is
> meaningful.

Cool.

> To what extent have fixed packages been moved to dublin since it was
> frozen?

In practice, close to zero updates in the last... I don't know, year?
We did push PostgreSQL updates though, if I'm not mistaken.

We have the capacity to submit with csw-upload-pkg to a named catalog,
not only unstable. We can whitelist dublin and make submissions there
a standard practice, with the regular checkpkg procedure. If anyone
wants to submit packages to dublin, it's either possible already, or
we can make it possible without too much effort.

> Has it relied on a single person or could any maintainer run
> integrate_catalogs.py if they had fixed a critical issue.

Anyone can run integrate_catalogs.py, and the same goes with
csw-upload-pkg. The former is far more dangerous though.

> Maciej (Matchek) Bliziński wrote:
>> I'd like to hand over the unstable→testing integration to someone
>> else. It's a periodic task, where you take an existing state of
>> unstable, create a list of operations to bring testing to the same
>> state, then you review the list and if it looks good, you execute it.
>> If it doesn't look good (e.g. there's a broken package in unstable),
>> you manually remove this package from the list.
>
> I'm tempted to take on this task though in a normal situation my use of
> unstable can be limited.
>
> For the systems at my work, I ended up creating my own stable release by
> taking a snapshot from unstable as it then was and grabbing newer
> packages in those cases where there were problems.

I used to do the same. I guess it's a necessity if you run a fleet of
machines. It's good that you have experience with managing catalogs.

> It was easier to use
> unstable as a starting point because I needed some extra things that
> were broken or missing at that time. This was before dublin and stable
> at that time was already old. We've got new hardware and I'm currently
> preparing a similar snapshot based on kiel. Perhaps I should use dublin
> but kiel seemed stable on the test machine. The result is that at the
> moment I'm testing and using unstable quite thoroughly. What is the
> intended schedule for kiel being frozen?

There isn't a fully crystallized plan right now. There is a consensus
that we will move towards timed releases, e.g. every 6 or every 12
months. With the limited workforce it has been very hard to hit our
targets, but at least our efforts were coordinated. I'm thinking that
what we want to finish for the kiel release is the OpenSSL migration.
When we're done, we'll freeze kiel and continue with a new testing
release. This topic will be definitely discussed in Berlin.

We have the audacious goal of doing a full rebuild with GCC, but I
still don't know if it's feasible. Maybe we should focus on IPS
instead. To be discussed in Berlin.

Maciej