> -----Original Message-----
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, March 10, 2016 2:03 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Mangefeste, Tony <tony.mangefe...@intel.com>;
> edk2-
> de...@lists.01.org <edk2-de...@ml01.01.org>
> Subject: Re: [edk2] EDK2 Staging Repository
>
> On 03/10/16 00:02, Kinney, Michael D wrote:
> > Jordan,
> >
> > Responses included below.
> >
> > Mike
> >
> >
> >
> >> -----Original Message-----
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Jordan Justen
> >> Sent: Wednesday, March 9, 2016 1:47 PM
> >> To: Mangefeste, Tony <tony.mangefe...@intel.com>; edk2-devel@lists.01.org
> >> Subject: Re: [edk2] EDK2 Staging Repository
> >>
> >> On 2016-03-09 10:53:38, Mangefeste, Tony wrote:
> >>> Below are the details of the proposal for a staging branch, please review
> >>> and
> >> comment.
> >>>
> >>> <proposal>
> >>>
> >>> 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.
> >>>
> >>
> >> I think the parts about making a central place for big feature
> >> branches seems good. I think Laszlo might have appreciated having a
> >> well defined central location for his OVMF SMM enabling branch.
> >>
> >> I think the processes around allowing the code to be merged seems too
> >> heavyweight. In the cases of big patchsets, it can be burdensome
> >> enough just to get code review. To insert another process step (and
> >> set of approvers) to actually merge the feature seems perhaps
> >> unneccesary.
> >>
> >>> Proposal
> >>> ========
> >>> 1) Create a new repo called edk2-staging
> >>> a) edk2-staging is a fork of edk
> >>> b) edk2-staging/master tracks edk2/master
> >>>
> >>
> >> For branches maintained by package maintainers, could we have them
> >> under the edk2 repo and named staging/*?
> >
> > Do you mean a directory in the edk2 repo called staging? I did think about
> > this
> option,
> > but I am concerned about code that is not ready for product integration
> > being in the
> edk2
> > repo and I am also concerned about the size of the edk2 repo. Creating a
> > new repo
> that is
> > a fork of edk2 addressed both of those issues.
>
> I disagree.
>
> I have now re-read our private discussion from last year, when we were
> working on SMM (the core infrastructure and the OVMF platform enablement
> in parallel). The message ID of the root of the sub-thread is
> <564f50b9.6040...@redhat.com>, if someone on CC at that time would like
> to re-read it now.
>
> At that time, the consensus seemed to be to create a top-level Staging/
> directory, with packages under it (with their DEC files and modules).
> So, we would have:
>
> ArmVirtPkg/...
> EmulatorPkg/...
> OvmfPkg/...
> Staging/ArmVirtPkg/...
> Staging/EmulatorPkg/...
> Staging/OvmfPkg/...
>
> This matches how Linux works, and the naming makes it very clear that
> modules (drivers, applications, library instances) under Staging are
> work in progress. It is not possible to include a module from under
> Staging as an oversight.
>
> Keeping work-in-progress modules in a separate repo has a critical
> drawback: those modules will not share the commit history of the main
> edk2 repo.
The issue with a single staging directory in edk2 is that we can not work on
different features that touch the same module/lib. This is where branching
provides helps. One purpose of edk2-staging is complex features that touch
several modules, likely across multiple packages.
Maybe there are 2 concepts here. One is feature branches for active
Design/dev/test. Another is content that is functional and stable and
synced with the edk2 trunk, but has some number of "known" issues.
>
> Consider the following example: a new release or erratum of the UEFI or
> PI spec is published, and a developer contributes the implementation of
> a new feature (or bugfix) to one of the core packages: MdePkg,
> MdeModulePkg, NetworkPkg, etc. Then a platform developer would like to
> rely on this UEFI or PI change in his or her work-in-progress module. If
> that module lives outside of the main edk2 repo, it will cause a
> dependency nightmare.
I the proposal, step (4e) says the feature branch maintainer needs to
keep the feature branch synced with the edk2 trunk. The proposal uses
the term "rebase", but that may not be the right operation to track
changes from edk2 into an edk2-staging branch. Maybe it is a "merge"
operation.
Also, for some new features, we may want to use a stable tag from edk2,
so the feature development work can progress without having to track
edk2. Then as the feature matures and preparation for commit back to
edk2 begins, sync with edk2 is required.
>
> Proprietary downstreams of edk2 already manage this, but let that remain
> only their problem.
>
> For OvmfPkg and ArmVirtPkg minimally, a Staging/ directory only makes
> sense to me if it lives in the main edk2 repository, and shares its
> commit history. Staging/ doesn't stand for separate product, separate
> maintainership, separate life cycle, etc -- the sole difference with
> staging modules is that we publicly admit, "yeah these are not fully
> polished yet". There's no other difference.
>
> Size-wise, the edk2 repo is easily manageable. Here's a comparison
> between up-to-date & clean checkouts of projects I work with (note that
> the below doesn't include the .git subdirectory):
>
> $ du -s -h --apparent-size --exclude=.git \
> edk2 qemu libvirt-upstream kernel \
> | sort -h
> 69M qemu
> 147M libvirt-upstream
> 202M edk2
> 845M kernel
>
> The .git subdirectory isn't large either:
>
> $ du -s -h --apparent-size \
> {edk2,qemu,libvirt-upstream,kernel}/.git \
> | sort -h
> 174M edk2/.git
> 342M qemu/.git
> 692M libvirt-upstream/.git
> 1.3G kernel/.git
>
> If Staging/ lived in a separate repository, it would not help me, and I
> couldn't use it. It might still serve the needs of others, of course.
I agree that not every development task should use a feature branch. We
need clear criteria for using feature branches. Please feel free to
provide additional guidelines on when you think a feature branch is
required or not required.
>
> Thank you
> Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
