[Kolab-devel] Process Around Kolab 3.4 Release (Book Fri, 15:00 CET)

van Meeuwen, Jeroen jeroen at kolab.org
Wed Feb 11 13:46:38 CET 2015


Hi there,

I wanted to let you know I've started some of the work needed to get 
Kolab 3.4 out of the door some time this month.

Firstly, my intended timeframe is between now and two weeks from now, 
with very little room for further delays.

Secondly, I would like to open up the process a little bit, so here's 
how I was thinking of working with this:

   - I've created a release tracker issue in our Bugzilla;

     https://issues.kolab.org/show_bug.cgi?id=k3.4

   - Any issue that is currently "open" (i.e. their status is 
UNCONFIRMED, NEW, ASSIGNED, NEEDSINFO, IN_PROGRESS, or even RESOLVED), 
and that matters to you, should be made to block this tracker ticket, 
and, of course,

   - Any new issue you find in current Kolab:Development should also 
block the 'k3.4' tracker issue.

     The easy way of doing so is to add 'k3.4' to the "Blocks:" field in 
the ticket in question.

   - This is also the time we start looking at making sure that a 
Kolab:Development next-next-finish installation functions as is 
intended, and gets you the best possible show-case implementation of a 
Kolab Groupware server (i.e. all the fancy stuff should be in the 
defaults).

Some people may be involved with Debian packaging more so than they are 
with work on the Web Administration Panel, or as in my case, more 
involved with the RPM / CentOS 6 side. Please do not hesitate to focus 
on just what you find important, we'll figure out what is indeed a 
blocker vs. what is a minor issue that can be resolved with an update to 
a package later.

Speaking of such decision-making level events, this is the other part I 
would like to open up further. Rather than my say-so at 4am in the 
morning on a February 14th like last year's Kolab 3.2 release, I would 
like to have meetings on IRC (in #kolab) with those of you involved with 
resolving tickets -- packaging or software or otherwise.

As most of us are in the European time-space continuum, I propose Friday 
13:00 CET to do so. I'm not sure how many people will be attending, but 
it is common practise to have a little bit of a meeting protocol 
regardless, see below. There's also an agenda;

== Agenda ==

* Existing blocker tickets to releasing Kolab 3.4.

* Any other tickets that could be considered blockers to releasing Kolab 
3.4.

Both the former topics will search for a volunteer to seek resolution of 
the ticket, and be assigned accordingly, or (should be considered) 
popped off the blocker list.

* Setting the time and date for the next meeting.

* Miscellaneous / Open Floor.

   It helps if you have topics that need to be here before the meeting.

== General Rules ==

* The meeting moderator (Mads Petersen) will start the meeting, and set 
the topics.

* Participants should refrain from going off the defined topic.

* Participants may only speak when it is their turn. There is a speaking 
queue. The moderator will inform you when it is your turn to speak.

   * If you have a question, type "?".  You will be added to the end of 
the speaking queue.
   * If you need to speak, type "!".  You will be added to the end of the 
speaking queue.

   NOTE: It can speed things up if you have your question or comment 
typed in ahead of time and just send it when you get approval.

* If you're done speaking, type "EOF".  That will let others know you're 
done.
* If you agree with a participant's statement, type "username: +1". If 
you disagree: "username: -1".

   This can be done by anyone at any time, and does not require sitting 
in the speaking queue. Specifying the username of the participant whom 
you are +1'ing helps make it clear what you are agreeing with.

-- Jeroen


More information about the devel mailing list