[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Koha-devel] Post-3.0 git branch and version numbering
From: |
Henri-Damien LAURENT |
Subject: |
Re: [Koha-devel] Post-3.0 git branch and version numbering |
Date: |
Tue, 12 Aug 2008 16:32:41 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080725) |
Galen Charlton a écrit :
Hi,
On Tue, Aug 12, 2008 at 4:19 AM, Henri-Damien LAURENT
<address@hidden> wrote:
As far as we (BibLibre) are concerned, even though it was talked about
a while back, we are in fact not candidate for the QA management
position in 3.2. So the position is indeed open: anyone volunteering ?
Joshua may be a volunteer; I'll let him toss his hat in the ring
directly if he chooses.
Would Joshua be volunteer both for QA and Release Maintainer ?
But going beyond the QA position, I would be
interested in setting up a mechanism for distributing the review and
signoff of important patches across as many contributors as are
willing to do it, which might ease the burden on the QA manager a bit.
Good Idea.
But I'm really willing to be Release Maintainer for 3.0.
Great. What are your plans (roughly speaking) for maintaining 3.0.x?
Stay tuned for bugs on rel30 and HEAD, and keep track of those who are
on both versions.
File bugs when they are only sent on lists.
cherry pick patches which adress rel30 bugs.
If a patch is sent related to branch 3.0, then resend the patch for
branch3.1
In that purpose, maybe building a smolder server for 3.0 and revive
information nightly could be good.
Or maybe I could use Andrew's one if allowed.
Comments welcome.
We fully support what Chris said about the roles being spread around as many
organisations as possible.
By the same token we support his candidacy to be the translation manager.
As do we.
But I also think we should be clear about what those positions would mean.
Specifically, these roles (Q&A, RM for 3.1, RMaint for 3.0,
Translation) should have ssh access to the git repository via a key so
that they can do what their position requires them to do, with
sign-off of their commits so that RM can be informed in real time of
what has been done.
This can be done on a branch-by-branch basis. In other words, we can
set it up so that the 3.0 maintainer can push directly to the 3.0.x
branch.
OK then for Release Maintainer.
What about QA manager for position, if he were outside from Liblime and
BibLibre ?
Chris spoke his plans on Translation.
Having a website where patches would be fetched by RM seems to me a
solution which will make the RM task heavier and quite tricky if some
patches are to be replaced, or updated. Would it not be easier if he
could push sthg on his remote branch with signing-off his patches, same
for QA ? And then, RM would just have to merge those remote branches.
my 2 cts.
--
Henri-Damien LAURENT