[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [glassfish-dev] [External] : Re: Proposed Process for New Features, release plans post 7 Final
|
- From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
- Date: Wed, 25 Jan 2023 18:01:46 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=payara.fish; dmarc=pass action=none header.from=payara.fish; dkim=pass header.d=payara.fish; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GIGoqJlAxmfQchB0uFwVgChVlNrDS8G7l+kEpwj8YZg=; b=j+2PFHzeRR4rx1wD4ZasYHh3kIILzA0r7Z2eVf+L/jOrCIO7L7oJD7G7/YGixVv8i9me6T0kx6Gz0BAxnzBmcWu5bE4eWLFbD8c19Q22OofH0ZSgnDlq+0Xiuv47njtK8g0M5nLoMk5uZxj1iZ9MYY/W0HznZDQhZpa6bEYIR/poWo/bbxMlKUZpdqYPOHzoT1QitbApvGSk+j9c4k0MuFUWukSCIvsTFkXCzCMEWM7fvD3HC8QXkOQ8q5Co6r0pPt9QY5ZT/cOTPcsHRB8aM1npECbLQIwVnpombpLlE2SolvWVXS6fBx0VHFBOHaPjg2lWZCoTHWfiH18SJNWiEw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E5/u8K++LAcJrABft6lwYWrRn6jLSWdQyst/cRTTywuwZPELQDaBfN1kLBH9+x9qDCeosT13vWrnLQkOAayVU/ZkosHKqVJ+T/80nrKymiyU8jZRx+IB+lexALaFPxDfgFdg5aZdnxhw4sLEU22aH8VUnpOyIdcLXpXMXQpwu0gSZD6kG1pQ0yv9edc+Xp7+DuLSk4MknAXKlUnRvi7lzg1XfSQjDoUI31YEOCtbBRF/ZK1GKdbqT5qckwOWSoRcqAijjdy9/+fw5VJlMzYt8tDXkP7JI8wE4s6nAZQOpQ/+CkWMj1SS2Wg/E2hn0g658gEYjqHDDg5MOoRYGxhXMA==
- Delivered-to: glassfish-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/glassfish-dev/>
- List-help: <mailto:glassfish-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/glassfish-dev>, <mailto:glassfish-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/glassfish-dev>, <mailto:glassfish-dev-request@eclipse.org?subject=unsubscribe>
- Msip_labels: MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Enabled=true; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SetDate=2022-12-19T01:14:11Z; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Method=Standard; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Name=FUJITSU-RESTRICTED?; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SiteId=a19f121d-81e1-4858-a9d8-736e267fd4c7; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_ActionId=0ad009ed-e18f-422b-a547-91d953c5e7f1; MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_ContentBits=0
- Thread-index: AQHZMOcW0GmhqNUXuEK8Nit7d4kG1Q==
- Thread-topic: [glassfish-dev] [External] : Re: Proposed Process for New Features, release plans post 7 Final
Hi Hiroki,
Do you want to send this out as a vote?
Steve
-----Original Message-----
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Hiroki Sawamura (Fujitsu)
Sent: 19 December 2022 01:19
To: glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] [External] : Re: Proposed Process for New Features, release plans post 7 Final
Hi,
Thank you, Lukas. I reflected your suggestion:
```
1) Create GitHub issue and describe the need for the new/dropped features or significant behaviour changes.
2) Label the issue with "New feature" for a completely new feature;
"enhancement" for significant behaviour change;
"deprecation" for something to be removed.
3) Create PR that references the issue, copy the above label to it from the issue, and defer merges for at least 24 hours for review by other committers.
- If a PR is created without an issue, apply one of the above labels to it, and create a corresponding issue before review.
4) PR can be merged by any committer (including the proposer) after approved by committers from 2 different organisations.
- If the PR is created by a committer, it's implicitly approved by their organisation, and only 1 more approval from a different organisation is required.
- If no review or comment has been posted for 7 days, it can be merged with the approval of another committer of the same organization.
- If there is any doubt, label "CONTROVERSY" as PR and continue the discussion.
In this case, if there is no objection within 7 days of the last update by the proposer, the discussion is considered to be over.
* This process applies for new/dropped features or significant behaviour changes.
* Any PRs that do not meet the above conditions can be merged immediately by any committer (including the proposer) after 1 approved review by another committer.
such as obvious bug fixes, refactoring/code cleaning, upgrading utility modules, adding tests.
```
Kind Regards,
Hiroki
-----Original Message-----
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Lukas Jungmann
Sent: Friday, December 16, 2022 10:56 PM
To: glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] [External] : Re: Proposed Process for New Features, release plans post 7 Final
On 12/16/22 2:22 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Dec 16, 2022 at 1:08 PM Lukas Jungmann
> <lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:
>
>
> "A committer is required to check PRs at least once a week, so he is
> not
> allowed to unplug himself for a week - vacation, sickness, whatever the
> real reason can be - without a replacement."
>
>
> Everybody is always allowed to unplug themselves for a week (or two
> weeks, or longer). And sickness is also allowed, of course. I don't
> think we can disallow someone from becoming sick.
>
> But in the event of those things happening, the project should be able
> to simply continue. There's IMHO no need, or requirement, for the
> person unplugging themselves, to become available again within any
> given time limit.
right, the project must be able to continue and a full week sounds like a good compromise to me as usually it takes ~3 days to somehow resolve "unexpected events". On the other hand taking 1 day off and be out for 5 continuous days is not as uncommon as it may seem in many countries around the globe through out the year, not only during Christmas break when one sort of expects delayed responses; PR on Mon and merge on Fri/Sat/Sun can be another example against "hard-coded" 5 days.
As I understand, this "limit" is applicable to bigger changes, not simple/non-controversial bug fixes/changes where waiting too long really makes no sense.
thanks,
--lukas
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> _______________________________________________
> glassfish-dev mailing list
> glassfish-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/g
> lassfish-dev__;!!ACWV5N9M2RV99hQ!OkKoNepEuBep9JoEJJ8sSkcD0ydPHAXwWBIJ7
> NXIFn1hn91cVgjSQcqzTs_JYfwyi7QqwvUYyE2D6pU5djgfENVD$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev