[sip-comm-dev] Preparing for alpha2 (Romain Kuntz for release manager)


#1

Hello all,

It's been a while since our last (and first) release, and I think times
are ripe for a new one - alpha2.

This new release would mainly consist in wrapping up all working
functionalities that we currently have, making sure that they really are
working, and rolling out all corresponding native installers and jars.

I hope that we would be able to speed up our release loop after that and
be able to bring out alpha3 (that, among other things would include FMJ
and would no longer have the J1.4 compatibility condition).

The list of issues that we need to address before rolling out the
release is here:
https://sip-communicator.dev.java.net/issues/buglist.cgi?target_milestone=alpha2&component=sip-communicator&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED

During the following days we will decide what else we need to add there
and what are the issues that we need to push back to alpha3. Generally
however, I wouldn't want to see anything that would take more than a
couple of hours of work in it. As I said, the purpose of this release is
to simply wrap up everything working and put a release stamp on the
whole bundle.

Yana would shortly create an alpha2 SVN branch and we will be using it
as the source for the release.

I've asked Romain Kuntz to be our release manager for alpha2 and he has
accepted. When describing the role of a release manager I like using a
quotation from Richard Hall that he once sent to the Felix mailing list:

"The release manager is the person who is responsible for making sure
all of the T's are crossed and all of the I's are dotted when we go to
make a release (e.g., making sure we have the appropriate LICENSE and
NOTICE everywhere they are supposed to be, tagging the release, signing
the release, etc.)."

Developers should therefore be prepared to receive a fair amount of
prodding from Romain during the following weeks as he would be following
the status of all alpha2 issues, and making sure that someone would
either take care of them or push them back to alpha3.

Good luck to all, and let's hope we'll soon pop the bubbly!

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Emil, all,

Yana would shortly create an alpha2 SVN branch and we will be using it
as the source for the release.

You can already find our alpha2 branch at:

https://sip-communicator.dev.java.net/svn/sip-communicator/branches/alpha2

Cheers,
Yana

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil, all,

I'm happy to take the release manager role for alpha2! So I'll be the bad guy who annoys developers in the next few weeks. I'll try to do my best :slight_smile:

Here are some thoughts and questions, let me know what you think.

I had a look at the alpha2 issue list, and was wondering who is supposed to take care of the one assigned to "issues@sip-communicator"? Shall we assign all issues to specific names?

What would be the timeline for the release? To decide this, I'd like each developer with assigned issues (and maybe others willing to stabilize code for alpha2) to tell me which issues they plan to solve, which one they plan to move to alpha3, and what would be the rough timeline.

As Yana created an alpha2 branch, I think that from now on each developer that wants to commit something to the repository should ask himself the question if this is someone that is supposed to appear in the alpha2 release: if yes, commit it to the alpha2 branch, then to the main branch, if no, commit it only to the main branch. What I mean is that all changes in the alpha2 must be also committed to the main branch.

BTW, is cruisecontrol also runned on the alpha2 branch code?

Cheers,
romain

···

On 2007/10/17, at 18:50, Emil Ivov wrote:

Hello all,

It's been a while since our last (and first) release, and I think times
are ripe for a new one - alpha2.

This new release would mainly consist in wrapping up all working
functionalities that we currently have, making sure that they really are
working, and rolling out all corresponding native installers and jars.

I hope that we would be able to speed up our release loop after that and
be able to bring out alpha3 (that, among other things would include FMJ
and would no longer have the J1.4 compatibility condition).

The list of issues that we need to address before rolling out the
release is here:
https://sip-communicator.dev.java.net/issues/buglist.cgi?target_milestone=alpha2&component=sip-communicator&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED

During the following days we will decide what else we need to add there
and what are the issues that we need to push back to alpha3. Generally
however, I wouldn't want to see anything that would take more than a
couple of hours of work in it. As I said, the purpose of this release is
to simply wrap up everything working and put a release stamp on the
whole bundle.

Yana would shortly create an alpha2 SVN branch and we will be using it
as the source for the release.

I've asked Romain Kuntz to be our release manager for alpha2 and he has
accepted. When describing the role of a release manager I like using a
quotation from Richard Hall that he once sent to the Felix mailing list:

"The release manager is the person who is responsible for making sure
all of the T's are crossed and all of the I's are dotted when we go to
make a release (e.g., making sure we have the appropriate LICENSE and
NOTICE everywhere they are supposed to be, tagging the release, signing
the release, etc.)."

Developers should therefore be prepared to receive a fair amount of
prodding from Romain during the following weeks as he would be following
the status of all alpha2 issues, and making sure that someone would
either take care of them or push them back to alpha3.

Good luck to all, and let's hope we'll soon pop the bubbly!

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Romain,

(see inline)

Romain KUNTZ wrote:

Hi Emil, all,

I'm happy to take the release manager role for alpha2! So I'll be the bad guy who annoys developers in the next few weeks. I'll try to do my best :slight_smile:

We'll do our best to help you stay a good guy:) We like you like this:)

Here are some thoughts and questions, let me know what you think.

I had a look at the alpha2 issue list, and was wondering who is supposed to take care of the one assigned to "issues@sip-communicator"? Shall we assign all issues to specific names?

I agree that for all issues staying for alpha2 we have to assign specific names. I'll have a look what are the issues assigned to issues@sip-communicator that I could take and will assign them to myself.

What would be the timeline for the release? To decide this, I'd like each developer with assigned issues (and maybe others willing to stabilize code for alpha2) to tell me which issues they plan to solve, which one they plan to move to alpha3, and what would be the rough timeline.

