Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

> On 03/15/16 18:20, Kinney, Michael D wrote:
> I don't object to pulling, if the submitter explicitly requests it, and
> if we're making this option official now.

Let's say "at the discretion of the person doing the merge" rather than
writing down that it should need an explicit request.

Over time, as people get used to using the tools properly, I would expect
that pulling will become the default behaviour. By choosing to rebase
instead, *you* are choosing to discard the correct history of the original
development vs. the merge, and to take the responsibility for any
resulting problems.

> Regarding Reviewed-by tags, I like to review series per-patch, and I
> also like the tags to be present in the commit history per-patch. For
> example, when a series modifies several top-level packages, I don't /
> can't always review all patches in full depth; so I might give an
> Acked-by for some patches, or even nothing.
>
> In this case I'm fine with the submitter rebasing one last time, adding
> the tags, and then I can do the pull. (I'll have to remember to verify
> the individual patches on the branch being pulled, and the labels on the
> commit messages, against the mailing list traffic.)

Of course you had to do that verification anyway, as the patch in your
inbox might not actually match the "same" message on the list. So no
change there.

It's also worth noting that we use "rebase" for two different things. In
normal usage it's considered bad form just to recommit the same patch on
the *same* parent. We will probably continue to do that freely here, and
as long as you don't move it to a new parent, that's OK. But people
generally still call that "rebasing".


-- 
dwmw2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Laszlo Ersek]

On 03/15/16 18:20, Kinney, Michael D wrote:
> David,
> 
> Thanks for the suggestion.  Today the git dev process requires a rebase.
> Given that this operation is transferring content from one community 
> maintained feature branch in edk2-staging into edk2/master, I agree the
> option to use 'git pull' should be available.  Not sure it should be 
> required in all cases.  I would prefer let the feature owner(s) decide 
> which method makes the most sense.
> 
> Does anyone have any objections to supporting either the current 
> rebase work flow or a 'git pull' work flow in step (6)?

I don't object to pulling, if the submitter explicitly requests it, and
if we're making this option official now.

Regarding Reviewed-by tags, I like to review series per-patch, and I
also like the tags to be present in the commit history per-patch. For
example, when a series modifies several top-level packages, I don't /
can't always review all patches in full depth; so I might give an
Acked-by for some patches, or even nothing.

In this case I'm fine with the submitter rebasing one last time, adding
the tags, and then I can do the pull. (I'll have to remember to verify
the individual patches on the branch being pulled, and the labels on the
commit messages, against the mailing list traffic.)

Thanks
Laszlo

> 
> 
> I think there are several methods we can support for development.
> 
> 1) Simple bug fixes/features sent directly to edk2-devel for PRs.
> 2) A larger or more complex bug fix/feature can optionally post a link
>to a branch on personal github fork to help simplify the review process 
>for those reviewers that prefer to use that method.  This type of bug 
>fix or feature is usually owned by a single subject matter expert.
> 3) A larger or more complex feature that requires design/dev/test by more
>than one subject matter expert.
> 
> We already support (1) and (2) today.  Feature branches on edk2-staging are 
> intended for (3).
> 
> I can think of a couple ways we end up in (3). The first is a feature we know
> requires multiple subject matter experts and the request is made to add
> to edk2-staging from the beginning.  The second is a PR that is sent to 
> edk2-devel, and the community believes it needs more design/dev/test work
> that requires cooperation of multiple subject matter experts and the PR 
> is re-directed to a feature branch in edk2-staging.
> 
> Thanks,
> 
> Mike
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
>> Woodhouse
>> Sent: Tuesday, March 15, 2016 3:50 AM
>> To: Kinney, Michael D ; Mangefeste, Tony
>> ; edk2-devel@lists.01.org 
>> Subject: Re: [edk2] EDK2 Staging Repository 2nd Draft
>>
>> On Tue, 2016-03-15 at 00:16 +, Kinney, Michael D wrote:
>>>
>>>
>>> Can you provide some revised text you would like to see in step 6.
>>>
>>> I agree that we need to use the tools in ways that help make this easy, 
>>> prevent
>>> errors, and preserve history.  Given that step 6 describes promoting a 
>>> feature
>>> from edk2-staging repo to edk2 repo, what set of git operations you would
>>> recommend?
>>
>> Literally, 'git pull'. So my change in patch form would be:
>>
>> @@
>>  6) Process to promote an edk2-staging branch to edk2 trunk
>>  a) Request sent to edk2-devel that describes the feature, design, 
>> testing,
>> etc.
>>  b) Stewards evaluate request and determine if the feature meets 
>> edk2 criteria.
>> -c) If approved, use edk2 patch review/commit process on edk2-devel 
>> mailing
>> list
>> +c) If approved, use 'git pull' to merge the branch into edk2 
>> master, adding
>> +   any final 'Reviewed-by:' tags to the merge commit as appropriate.
>>  d) Remove feature branch from edk2-staging (maybe archived 
>> elsewhere?).
>>
>>
>> I'm still interested in what benefit we gain from a centralised
>> edk2-staging repository though, over the normal process of contributors
>> just pushing their work to github repositories and submitting PRs.
>>
>> --
>> dwmw2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Kinney, Michael D]

