[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