Ok, for me. I'll change the "Target milestone" to alpha3 for all my issues, which I won't have the time to finish for this release. I'll also send you in the beginning of next week some timing information. Is that ok?

As Yana created an alpha2 branch, I think that from now on each developer that wants to commit something to the repository should ask himself the question if this is someone that is supposed to appear in the alpha2 release: if yes, commit it to the alpha2 branch, then to the main branch, if no, commit it only to the main branch. What I mean is that all changes in the alpha2 must be also committed to the main branch.

Is this really obligatory? Because, finally the alpha2 branch will be merged with the trunk. On the mean time we could commit to alpha2 everything we want to be included in the release and in the trunk everything else. WDYT?

BTW, is cruisecontrol also runned on the alpha2 branch code?

It wasn't the case this morning, but I think Emil will take care of this?

Cheers,
Yana

···

Cheers,
romain

On 2007/10/17, at 18:50, Emil Ivov wrote:

Hello all,

It's been a while since our last (and first) release, and I think times
are ripe for a new one - alpha2.

This new release would mainly consist in wrapping up all working
functionalities that we currently have, making sure that they really are
working, and rolling out all corresponding native installers and jars.

I hope that we would be able to speed up our release loop after that and
be able to bring out alpha3 (that, among other things would include FMJ
and would no longer have the J1.4 compatibility condition).

The list of issues that we need to address before rolling out the
release is here:
https://sip-communicator.dev.java.net/issues/buglist.cgi?target_milestone=alpha2&component=sip-communicator&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED

During the following days we will decide what else we need to add there
and what are the issues that we need to push back to alpha3. Generally
however, I wouldn't want to see anything that would take more than a
couple of hours of work in it. As I said, the purpose of this release is
to simply wrap up everything working and put a release stamp on the
whole bundle.

Yana would shortly create an alpha2 SVN branch and we will be using it
as the source for the release.

I've asked Romain Kuntz to be our release manager for alpha2 and he has
accepted. When describing the role of a release manager I like using a
quotation from Richard Hall that he once sent to the Felix mailing list:

"The release manager is the person who is responsible for making sure
all of the T's are crossed and all of the I's are dotted when we go to
make a release (e.g., making sure we have the appropriate LICENSE and
NOTICE everywhere they are supposed to be, tagging the release, signing
the release, etc.)."

Developers should therefore be prepared to receive a fair amount of
prodding from Romain during the following weeks as he would be following
the status of all alpha2 issues, and making sure that someone would
either take care of them or push them back to alpha3.

Good luck to all, and let's hope we'll soon pop the bubbly!

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Yana,

I agree that for all issues staying for alpha2 we have to assign specific names. I'll have a look what are the issues assigned to issues@sip-communicator that I could take and will assign them to myself.

Great thanks!

What would be the timeline for the release? To decide this, I'd like each developer with assigned issues (and maybe others willing to stabilize code for alpha2) to tell me which issues they plan to solve, which one they plan to move to alpha3, and what would be the rough timeline.

Ok, for me. I'll change the "Target milestone" to alpha3 for all my issues, which I won't have the time to finish for this release. I'll also send you in the beginning of next week some timing information. Is that ok?

Sure yes.

What I mean is that all changes in the alpha2 must be also committed to the main branch.

Is this really obligatory? Because, finally the alpha2 branch will be merged with the trunk. On the mean time we could commit to alpha2 everything we want to be included in the release and in the trunk everything else. WDYT?

Ok, but maybe the most critical code (if any) should me merged in the main branch right after committing to the alpha2 branch? That may avoid too much conflict when merging both branches after the alpha2 release.

Well, maybe I'm a bit too paranoiac :slight_smile:
Anyone here has some more experiences on managing branches?

Cheers,
romain

···

On 2007/10/18, at 17:57, Yana Stamcheva wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey Romain,

Romain KUNTZ wrote:

Hi Yana,

I agree that for all issues staying for alpha2 we have to assign
specific names. I'll have a look what are the issues assigned to
issues@sip-communicator that I could take and will assign them to
myself.

Great thanks!

What would be the timeline for the release? To decide this, I'd
like each developer with assigned issues (and maybe others
willing to stabilize code for alpha2) to tell me which issues they
plan to solve, which one they plan to move to alpha3, and what
would be the rough timeline.

When setting issue deadlines please keep in mind that we should be able
to release in more or less two weeks from now. This should help everyone
determine whether to address certain issues or move them to alpha3.

Ok, for me. I'll change the "Target milestone" to alpha3 for all my
issues, which I won't have the time to finish for this release.
I'll also send you in the beginning of next week some timing
information. Is that ok?

Sure yes.

What I mean is that all changes in the alpha2 must be also
committed to the main branch.

Is this really obligatory? Because, finally the alpha2 branch will
be merged with the trunk. On the mean time we could commit to
alpha2 everything we want to be included in the release and in the
trunk everything else. WDYT?

Ok, but maybe the most critical code (if any) should me merged in the
main branch right after committing to the alpha2 branch? That may
avoid too much conflict when merging both branches after the alpha2
release.

I think that the common practice is to commit fixes to the release
branch and then move them to the development branch when merging.
However, I completely agree that committing to both places right from
the start (where applicable) would probably save us a lot of time and
make the merge easier. I guess it would depend on each developer.

Cheers
Emil

···

On 2007/10/18, at 17:57, Yana Stamcheva wrote:

Well, maybe I'm a bit too paranoiac :slight_smile:
Anyone here has some more experiences on managing branches?

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net