David,

Thanks for the suggestion.  Today the git dev process requires a rebase.
Given that this operation is transferring content from one community 
maintained feature branch in edk2-staging into edk2/master, I agree the
option to use 'git pull' should be available.  Not sure it should be 
required in all cases.  I would prefer let the feature owner(s) decide 
which method makes the most sense.

Does anyone have any objections to supporting either the current 
rebase work flow or a 'git pull' work flow in step (6)?



I think there are several methods we can support for development.

1) Simple bug fixes/features sent directly to edk2-devel for PRs.
2) A larger or more complex bug fix/feature can optionally post a link
   to a branch on personal github fork to help simplify the review process 
   for those reviewers that prefer to use that method.  This type of bug 
   fix or feature is usually owned by a single subject matter expert.
3) A larger or more complex feature that requires design/dev/test by more
   than one subject matter expert.

We already support (1) and (2) today.  Feature branches on edk2-staging are 
intended for (3).

I can think of a couple ways we end up in (3). The first is a feature we know
requires multiple subject matter experts and the request is made to add
to edk2-staging from the beginning.  The second is a PR that is sent to 
edk2-devel, and the community believes it needs more design/dev/test work
that requires cooperation of multiple subject matter experts and the PR 
is re-directed to a feature branch in edk2-staging.

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
> Woodhouse
> Sent: Tuesday, March 15, 2016 3:50 AM
> To: Kinney, Michael D ; Mangefeste, Tony
> ; edk2-devel@lists.01.org 
> Subject: Re: [edk2] EDK2 Staging Repository 2nd Draft
> 
> On Tue, 2016-03-15 at 00:16 +, Kinney, Michael D wrote:
> >
> >
> > Can you provide some revised text you would like to see in step 6.
> >
> > I agree that we need to use the tools in ways that help make this easy, 
> > prevent
> > errors, and preserve history.  Given that step 6 describes promoting a 
> > feature
> > from edk2-staging repo to edk2 repo, what set of git operations you would
> > recommend?
> 
> Literally, 'git pull'. So my change in patch form would be:
> 
> @@
>  6) Process to promote an edk2-staging branch to edk2 trunk
>  a) Request sent to edk2-devel that describes the feature, design, 
> testing,
> etc.
>  b) Stewards evaluate request and determine if the feature meets edk2 
> criteria.
> -c) If approved, use edk2 patch review/commit process on edk2-devel 
> mailing
> list
> +    c) If approved, use 'git pull' to merge the branch into edk2 master, 
> adding
> +   any final 'Reviewed-by:' tags to the merge commit as appropriate.
>  d) Remove feature branch from edk2-staging (maybe archived 
> elsewhere?).
> 
> 
> I'm still interested in what benefit we gain from a centralised
> edk2-staging repository though, over the normal process of contributors
> just pushing their work to github repositories and submitting PRs.
> 
> --
> dwmw2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

On Tue, 2016-03-15 at 00:16 +, Kinney, Michael D wrote:
> 
> 
> Can you provide some revised text you would like to see in step 6.
> 
> I agree that we need to use the tools in ways that help make this easy, 
> prevent
> errors, and preserve history.  Given that step 6 describes promoting a 
> feature 
> from edk2-staging repo to edk2 repo, what set of git operations you would 
> recommend?

