David, Yes. Use of developer github forks is supported. I had summarized 3 development methods earlier in this thread.
1) PR emails send to edk2-devel. There is a Wiki page that details process for developers and maintainer. 2) Branch on developer owned github fork of edk2. There have been discussions on how to support a pull request. This is still under investigation. In the meantime, a link to the branch and pull request can be included in the PR emails to edk2-devel. 3) Branch on edk2-staging (Specific process being discussed in this thread) In order to properly capture your feedback, I think a higher level overview Wiki page on the development methods available needs to be written up with edk2-staging just being one of the 3 methods (and likely most rare). I will work with Tony to get Wiki pages updated with all this information. Will this address your concerns? Mike > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of David > Woodhouse > Sent: Thursday, March 17, 2016 1:39 PM > To: Kinney, Michael D <[email protected]>; Mangefeste, Tony > <[email protected]>; [email protected] <[email protected]> > Subject: Re: [edk2] EDK2 Staging Proposal 3rd draft, final? > > I could have sworn I'd responded to this last night, but it was late, > and I see no evidence of such in my outbox or on the list. Apologies if > I'm repeating myself... > > On Thu, 2016-03-17 at 00:15 +0000, Kinney, Michael D wrote: > > 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). > > This seems to me to be a false dichotomy. You've left out the third > option, which is just to use the tools as they were designed to be > used. > > Let people set up their submissions in github repositories of their own > (which works for groups as well as individuals, and allows loosely- > formed collaborative groups as well as more formal projects). And you > can already track their submissions at > https://github.com/tianocore/edk2/pulls > > > 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. > > Developer-owned github repositories are suitable for larger submissions > too, surely? (With associated discussion on the mailing list which was > always part of the plan, of course. I'm not suggesting that it should > necessarily happen *only* in the github PR format.) > > -- > dwmw2 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
