David, Jordan asked a similar question about adding a 'staging' directory or 'staging' branches to the edk2 repo. If you look at the edk2 repo today, it has master and the supported UDK* branches. In the transition from SVN -> GIT, the old tags were removed and archived.
The reason for suggesting a new edk2-staging repo is to keep content that is not ready for products to be clearly separated. We do not want anyone to pick up any of the staging content and put it into shipping FW images. There was also a minor concern about the size of the edk2 repo, but it was shown that this is not really an issue at this time. So the choice here is a set of staging feature branches in the current edk2 repo with clear communication that none of them are product ready. Or a new edk2-staging repo with feature branches (current proposal). I think a process to create/merge/remove feature branches in the tianocore.org repos is required because we really do not want too many branches. If the feature being developed is smaller in scope, developer owned github branches or email PRs should be sufficient. Thanks, Mike > -----Original Message----- > From: David Woodhouse [mailto:[email protected]] > Sent: Wednesday, March 16, 2016 3:23 PM > To: Kinney, Michael D <[email protected]>; Mangefeste, Tony > <[email protected]>; [email protected] <[email protected]> > Subject: Re: [edk2] EDK2 Staging Proposal 3rd draft, final? > > On Wed, 2016-03-16 at 22:05 +0000, Kinney, Michael D wrote: > > > > I responded to an earlier email: > > Ah, apologies — it wasn't clear this was intended as an answer to that > question. This is one of those examples with the common email behaviour > of placing the response below a carefully-selected citation would have > helped a great deal, FWIW. > > > 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). > > So the answer would be that it allows more than one person to > collaborate on a submission? I'm not sure we need a whole new process > document just for that, do we? It's not as if it's hard for people to > share access to their repositories, or just pull from each other's. > > ================== > > On Wed, 2016-03-16 at 15:15 -0700, Andrew Fish wrote: > > I think David's point is any github repository can be used for this, > > if I understand David's point? > > Precisely so. > > > So the only value to branches is an official place for them to live? > > Thus a way they can be discovered. > > Can't they already be discovered at > https://github.com/tianocore/edk2/pulls ? > > This is the normal workflow. People (individuals or otherwise) put > together some work, discussion happens (and is archived and > discoverable) in a pull request. New versions of the tree can be > submitted to the PR at any time. > > We don't need to invent anything new and different, just to allow more > than one person to work together on a submission. > > -- > David Woodhouse Open Source Technology Centre > [email protected] Intel Corporation _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