Literally, 'git pull'. So my change in patch form would be:

@@
 6) Process to promote an edk2-staging branch to edk2 trunk
 a) Request sent to edk2-devel that describes the feature, design, 
testing, etc.
 b) Stewards evaluate request and determine if the feature meets edk2 
criteria.
-c) If approved, use edk2 patch review/commit process on edk2-devel 
mailing list
+    c) If approved, use 'git pull' to merge the branch into edk2 master, 
adding
+   any final 'Reviewed-by:' tags to the merge commit as appropriate.
 d) Remove feature branch from edk2-staging (maybe archived 
elsewhere?). 


I'm still interested in what benefit we gain from a centralised
edk2-staging repository though, over the normal process of contributors
just pushing their work to github repositories and submitting PRs.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Kinney, Michael D]

David,

Can you provide some revised text you would like to see in step 6.

I agree that we need to use the tools in ways that help make this easy, prevent
errors, and preserve history.  Given that step 6 describes promoting a feature 
from edk2-staging repo to edk2 repo, what set of git operations you would 
recommend?

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
> Woodhouse
> Sent: Monday, March 14, 2016 3:48 PM
> To: Mangefeste, Tony ; edk2-devel@lists.01.org 
>  de...@ml01.01.org>
> Subject: Re: [edk2] EDK2 Staging Repository 2nd Draft
> 
> On Mon, 2016-03-14 at 22:38 +, Mangefeste, Tony wrote:
> > Yes there is work that is substantial enough.
> 
> I'm not sure what that's an answer to; you didn't leave a specific part
> of my email above it as context.
> 
> I was saying that *when* work is substantial enough to warrant such
> staging, that is *precisely* the kind of work where we want to be using
> the tools properly and *pull* it in rather than rebasing it.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

On Mon, 2016-03-14 at 22:38 +, Mangefeste, Tony wrote:
> Yes there is work that is substantial enough.

I'm not sure what that's an answer to; you didn't leave a specific part
of my email above it as context.

I was saying that *when* work is substantial enough to warrant such
staging, that is *precisely* the kind of work where we want to be using
the tools properly and *pull* it in rather than rebasing it.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Mangefeste, Tony]

Yes there is work that is substantial enough.

-- Original message--
From: David Woodhouse
Date: Mon, Mar 14, 2016 3:19 PM
To: Mangefeste, Tony;edk2-devel@lists.01.org;
Cc:
Subject:Re: [edk2] EDK2 Staging Repository 2nd Draft


On Sat, 2016-03-12 at 00:25 +, Mangefeste, Tony wrote:> > 
6) Process to promote an edk2-staging branch to edk2 trunk> a) Request 
sent to edk2-devel that describes the feature, design, testing, etc.> 
b) Stewards evaluate request and determine if the feature meets edk2 criteria.> 
c) If approved, use edk2 patch review/commit process on edk2-devel 
mailing list> d) Remove feature branch from edk2-staging (maybe 
archived elsewhere?). Anything which is substantial enough to warrant this kind 
of 'staging'definitely wants to be *pulled* into the main tree, rather 
thanrebasing it onto the current master, losing accurate history 
andinvalidating the testing that's been done.The 'Reviewed-by' 
and similar tags could be collected by the submitterand added in their own tree 
(leaving them in control of whether theyrebase, and responsible for subsequent 
retesting everything).Perhaps better still, the Reviewed-by: could be included 
in 
 the *merge*commit.Either way, let's not further entrench incorrect rebase 
behaviour.-- David WoodhouseOpen Source Technology 
centredavid.woodho...@intel.com  
Intel Corporation
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

On Sat, 2016-03-12 at 00:25 +, Mangefeste, Tony wrote:
> 
> 6) Process to promote an edk2-staging branch to edk2 trunk
> a) Request sent to edk2-devel that describes the feature, design, 
> testing, etc.
> b) Stewards evaluate request and determine if the feature meets edk2 
> criteria.
> c) If approved, use edk2 patch review/commit process on edk2-devel 
> mailing list
> d) Remove feature branch from edk2-staging (maybe archived 
> elsewhere?). 

