[kde-promo] Coordination of releases

Sebastian K├╝gler sebas at kde.org
Sun Apr 2 18:31:33 BST 2006


I've been put off a little by the way the past (mainly the x.y.z) releases 
have been coordinated. Therefore, I'd like to propose a simple procedure to 
follow.

What we need is the following:

1) A list with changes between the last and the upcoming release
2) Clear indication of dates known to those who are preparing the release
3) Clear responsibilities: Who does what?


ad 1):
Carsten Niehaus has been putting together a list which was a great help with 
identifying keypoints for the press release. That has been a great help. I'd 
like to encourage developers to work with Carsten there. Also, he probably 
needs some help with this. So please, everybody supporting Carsten with 
creating the list of changes.

ad 2): 
It'd be good if the release team (TWG, right?) could send a reminder one week 
before tagging a x.y.z release to kde-promo so we're able to start creating 
release notes. For x.y releases, this should be one month, preferably around 
the feature freeze.

ad 3): 
The fact that no official email to announce the release of KDE 3.5.2 has been 
sent to kde-announce yet probably shows that the responsibilities are unclear 
at this point. Coolo has sent those emails in the past, but I figure, we can 
make that part of the Marketing Team's task as well. The responsibilities as 
I have them in mind would be the following:

- Initiating release preparations by sending a note to kde-promo
- Creating a list of changes: TWG
- Preparation of release notes: MWG, that includes:
	- Distilling key-features / key-messages
	- Posting notes on the dot
	- Sending announcement email to kde-announce
	- Doing whatever is necessary to make the release known to the public
- Actually releasing: TWG, with close coordination with MWG

Note: Those are the people / groups responsible, it does not mean that those 
have to be the people who do the actual work, but the people who should take 
care that it happens, and if not, to ring a bell and call for assistance.

On release day, we could coordinate (IRC?) that the release will happen, and 
at what time. This way the dot story, kde-announce email and website receive 
the release announcement all at once.

We, the Marketing Team have already worked out most of the things necessary 
for a properly announced release. If you're interested, please read [SKO]. 
The plan de campagne is to use that documentation to create procedures for 
x[.y[.z]] releases. 

Please help us in doing so, so we make our software releases reflect the 
quality of the code we've put together. Can we agree on that kind of 
procedure, including responsibilities? If not, what would be the proposed 
changes? Are there other considerations, I forgot to mention?

[SKO] http://spreadkde.org/handbook/release_promotion
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Let's put it this way: if you need to ask a lawyer whether what you do 
is "right" or not, you are morally corrupt. Let's not go there. We don't base 
our morality on law. - Linus Torvalds

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 483 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060402/30ea5ae9/attachment.sig>
-------------- next part --------------
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.


More information about the kde-core-devel mailing list