Anything which is substantial enough to warrant this kind of 'staging'
definitely wants to be *pulled* into the main tree, rather than
rebasing it onto the current master, losing accurate history and
invalidating the testing that's been done.

The 'Reviewed-by' and similar tags could be collected by the submitter
and added in their own tree (leaving them in control of whether they
rebase, and responsible for subsequent retesting everything).

Perhaps better still, the Reviewed-by: could be included in the *merge*
commit.

Either way, let's not further entrench incorrect rebase behaviour.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

On Sat, 2016-03-12 at 00:25 +, Mangefeste, Tony wrote:
> 
> Problem statement
> =
> Need place on tianocore.org where new features that are not ready for
> product integration can be checked in for evaluation by the EDK II
> community prior to adding to the edk2 trunk.  This serves several
> purposes:
> 
> * Encourage source code to be shared earlier in the development
> process
> * Allow source code to be shared that does not yet meet all edk2
> required quality criteria
> * Allow source code to be shared so the EDK II community can help
> finish and validate new features
> * Provide a location to hold new features until they are deemed ready
> for product integration
> * Provide a location to hold new features until there is a natural
> point in edk2 release cycle to fully validate the new feature.
> * Not intended to be used for bug fixes.
> * Not intended to be used for small, simple, or low risk features.

Surely all of this is covered by the normal process of contributors
publishing their work in github repositories of their own?

Why do we need to do something different?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Mangefeste, Tony]

The ideal is to align to the edk2 project.  The next steps that we're working 
on with Tianocore/edk2 is to define how features bubble up from the main trunk 
up to the edk2, and ultimately the udk.

We haven't defined or started that discussion yet.  I'll plan to roll out more 
details in the coming weeks.  As we get our first staging feature, we can see 
how it plays out.

By the way, the staging area can be used for feature development, it does not 
imply that all feature development is done in the staging branch.  This is just 
a way to provide an isolated environment for design, validation before merging 
to the edk2 trunk (or udk I suppose).

-Original Message-
From: Gao, Liming 
Sent: Monday, March 14, 2016 8:36 AM
To: Mangefeste, Tony ; edk2-devel@lists.01.org 

Subject: RE: EDK2 Staging Repository 2nd Draft

On edk2-staging, do we need to regularly sync edk2 change into edk2-staging and 
keep edk2-staging as the mirror of ed2 project? Or align it to edk2 project 
only when new udk release is made? I think it will be fine to let edk2-staging 
align to edk2 udk release, not as edk2 mirror. New feature can be developed 
based on edk2 udk branch, not edk2 master. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Mangefeste, Tony
Sent: Saturday, March 12, 2016 8:26 AM
To: edk2-devel@lists.01.org 
Subject: [edk2] EDK2 Staging Repository 2nd Draft
Importance: High

After collecting numerous feedback, here's a clean 2nd proposal for review.  
* Message format clean
* Approval process updates for stanging -> EDK2 trunk
* The intention of the staging branch is _not_ to work on features that grow to 
unreasonable sizes.  It is to manage features in an isolated environment that 
requires collaboration and testing by the community.  The stewards will ensure 
that any features that are developed, tested within the staging area are 
managed closely, and prevent unmanageable merges.
* Other minor fixes, changes...

Let's drive for closure on this by Tuesday, March 15, 2016.  If anyone else 
speaks up and needs more time, please speak up, right away.



=
edk2-staging Proposal V2
=

Problem statement
=
Need place on tianocore.org where new features that are not ready for product 
integration can be checked in for evaluation by the EDK II community prior to 
adding to the edk2 trunk.  This serves several purposes:

* Encourage source code to be shared earlier in the development process
* Allow source code to be shared that does not yet meet all edk2 required 
quality criteria
* Allow source code to be shared so the EDK II community can help finish and 
validate new features
* Provide a location to hold new features until they are deemed ready for 
product integration
* Provide a location to hold new features until there is a natural point in 
edk2 release cycle to fully validate the new feature.
* Not intended to be used for bug fixes.
* Not intended to be used for small, simple, or low risk features.

Proposal

1) Create a new repo called edk2-staging
a) edk2-staging is a fork of edk
b) edk2-staging/master tracks edk2/master

2) All edk2-staging discussions use the existing edk2-devel mailing list for 
design/patch/test.
Use the following style for discussion of a specific feature branch in 
edk2-staging repo.

[staging/branch]: Subject

3) All commits to edk2-staging must follow same edk2 rules (e.g. Tiano 
Contributor's Agreement)

4) Process to add a new feature to edk2-staging
a) Request to create a new edk2-staging feature branch sent to 
edk2-devel
Request should include feature summary, owners, timeline, and quality 
criteria to add to edk2.
If Request is a platform or package specific feature, pre-approval for 
edk2 trunk promotion may be requested here.
b) Branch request and branch name must be approved by stewards
c) Branch maintainer creates edk2-staging feature branch
d) Branch maintainer creates Readme.MD in root of feature branch with 
summary, owners, timeline, links to related materials.
e) Branch maintainer is responsible for making sure feature is 
frequently synced to edk2/master

 NOTE: Feature branch may initially use a stable edk2 tag.  As feature 
stabilizes, syncs to edk2/master can begin.

5) Process to update sources in feature branch
a) Patch email send to edk2-devel
b) Commit message subject format

[staging/branch PATCH]: Package/Module: Subject

c) Use same edk2-devel review process 
d) If pass review, then maintainer commits change to edk2-staging 
feature branch

NOTE: win32 binaries are not automatically generated if a feature 
branch includes BaseTools source changes.

6) Process to promote an edk2-staging branch to edk2 trunk
a) Request sent to edk2-devel that describes the feature, design, 

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Gao, Liming]

On edk2-staging, do we need to regularly sync edk2 change into edk2-staging and 
keep edk2-staging as the mirror of ed2 project? Or align it to edk2 project 
only when new udk release is made? I think it will be fine to let edk2-staging 
align to edk2 udk release, not as edk2 mirror. New feature can be developed 
based on edk2 udk branch, not edk2 master. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Mangefeste, Tony
Sent: Saturday, March 12, 2016 8:26 AM
To: edk2-devel@lists.01.org 
Subject: [edk2] EDK2 Staging Repository 2nd Draft
Importance: High

After collecting numerous feedback, here's a clean 2nd proposal for review.  
* Message format clean
* Approval process updates for stanging -> EDK2 trunk
* The intention of the staging branch is _not_ to work on features that grow to 
unreasonable sizes.  It is to manage features in an isolated environment that 
requires collaboration and testing by the community.  The stewards will ensure 
that any features that are developed, tested within the staging area are 
managed closely, and prevent unmanageable merges.
* Other minor fixes, changes...

Let's drive for closure on this by Tuesday, March 15, 2016.  If anyone else 
speaks up and needs more time, please speak up, right away.



=
edk2-staging Proposal V2
=

Problem statement
=
Need place on tianocore.org where new features that are not ready for product 
integration can be checked in for evaluation by the EDK II community prior to 
adding to the edk2 trunk.  This serves several purposes:

* Encourage source code to be shared earlier in the development process
* Allow source code to be shared that does not yet meet all edk2 required 
quality criteria
* Allow source code to be shared so the EDK II community can help finish and 
validate new features
* Provide a location to hold new features until they are deemed ready for 
product integration
* Provide a location to hold new features until there is a natural point in 
edk2 release cycle to fully validate the new feature.
* Not intended to be used for bug fixes.
* Not intended to be used for small, simple, or low risk features.

Proposal

1) Create a new repo called edk2-staging
a) edk2-staging is a fork of edk
b) edk2-staging/master tracks edk2/master

2) All edk2-staging discussions use the existing edk2-devel mailing list for 
design/patch/test.
Use the following style for discussion of a specific feature branch in 
edk2-staging repo.

[staging/branch]: Subject

3) All commits to edk2-staging must follow same edk2 rules (e.g. Tiano 
Contributor's Agreement)

4) Process to add a new feature to edk2-staging
a) Request to create a new edk2-staging feature branch sent to 
edk2-devel
Request should include feature summary, owners, timeline, and quality 
criteria to add to edk2.
If Request is a platform or package specific feature, pre-approval for 
edk2 trunk promotion may be requested here.
b) Branch request and branch name must be approved by stewards
c) Branch maintainer creates edk2-staging feature branch
d) Branch maintainer creates Readme.MD in root of feature branch with 
summary, owners, timeline, links to related materials.
e) Branch maintainer is responsible for making sure feature is 
frequently synced to edk2/master

 NOTE: Feature branch may initially use a stable edk2 tag.  As feature 
stabilizes, syncs to edk2/master can begin.

5) Process to update sources in feature branch
a) Patch email send to edk2-devel
b) Commit message subject format

[staging/branch PATCH]: Package/Module: Subject

c) Use same edk2-devel review process 
d) If pass review, then maintainer commits change to edk2-staging 
feature branch

NOTE: win32 binaries are not automatically generated if a feature 
branch includes BaseTools source changes.

6) Process to promote an edk2-staging branch to edk2 trunk
a) Request sent to edk2-devel that describes the feature, design, 
testing, etc.
b) Stewards evaluate request and determine if the feature meets edk2 
criteria.
c) If approved, use edk2 patch review/commit process on edk2-devel 
mailing list
d) Remove feature branch from edk2-staging (maybe archived elsewhere?). 

7) Process to remove an edk2-staging branch
a) Stewards periodically review of feature branches in edk2-staging 
(once a quarter?)
b) If no activity for extended period of time and feature is no longer 
deemed a candidate for edk2 then stewards send email to edk2-devel to request 
deletion of feature branch.  
c) If no objections from EDK II community, then feature branch is 
deleted (maybe archived elsewhere?).

8) Process to evaluate a feature in edk2-staging
a) Clone edk2
b) Create local branch with optional platfor

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Mangefeste, Tony]

That's a good idea.

-- Original message--
From: Justen, Jordan L
Date: Fri, Mar 11, 2016 5:34 PM
To: Mangefeste, Tony;edk2-devel@lists.01.org;
Cc:
Subject:Re: [edk2] EDK2 Staging Repository 2nd Draft

On 2016-03-11 16:25:39, Mangefeste, Tony wrote:
>
> 6) Process to promote an edk2-staging branch to edk2 trunk
> a) Request sent to edk2-devel that describes the feature, design, 
> testing, etc.
> b) Stewards evaluate request and determine if the feature meets edk2 
> criteria.
> c) If approved, use edk2 patch review/commit process on edk2-devel 
> mailing list
> d) Remove feature branch from edk2-staging (maybe archived 
> elsewhere?).
>
> 7) Process to remove an edk2-staging branch
> a) Stewards periodically review of feature branches in edk2-staging 
> (once a quarter?)
> b) If no activity for extended period of time and feature is no 
> longer deemed a candidate for edk2 then stewards send email to edk2-devel to 
> request deletion of feature branch.
> c) If no objections from EDK II community, then feature branch is 
> deleted (maybe archived elsewhere?).

I recommend we move all committed and abandoned staging branches to:

https://github.com/tianocore/edk2-archive

Archiving the committed patchsets might not be useful though.

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository 2nd Draft

[Jordan Justen]

On 2016-03-11 16:25:39, Mangefeste, Tony wrote:
> 
> 6) Process to promote an edk2-staging branch to edk2 trunk
> a) Request sent to edk2-devel that describes the feature, design, 
> testing, etc.
> b) Stewards evaluate request and determine if the feature meets edk2 
> criteria.
> c) If approved, use edk2 patch review/commit process on edk2-devel 
> mailing list
> d) Remove feature branch from edk2-staging (maybe archived 
> elsewhere?). 
> 
> 7) Process to remove an edk2-staging branch
> a) Stewards periodically review of feature branches in edk2-staging 
> (once a quarter?)
> b) If no activity for extended period of time and feature is no 
> longer deemed a candidate for edk2 then stewards send email to edk2-devel to 
> request deletion of feature branch.  
> c) If no objections from EDK II community, then feature branch is 
> deleted (maybe archived elsewhere?).

I recommend we move all committed and abandoned staging branches to:

https://github.com/tianocore/edk2-archive

Archiving the committed patchsets might not be useful though.

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel