Re: [edk2] Task: Issue Tracking System for Tianocore

2016-02-11 Thread Laszlo Ersek 
On 02/11/16 02:52, Mangefeste, Tony wrote:
> I understand better.  My concern is if there's some sort of ongoing headcount 
> required to maintain Bugzilla.  As was stated before, if there's a 
> maintenance requirement is that a hard requirement? Or can the 
> software/system run autonomously for long periods of time without human 
> intervention*.
> 
> *I have no direct experience administering Bugzilla, just using it.

I think both Leif and Bruce (downthread) are right. I think with a
relatively low bug load, and a low concurrent user count, Bugzilla
should run mostly untended indeed.

At Red Hat though, there have been dedicated longer-term efforts by
dedicated people to optimize performance, develop features /
customizations, and fix bugs. What Leif mentioned should be stressed
however, about those orders of magnitude differences in ticket load. In
my personal account, end of 2010, start of 2011, new BZ numbers were
assigned around 640 thousand (but I worked on bugs with as low numbers
as ~450 thousand). One bug I opened last week was above 1,304 thousand.
On average, that's about 133 thousand new bugs per year, or ~2.56
thousand new bugs per week. (The growth has not been linear though, in
my impression.)

Things we shouldn't forget even in the "untended" case: security
updates, and regular database backups.

Laszlo

> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
> Sent: Wednesday, February 10, 2016 5:26 PM
> To: Mangefeste, Tony 
> Cc: Laszlo Ersek ; Ard Biesheuvel 
> ; edk2-devel@lists.01.org 
> Subject: Re: [edk2] Task: Issue Tracking System for Tianocore
> 
> On Thu, Feb 11, 2016 at 12:59:52AM +, Mangefeste, Tony wrote:
>> Do you have funding estimates you would share with me from a Linaro 
>> perspective?  Of course, it doesn't have to be shared out in this 
>> context, but if you have such data it'd be interesting to compare our 
>> resources with what is required to run Bugzilla.
> 
> Funding estimates for using Bugzilla? I mean, I could ask but I think
> the answer would basically be "a machine running Linux".
> 
> I would expect the ticket load for Tianocore to be an order of
> magnitude below what Linaro is seeing (across toolchains, Android,
> kernel, OpenEmbedded, ...), and a couple of orders of magnitude below
> what Red Hat are seeing.
> 
> /
> Leif
> 
>> -Original Message-
>> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>> Sent: Wednesday, February 10, 2016 4:53 PM
>> To: Laszlo Ersek 
>> Cc: Ard Biesheuvel ; Mangefeste, Tony 
>> ; edk2-devel@lists.01.org 
>> 
>> Subject: Re: [edk2] Task: Issue Tracking System for Tianocore
>>
>> On Thu, Feb 11, 2016 at 12:08:16AM +0100, Laszlo Ersek wrote:
>>> On 02/10/16 23:59, Mangefeste, Tony wrote:
 I've gone down the track of using Bugzilla as well.  Aside from 
 the massive list of pros listed below, gathering any other 
 preference is welcomed.  I have used Bugzilla, but never been a maintainer 
 on it.
 We do have some resources lined up for management of Bugzilla, if 
 needed, so that's not a barrier.  Of course, the devil's in the 
 details.

 So in short, Bugzilla is top of my mind right now.  I'm looking at 
 other OSS projects and seeing what they use.  If anyone here sees 
 one not listed below or has an opinion that they care to express 
 please do so.  On the mobility view, I'll try to play around with 
 that and see how it looks on my mobile devices.

 Welcome to real-time decision making, thought process spewing.
>>>
>>> I recall that Linaro uses JIRA:
>>> https://cards.linaro.org/
>>
>> Retired.
>>
>>> Oh wait, there seems to be a new URL (still JIRA):
>>> https://projects.linaro.org
>>
>> Yup.
>>
>>> I am (was?) subscribed to a minimal set of CARDs only, in the first 
>>> system; I don't have any real experience with JIRA. Ard, Leif, can 
>>> you please share your thoughts?
>>
>> We use Jira for project management.
>> https://bugs.linaro.org/ is bugzilla.
>>
>> Strongly support bugzilla over both Jira and the github one.
>>
>> Regards,
>>
>> Leif

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

Re: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation issues with ICC.

2016-02-11 Thread Kinney, Michael D 
Marvin,

It is ready to be checked in.  I can take care of that tomorrow.

Mike

From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
Sent: Thursday, February 11, 2016 11:20 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D 
Subject: RE: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation issues 
with ICC.

Dear Mike,

Am I supposed to perform any changes to this patch or is it considered ready 
for merge?

> To: michael.d.kin...@intel.com; 
> marvin.haeu...@outlook.com; 
> edk2-devel@lists.01.org; 
> michael.d.kin...@intel.com
> From: jordan.l.jus...@intel.com
> Subject: RE: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation issues 
> with ICC.
> Date: Sat, 30 Jan 2016 20:23:53 -0800
>
> On 2016-01-30 19:44:26, Kinney, Michael D wrote:
> > Jordan,
> >
> > Good idea, but ECB compiler does not define __INTEL_COMPILER.
> >
>
> Ok. You can add my r-b for the patch:
>
> Reviewed-by: Jordan Justen 
> >
>
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > > Jordan Justen
> > > Sent: Saturday, January 30, 2016 5:53 PM
> > > To: Kinney, Michael D 
> > > >; Marvin 
> > > Haeuser
> > > >; 
> > > edk2-devel@lists.01.org; Kinney, Michael D
> > > >
> > > Subject: Re: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation 
> > > issues with ICC.
> > >
> > > On 2016-01-30 16:42:55, Kinney, Michael D wrote:
> > > > Reviewed-by: Michael Kinney 
> > > > >
> > > >
> > >
> > > Mike, do you think the EBC compiler also defines __INTEL_COMPILER?
> > >
> > > If so, then this might work:
> > >
> > > #if defined(_MSC_EXTENSIONS) && !defined (__INTEL_COMPILER)
> > >
> > > -Jordan
> > >
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > > > > Of Marvin
> > > Haeuser
> > > > > Sent: Friday, January 29, 2016 3:56 PM
> > > > > To: edk2-devel@lists.01.org
> > > > > Subject: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation 
> > > > > issues with ICC.
> > > > >
> > > > > Recent versions of the Intel C compiler define the _MSC_EXTENSIONS
> > > > > constant. Base.h checks if this constant is defined to decide whether
> > > > > or not to use a pragma intrinsic, which is unsupported by the latest
> > > > > version of the Intel C compiler. Thus the check has been modified to
> > > > > only pass in the case __INTEL_COMPILER is not defined.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > > Signed-off-by: Marvin Haeuser 
> > > > > >
> > > > > ---
> > > > > MdePkg/Include/Base.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> > > > > index 85ed34f..2baf9a7 100644
> > > > > --- a/MdePkg/Include/Base.h
> > > > > +++ b/MdePkg/Include/Base.h
> > > > > @@ -1022,7 +1022,7 @@ typedef UINTN RETURN_STATUS;
> > > > > #define SIGNATURE_64(A, B, C, D, E, F, G, H) \
> > > > > (SIGNATURE_32 (A, B, C, D) | ((UINT64) (SIGNATURE_32 (E, F, G, H)) << 
> > > > > 32))
> > > > >
> > > > > -#if defined(_MSC_EXTENSIONS) && !defined (MDE_CPU_EBC)
> > > > > +#if defined(_MSC_EXTENSIONS) && !defined (__INTEL_COMPILER) && 
> > > > > !defined
> > > (MDE_CPU_EBC)
> > > > > #pragma intrinsic(_ReturnAddress)
> > > > > /**
> > > > > Get the return address of the calling funcation.
> > > > > --
> > > > > 2.6.2.windows.1
> > > > >
> > > > > ___
> > > > > 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
> > > ___
> > > 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] git history breakage [was: ShellPkg: ShellFileHandleReadLine must return UCS2 lines]

2016-02-11 Thread Laszlo Ersek 
On 02/11/16 17:16, Bruce Cran wrote:
> On 2/11/16 6:34 AM, Laszlo Ersek wrote:
> 
>> I think we managed to reconstruct what happened here. I recommend that
>> you open the git history in gitk, so you can jump on the commits I'm
>> about to mention.
> 
> By the way, you can also see the divergence and merging in the branching
> view at https://edk2.bluestop.org/diffusion/EDK/history/master/ .
> 

Interesting! Can you make this auth-less?

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

Re: [edk2] USB OHCI

2016-02-11 Thread Kinney, Michael D 
Samer,

Good question.  I have been considering it.  I need to review that code to make 
sure it works
with other OHCI controllers on other platforms and that the register 
definitions used match 
the OHCI spec.  If we can get through a couple of those steps, I think it is a 
candidate to move
to a common package.

If you have some platforms you can test it on, then please do and let us know 
the results.

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud,
> Samer
> Sent: Thursday, February 11, 2016 10:19 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D 
> Subject: [edk2] USB OHCI
> 
> Mike,
> 
> Is there any reason why we can't move the OHCI drivers from:
> QuarkSocPkg\QuarkSouthCluster\Usb\Ohci to be with the rest of the USB stack 
> at:
> MdeModulePkg\Bus\Pci? The code seems to be generic with no Quark SOC 
> dependencies,
> correct? The Suppoted() function seem to imply binding to any OHCI Class 
> controller:
> 
>   //
>   // Test whether the controller belongs to OHCI type
>   //
>   if ((UsbClassCReg.BaseCode != PCI_CLASS_SERIAL) ||
>   (UsbClassCReg.SubClassCode != PCI_CLASS_SERIAL_USB) ||
>   (UsbClassCReg.ProgInterface != PCI_IF_OHCI)
>   ) {
> 
> Status = EFI_UNSUPPORTED;
>   }
> 
> Thanks,
> --Samer
> 
> ___
> 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] [PATCH] MdePkg: Update Base.h to fix compilation issues with ICC.

2016-02-11 Thread Marvin Häuser 
Dear Mike,
 
Am I supposed to perform any changes to this patch or is it considered ready 
for merge?
 
> To: michael.d.kin...@intel.com; marvin.haeu...@outlook.com; 
> edk2-devel@lists.01.org; michael.d.kin...@intel.com
> From: jordan.l.jus...@intel.com
> Subject: RE: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation issues 
> with ICC.
> Date: Sat, 30 Jan 2016 20:23:53 -0800
> 
> On 2016-01-30 19:44:26, Kinney, Michael D wrote:
> > Jordan,
> > 
> > Good idea, but ECB compiler does not define __INTEL_COMPILER.
> > 
> 
> Ok. You can add my r-b for the patch:
> 
> Reviewed-by: Jordan Justen 
> 
> > 
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > > Jordan Justen
> > > Sent: Saturday, January 30, 2016 5:53 PM
> > > To: Kinney, Michael D ; Marvin Haeuser
> > > ; edk2-devel@lists.01.org; Kinney, Michael D
> > > 
> > > Subject: Re: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation 
> > > issues with ICC.
> > > 
> > > On 2016-01-30 16:42:55, Kinney, Michael D wrote:
> > > > Reviewed-by: Michael Kinney 
> > > >
> > > 
> > > Mike, do you think the EBC compiler also defines __INTEL_COMPILER?
> > > 
> > > If so, then this might work:
> > > 
> > > #if defined(_MSC_EXTENSIONS) && !defined (__INTEL_COMPILER)
> > > 
> > > -Jordan
> > > 
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > > > > Of Marvin
> > > Haeuser
> > > > > Sent: Friday, January 29, 2016 3:56 PM
> > > > > To: edk2-devel@lists.01.org
> > > > > Subject: [edk2] [PATCH] MdePkg: Update Base.h to fix compilation 
> > > > > issues with ICC.
> > > > >
> > > > > Recent versions of the Intel C compiler define the _MSC_EXTENSIONS
> > > > > constant. Base.h checks if this constant is defined to decide whether
> > > > > or not to use a pragma intrinsic, which is unsupported by the latest
> > > > > version of the Intel C compiler. Thus the check has been modified to
> > > > > only pass in the case __INTEL_COMPILER is not defined.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > > Signed-off-by: Marvin Haeuser 
> > > > > ---
> > > > >  MdePkg/Include/Base.h | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> > > > > index 85ed34f..2baf9a7 100644
> > > > > --- a/MdePkg/Include/Base.h
> > > > > +++ b/MdePkg/Include/Base.h
> > > > > @@ -1022,7 +1022,7 @@ typedef UINTN RETURN_STATUS;
> > > > >  #define SIGNATURE_64(A, B, C, D, E, F, G, H) \
> > > > >  (SIGNATURE_32 (A, B, C, D) | ((UINT64) (SIGNATURE_32 (E, F, G, 
> > > > > H)) << 32))
> > > > >
> > > > > -#if defined(_MSC_EXTENSIONS) && !defined (MDE_CPU_EBC)
> > > > > +#if defined(_MSC_EXTENSIONS) && !defined (__INTEL_COMPILER) && 
> > > > > !defined
> > > (MDE_CPU_EBC)
> > > > >#pragma intrinsic(_ReturnAddress)
> > > > >/**
> > > > >  Get the return address of the calling funcation.
> > > > > --
> > > > > 2.6.2.windows.1
> > > > >
> > > > > ___
> > > > > 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
> > > ___
> > > 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] [PATCH] ShellPkg: ShellFileHandleReadLine must return UCS2 lines

2016-02-11 Thread Laszlo Ersek 
On 02/10/16 20:37, Ryan Harkin wrote:
> On 10 February 2016 at 14:16, Ryan Harkin  wrote:
>> Hi Jim,
>>
>> Thanks for the quick fix!  It works for me on ARM Juno R0, R1 and R2
>> and Versatile Express TC2.
>>
>> On 10 February 2016 at 13:45,   wrote:
>>> ShellPkg: ShellFileHandleReadLine must return UCS2 lines.
>>>
>>> An earlier change had this function returning the type of lines that were 
>>> in the file being read (ASCII or UCS2).  The way it is used, UCS2 output is 
>>> expected, even when the file being read is ASCII. This change restores that 
>>> behavior and documents it.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Jim Dailey
>> ^^ your email address is missing from your sign-off, I think it's
>> mandatory, but don't hold me to that.
>>
>> I haven't had chance to read and understand the code, but I can at
>> least provide:
>>
>> Tested-by: Ryan Harkin 
>>
> 
> I've just updated to the tip of tianocore and I see the same problem
> as before.  I have made sure I'm running the binary I built from this
> point in the tree, after the fix has been merged:
> 
> 62989e0  2016-02-10  Merge branch 'master' of
> https://github.com/tianocore/edk2 [Jaben Carsey]
> 
> And it doesn't work.  So I went back to this commit:
> 
> d2a0d2e  2016-02-08  ShellPkg: Fix ASCII and UNICODE file pipes.
>  [jaben carsey]
> 
> And applied the patch myself from the original email in this thread
> and it works for me.
> 
> So I've looked again.  If I checkout the tree right where the fix went in:
> 
> 2dda8a1  2016-02-10  ShellPkg: ShellFileHandleReadLine must return
> UCS2 lines.  [Jim Dailey]
> 
> It also works.
> 
> If I then checkout the tree at the next commit, a strange merge commit:
> 
> 3a01358  2016-02-10  Merge branch 'master' of
> https://github.com/tianocore/edk2 [Jaben Carsey]
> 
> Then part of the fix vanishes and the code no longer works.
> 
> If I do a "git show -1 -m 3a01358", then I can see that the merge
> commit does indeed appear to add some of the code back.
> 
> A further merge commit in the tree:
> 
> 62989e0  2016-02-10  Merge branch 'master' of
> https://github.com/tianocore/edk2 [Jaben Carsey]
> 
> Has loads of other funky stuff in it and it adds part of the change
> back, but only the comment part, the code code hunk that fixes my
> problem.
> 
> Whilst I was surprised to see these merge commits in the tree in the
> first place, I didn't think too much about it.  But now I'm seeing the
> diffs they are introducing, I'm either going mad or I'm getting
> worried about the workflow in the tree :(

You should be getting worried about the workflow. The forking and the
merges were unintended. It's growing pains after the move to git.

I'll do my best to remedy the damage.

Thanks
Laszlo

> 
> Can someone have a look into the tree and please confirm either that
> I've lost the plot or that something strange has happened?
> 
>> Thanks,
>> Ryan.
>>
>>> ---
>>> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
>>> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
>>> index 4b53c70..abff0d3 100644
>>> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
>>> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
>>> @@ -4084,9 +4084,20 @@ ShellFileHandleReturnLine(
>>>If the position upon start is 0, then the Ascii Boolean will be set.  
>>> This should be
>>>maintained and not changed for all operations with the same file.
>>>
>>> +  NOTE: LINES THAT ARE RETURNED BY THIS FUNCTION ARE UCS2, EVEN IF THE 
>>> FILE BEING READ
>>> +IS IN ASCII FORMAT.
>>> +
>>>@param[in]   HandleSHELL_FILE_HANDLE to read from.
>>> -  @param[in, out]  BufferThe pointer to buffer to read into.
>>> -  @param[in, out]  Size  The pointer to number of bytes in Buffer.
>>> +  @param[in, out]  BufferThe pointer to buffer to read into. If 
>>> this function
>>> + returns EFI_SUCCESS, then on output 
>>> Buffer will
>>> + contain a UCS2 string, even if the file 
>>> being
>>> + read is ASCII.
>>> +  @param[in, out]  Size  On input, pointer to number of bytes in 
>>> Buffer.
>>> + On output, unchanged unless Buffer is too 
>>> small
>>> + to contain the next line of the file. In 
>>> that
>>> + case Size is set to the number of bytes 
>>> needed
>>> + to hold the next line of the file (as a 
>>> UCS2
>>> + string, even if it is an ASCII file).
>>>@param[in]   Truncate  If the buffer is large enough, this has 
>>> no effect.
>>>   If the buffer is is too small and 
>>> Truncate is TRUE,
>>>   the line will be truncated.
>>> @@ -4165,43 +4176,27 @@

Re: [edk2] GenericBdsLib equivalent of 'BdsStartEfiApplication'

2016-02-11 Thread Leif Lindholm 
On Wed, Feb 10, 2016 at 05:33:26PM +0100, Michael Zimmermann wrote:
> Hi,
> 
> I'm trying to switch from ARM's BdsLib to Intel's generic once.
> the only function that's left is 'BdsStartEfiApplication'. apparently the
> generic variant only allows booting via bootoptions.
> So, do we plan to move these functions out of ARM's BdsLib or is there
> another way?

What other methods are you looking for?
Android Fastboot?

A better way would be to update that module to use the built-in kernel
stub loader rather than the LinuxLoader module.

/
Leif

> to make it easier for you, this is the function's signature:
> /**
>   Start an EFI Application from a Device Path
> 
>   @param  ParentImageHandle Handle of the calling image
>   @param  DevicePathLocation of the EFI Application
> 
>   @retval EFI_SUCCESS   All drivers have been connected
>   @retval EFI_NOT_FOUND The Linux kernel Device Path has not been
> found
>   @retval EFI_OUT_OF_RESOURCES  There is not enough resource memory to
> store the matching results.
> 
> **/
> EFI_STATUS
> BdsStartEfiApplication (
>   IN EFI_HANDLE  ParentImageHandle,
>   IN EFI_DEVICE_PATH_PROTOCOL*DevicePath,
>   IN UINTN   LoadOptionsSize,
>   IN VOID*   LoadOptions
>   );
> 
> 
> 
> Michael
> ___
> 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

[edk2] git history breakage [was: ShellPkg: ShellFileHandleReadLine must return UCS2 lines]

2016-02-11 Thread Laszlo Ersek 
On 02/11/16 13:17, Laszlo Ersek wrote:
> On 02/10/16 20:37, Ryan Harkin wrote:

>> I've just updated to the tip of tianocore and I see the same problem
>> as before.  I have made sure I'm running the binary I built from this
>> point in the tree, after the fix has been merged:
>>
>> 62989e0  2016-02-10  Merge branch 'master' of
>> https://github.com/tianocore/edk2 [Jaben Carsey]
>>
>> And it doesn't work.  So I went back to this commit:
>>
>> d2a0d2e  2016-02-08  ShellPkg: Fix ASCII and UNICODE file pipes.
>>  [jaben carsey]
>>
>> And applied the patch myself from the original email in this thread
>> and it works for me.
>>
>> So I've looked again.  If I checkout the tree right where the fix went in:
>>
>> 2dda8a1  2016-02-10  ShellPkg: ShellFileHandleReadLine must return
>> UCS2 lines.  [Jim Dailey]
>>
>> It also works.
>>
>> If I then checkout the tree at the next commit, a strange merge commit:
>>
>> 3a01358  2016-02-10  Merge branch 'master' of
>> https://github.com/tianocore/edk2 [Jaben Carsey]
>>
>> Then part of the fix vanishes and the code no longer works.
>>
>> If I do a "git show -1 -m 3a01358", then I can see that the merge
>> commit does indeed appear to add some of the code back.
>>
>> A further merge commit in the tree:
>>
>> 62989e0  2016-02-10  Merge branch 'master' of
>> https://github.com/tianocore/edk2 [Jaben Carsey]
>>
>> Has loads of other funky stuff in it and it adds part of the change
>> back, but only the comment part, the code code hunk that fixes my
>> problem.
>>
>> Whilst I was surprised to see these merge commits in the tree in the
>> first place, I didn't think too much about it.  But now I'm seeing the
>> diffs they are introducing, I'm either going mad or I'm getting
>> worried about the workflow in the tree :(
> 
> You should be getting worried about the workflow. The forking and the
> merges were unintended. It's growing pains after the move to git.
> 
> I'll do my best to remedy the damage.

I think we managed to reconstruct what happened here. I recommend that
you open the git history in gitk, so you can jump on the commits I'm
about to mention.

(1) Commit 8de84d424221 ("ArmVirtPkg: implement ArmVirtQemuKernel") is
the last linear commit in the history. At that point the history was
forked into two branches. One of those is (apparently) Jaben's local
master branch, and the other is the real upstream master branch.

(2) The patch "ShellPkg: Fix ASCII and UNICODE file pipes." got applied
to *both* branches, identically. I don't know how this happened, but it
is present in what I think was Jaben's local master branch (commit
9ed21946c76e), and also on the real master branch (d2a0d2e6acea).

(3) I think Jaben didn't notice that his local master diverged from
remote master. While Leif and Ard went on to commit 12 patches in total
on top of d2a0d2e6acea, on the real master branch, Jaben committed the
patch "ShellPkg: ShellFileHandleReadLine must return UCS2 lines" to his
*diverged* local master branch (2dda8a123297).

I think Jaben then tried to push his diverged local master to upstream,
as remote master. Github must have rejected it (correctly) -- it would
have been a non-fast-forward push, losing Leif's commits.

(4) So Jaben followed the instructions on the wiki, and issued "git
pull", about two minutes after applying "ShellPkg:
ShellFileHandleReadLine must return UCS2 lines" (2dda8a123297) to his
diverged master.

Unfortunately, since his branch had diverged, and he (unknowingly)
didn't request a fetch+rebase, but a fetch+merge, this created an actual
merge commit (3a01358bdb03).

(5) Funnily enough, Jaben could *still* not push his diverged local
master to remote master, because at the exact same (6 seconds after
Jaben's merge in (4)) time Ard committed more patches to the *right*
master branch, and pushed them too (first of those is a4626006bbf8). So
github rejected Jaben's push again.

(6) Therefore Jaben pulled again, about four minutes later, which
created the *second* merge commit on his diverged local master branch
(62989e0bd2bf).

This action finally caught up with the right master branch, altough with
a non-linear history, so github permitted Jaben to push his now-unified
branch to github as the new master HEAD.

(7) Unfortunately, Jaben's *first* pull in (4) must have resulted in a
botched merge conflict resolution, which actually lost code from
2dda8a123297 -- step (3) -- on Jaben's local, diverged, master.

When Ryan pulled the tree (about two and half hours after step (6)), he
found out about this, and reported it.

(8) About two hours later, Jaben committed and pushed the hunks that
were lost in step (4) as a separate patch: 1095b432.


The tree is now in a correct state (at 1095b432). I verified it by
locally restoring the tree state to Ard's last commit on the real master
branch (bbff41c11fd374c7818c96f69c28b51c9caba619), and applying the one
patch that Jaben wanted to get in all along ("ShellPkg:
ShellFileHandleReadLine must return UCS2 lines."). This

Re: [edk2] git history breakage [was: ShellPkg: ShellFileHandleReadLine must return UCS2 lines]

2016-02-11 Thread Bruce Cran 

On 2/11/16 6:34 AM, Laszlo Ersek wrote:


I think we managed to reconstruct what happened here. I recommend that
you open the git history in gitk, so you can jump on the commits I'm
about to mention.


By the way, you can also see the divergence and merging in the branching 
view at https://edk2.bluestop.org/diffusion/EDK/history/master/ .


--
Bruce

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

Re: [edk2] github development process

2016-02-11 Thread El-Haj-Mahmoud, Samer 
Justen,

Yes I see now that there is duplicate between:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
and
https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start


And yes, step "7. Update the master branch (pull or fetch/merge" is what 
triggered me to create a pull request (that, and my incorrect assumption that 
we are using github for development process, not just to host the pull 
requests).

Thanks,
--Samer





-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com] 
Sent: Wednesday, February 10, 2016 6:32 PM
To: El-Haj-Mahmoud, Samer ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] github development process

On 2016-02-10 16:03:26, El-Haj-Mahmoud, Samer wrote:
> So I have been itching to submit patches after the transition to 
> github, when I stumbled across this. It looks like the development 
> process described in:
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
> nt-Process , does not match the process described in:
> https://raw.githubusercontent.com/tianocore/edk2/master/MdePkg/Contrib
> utions.txt
> 

There seems to be duplicated content on

https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start

And, I think the EDK-II-Development-Process version was a little older. I 
updated it to match the other one.

Before and after, I only saw one mention of 'pull':

"7. Update the master branch (pull or fetch/merge)"

Is this what caused the confusion? Or, was there something else that generated 
a pull request?

-Jordan

> I followed the process in the wiki, and ended up creating a pull 
> request for tiancore/edk for my contribution 
> (https://github.com/tianocore/edk2/pull/55). I was also going to send 
> a patch to EDK2 list (as the wiki suggests). Then I quickly realized 
> that the maintainers are still working only with e-mail patches, and 
> not pull requests, as clear from the conversations in closed/rejected 
> pull requests:
> 
> https://github.com/tianocore/edk2/pull/45
> https://github.com/tianocore/edk2/pull/51
> https://github.com/tianocore/edk2/pull/41
> etc..
> 
> 
> I have no problem of sticking with the edk2-devel e-mail patches like 
> we have been doing (all of my team from HPE contributes that way). But 
> if that is the only/proper way to submit contributions, then the wiki 
> need to be updated to drop the pull requests steps.
> 
> Thanks,
> --Samer
> 
> 
> 
> ___
> 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

[edk2] [PATCH] NetworkPkg: better sanity check on Ipv6 prefix length

2016-02-11 Thread Samer El-Haj-Mahmoud 
Fix a possible buffer overrun issue that could occur if PrefixLength >
128 . Changed == 128 to >= 128. Also remove check for Byte < 16, which
is no longer possible because of the first change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 NetworkPkg/Ip6Dxe/Ip6Icmp.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/NetworkPkg/Ip6Dxe/Ip6Icmp.c b/NetworkPkg/Ip6Dxe/Ip6Icmp.c
index db40b81..f6a9bb4 100644
--- a/NetworkPkg/Ip6Dxe/Ip6Icmp.c
+++ b/NetworkPkg/Ip6Dxe/Ip6Icmp.c
@@ -2,7 +2,8 @@
   The ICMPv6 handle routines to process the ICMPv6 control messages.
 
   Copyright (c) 2009 - 2010, Intel Corporation. All rights reserved.
-
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+  
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -479,7 +480,7 @@ Ip6GetPrefix (
 return ;
   }
 
-  if (PrefixLength == IP6_PREFIX_NUM - 1) {
+  if (PrefixLength >= IP6_PREFIX_NUM - 1) {
 return ;
   }
 
@@ -487,7 +488,7 @@ Ip6GetPrefix (
   Bit   = (UINT8) (PrefixLength % 8);
   Value = Prefix->Addr[Byte];
 
-  if ((Byte > 0) && (Byte < 16)) {
+  if (Byte > 0) {
 ZeroMem (Prefix->Addr + Byte, 16 - Byte);
   }
 
-- 
2.6.3.windows.1

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

Re: [edk2] github development process

2016-02-11 Thread Bjorge, Erik C 
Jordan and I have updated the EDK II Development Process page.  Please check 
and see if this clears up some of the issues.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Thanks,
-Erik

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Bjorge, Erik C
> Sent: Thursday, February 11, 2016 10:23 AM
> To: El-Haj-Mahmoud, Samer ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] github development process
> 
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > El-Haj-Mahmoud, Samer
> > Sent: Wednesday, February 10, 2016 4:03 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] github development process
> >
> > So I have been itching to submit patches after the transition to
> github,
> > when I stumbled across this. It looks like the development process
> > described in:
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-
> > II-Development-Process , does not match the process described in:
> >
> https://raw.githubusercontent.com/tianocore/edk2/master/MdePkg/Contribut
> > ions.txt
> >
> > I followed the process in the wiki, and ended up creating a pull
> request
> > for tiancore/edk for my contribution
> > (https://github.com/tianocore/edk2/pull/55). I was also going to send
> a
> > patch to EDK2 list (as the wiki suggests). Then I quickly realized
> that
> > the maintainers are still working only with e-mail patches, and not
> pull
> > requests, as clear from the conversations in closed/rejected pull
> > requests:
> >
> > https://github.com/tianocore/edk2/pull/45
> > https://github.com/tianocore/edk2/pull/51
> > https://github.com/tianocore/edk2/pull/41
> > etc..
> >
> >
> > I have no problem of sticking with the edk2-devel e-mail patches like
> we
> > have been doing (all of my team from HPE contributes that way). But if
> > that is the only/proper way to submit contributions, then the wiki
> need
> > to be updated to drop the pull requests steps.
> 
> I will update the Wiki as you suggest.  We were hoping to allow for at
> least some form of pull request but it looks like we are not quite ready
> for that yet.
> 
> Thanks,
> -Erik
> 
> >
> > Thanks,
> > --Samer
> >
> >
> >
> > ___
> > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] NetworkPkg: Reword PXE download message

2016-02-11 Thread Samer El-Haj-Mahmoud 
Fix a minor grammatical error in the PXE boot message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
index 2531153..5be82dc 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
@@ -2,6 +2,7 @@
   Boot functions implementation for UefiPxeBc Driver.
 
   Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -1228,7 +1229,7 @@ ON_EXIT:
   PxeBcUninstallCallback(Private, NewMakeCallback);
 
   if (Status == EFI_SUCCESS) {
-AsciiPrint ("\n  Succeed to download NBP file.\n");
+AsciiPrint ("\n  NBP file downloaded successfully.\n");
 return EFI_SUCCESS;
   } else if (Status == EFI_BUFFER_TOO_SMALL && Buffer != NULL) {
 AsciiPrint ("\n  PXE-E05: Buffer size is smaller than the requested 
file.\n");
-- 
2.6.3.windows.1

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

[edk2] An unkempt git guide for edk2 contributors and maintainers

2016-02-11 Thread Laszlo Ersek 
Disclaimer
==

This is a quick and dirty, simplified and slightly modified description
of my own edk2 workflow with git. It expressly defers to any upcoming
git workflow documentation on the wiki. It doesn't try to be generic,
focuses only on GNU/Linux (that's what I use). It will not go into many
details about git; if you are interested, you'll have to research those
concepts on the web yourself.

Also, this is very specific to edk2. Other projects have different
workflows.


Contributor workflow


(01) Create an account on GitHub.

(02) Enable SSH authentication for your account.

   https://help.github.com/articles/generating-an-ssh-key/

 When completing this step, you should end up with a new keypair
 under ~/.ssh/, for example:

   id_rsa_for_github
   id_rsa_for_github.pub

 and the following stanza in your ~/.ssh/config:

   Host github.com
 User  git
 IdentityFile  ~/.ssh/id_rsa_for_github

(03) Fork the following repository on GitHub into your own GitHub
 account, using the GitHub web GUI:

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

 (My personal fork is at

   https://github.com/lersek/edk2/
 )

(04) Clone the official edk2 repository to your local computer:

   cd some-appropriate-directory
   git clone https://github.com/tianocore/edk2.git

(05) Implement the following git settings for your local clone, i.e.,
 while standing in your local edk2 directory (these steps don't need
 customization):

   git config am.keepcr  true
   git config am.signoff true
   git config cherry-pick.signofftrue
   git config color.diff true
   git config color.grep auto
   git config commit.signoff true
   git config core.abbrev12
   git config core.pager cat
   git config core.whitespacecr-at-eol
   git config diff.algorithm patience
   git config diff.ini.xfuncname '^\[[A-Za-z0-9_.,   ]+]'
   git config diff.renames   copies
   git config format.signoff false
   git config notes.rewriteRef   refs/notes/commits
   git config sendemail.chainreplyto false
   git config sendemail.thread   true

(06) Also implement the following -- they need customization:

   git config sendemail.smtpserver FQDN_OF_YOUR_LOCAL_SMTP_SERVER
   git config user.email   "Your Email Address"
   git config user.name"Your Name"

(07) Create a file called "tianocore.template" somewhere outside your
 edk2 clone, with the following contents (remove leading
 whitespace). Note that the last line requires customization.

   [empty line]
   [empty line]
   Contributed-under: TianoCore Contribution Agreement 1.0
   Signed-off-by: Your Name 

(08) Standing in your edk2 clone, implement the following setting
 (requires customization):

   git config commit.template \
 FULL_PATHNAME_OF_FILE_CREATED_IN_LAST_STEP

(09) Open the file

   .git/info/attributes

 (create it if it doesn't exist), and add the following contents
 (with the leading whitespace removed):

   *.efi -diff
   *.EFI -diff
   *.bin -diff
   *.BIN -diff
   *.raw -diff
   *.RAW -diff
   *.bmp -diff
   *.BMP -diff
   *.dec diff=ini
   *.dsc diff=ini
   *.dsc.inc diff=ini
   *.fdf diff=ini
   *.fdf.inc diff=ini
   *.inf diff=ini

(10) Create a file called "edk2.diff.order" somewhere outside your local
 clone, with the following contents (removing the leading
 whitespace):

   *.dec
   *.dsc.inc
   *.dsc
   *.fdf
   *.inf
   *.h
   *.vfr
   *.c

(11) Add your own fork of edk2 that lives on GitHub as a *remote* to
 your local clone:

   git remote add -f --no-tags \
 YOUR_GITHUB_ID \
 g...@github.com:YOUR_GITHUB_ID/edk2.git

(12) At this point you are ready to start developing. Refresh your local
 master branch from the upstream master branch:

   git checkout master
   git pull

 The first command is extremely important. You should only run "git
 pull" while you are standing on your local master branch that
 tracks (and never diverges from) the upstream master branch.

 These commands will fetch any new commits from upstream master, and
 fast-forward your local tracking branch to the new HEAD.

(13) Create and check out a topic branch for the feature or bugfix that
 you would like to work on. The topic branch name requires
 customization of course.

   git checkout -b implement_foo_for_bar_v1 master

(14) Make sure you have the build environment set up:

   source edk2setup.sh
   make -C "$EDK_TOOLS_PATH"

(15) Implement the next atomic, logical step in your feature or bugfix.
 Test that

Re: [edk2] USB OHCI

2016-02-11 Thread El-Haj-Mahmoud, Samer 
Mike,

I will test it on an off-the-shelf PCI OHCI card and let you know.

Thanks,
--Samer

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Thursday, February 11, 2016 12:59 PM
To: El-Haj-Mahmoud, Samer ; 
edk2-devel@lists.01.org; Kinney, Michael D 
Subject: RE: USB OHCI

Samer,

Good question.  I have been considering it.  I need to review that code to make 
sure it works with other OHCI controllers on other platforms and that the 
register definitions used match the OHCI spec.  If we can get through a couple 
of those steps, I think it is a candidate to move to a common package.

If you have some platforms you can test it on, then please do and let us know 
the results.

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud, Samer
> Sent: Thursday, February 11, 2016 10:19 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D 
> 
> Subject: [edk2] USB OHCI
> 
> Mike,
> 
> Is there any reason why we can't move the OHCI drivers from:
> QuarkSocPkg\QuarkSouthCluster\Usb\Ohci to be with the rest of the USB stack 
> at:
> MdeModulePkg\Bus\Pci? The code seems to be generic with no Quark SOC 
> dependencies, correct? The Suppoted() function seem to imply binding to any 
> OHCI Class controller:
> 
>   //
>   // Test whether the controller belongs to OHCI type
>   //
>   if ((UsbClassCReg.BaseCode != PCI_CLASS_SERIAL) ||
>   (UsbClassCReg.SubClassCode != PCI_CLASS_SERIAL_USB) ||
>   (UsbClassCReg.ProgInterface != PCI_IF_OHCI)
>   ) {
> 
> Status = EFI_UNSUPPORTED;
>   }
> 
> Thanks,
> --Samer
> 
> ___
> 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] An unkempt git guide for edk2 contributors and maintainers

2016-02-11 Thread Laszlo Ersek 
On 02/12/16 02:05, Laszlo Ersek wrote:

> (16) Add your changes gradually to the staging area of git (it is called
>  the "index"):
> 
>git add -p
> 
>  This command will ask you interactively about staging each separate
>  hunk. See the manual for "git add".

I forgot to name two more commands here -- I've been now reminded of
them by Erik's and Jordan's updates to
:

- In order to stage a completely new file, use

  git add pathname-of-new-file

- In order to stage the removal of a file, use

  git rm pathname-of-file-to-remove

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

[edk2] USB OHCI

2016-02-11 Thread El-Haj-Mahmoud, Samer 
Mike,

Is there any reason why we can't move the OHCI drivers from: 
QuarkSocPkg\QuarkSouthCluster\Usb\Ohci to be with the rest of the USB stack at: 
MdeModulePkg\Bus\Pci? The code seems to be generic with no Quark SOC 
dependencies, correct? The Suppoted() function seem to imply binding to any 
OHCI Class controller:

  //
  // Test whether the controller belongs to OHCI type
  //
  if ((UsbClassCReg.BaseCode != PCI_CLASS_SERIAL) ||
  (UsbClassCReg.SubClassCode != PCI_CLASS_SERIAL_USB) ||
  (UsbClassCReg.ProgInterface != PCI_IF_OHCI)
  ) {

Status = EFI_UNSUPPORTED;
  }

Thanks,
--Samer

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

Re: [edk2] github development process

2016-02-11 Thread Bjorge, Erik C 
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> El-Haj-Mahmoud, Samer
> Sent: Wednesday, February 10, 2016 4:03 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] github development process
> 
> So I have been itching to submit patches after the transition to github,
> when I stumbled across this. It looks like the development process
> described in: https://github.com/tianocore/tianocore.github.io/wiki/EDK-
> II-Development-Process , does not match the process described in:
> https://raw.githubusercontent.com/tianocore/edk2/master/MdePkg/Contribut
> ions.txt
> 
> I followed the process in the wiki, and ended up creating a pull request
> for tiancore/edk for my contribution
> (https://github.com/tianocore/edk2/pull/55). I was also going to send a
> patch to EDK2 list (as the wiki suggests). Then I quickly realized that
> the maintainers are still working only with e-mail patches, and not pull
> requests, as clear from the conversations in closed/rejected pull
> requests:
> 
> https://github.com/tianocore/edk2/pull/45
> https://github.com/tianocore/edk2/pull/51
> https://github.com/tianocore/edk2/pull/41
> etc..
> 
> 
> I have no problem of sticking with the edk2-devel e-mail patches like we
> have been doing (all of my team from HPE contributes that way). But if
> that is the only/proper way to submit contributions, then the wiki need
> to be updated to drop the pull requests steps.

I will update the Wiki as you suggest.  We were hoping to allow for at least 
some form of pull request but it looks like we are not quite ready for that yet.

Thanks,
-Erik

> 
> Thanks,
> --Samer
> 
> 
> 
> ___
> 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] github development process

2016-02-11 Thread Bjorge, Erik C 
Jordan,

I think we also need to clarify step 9 as well by removing the option of 
sending a link and branch name of a forked repo.

Thanks,
-Erik

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> El-Haj-Mahmoud, Samer
> Sent: Thursday, February 11, 2016 7:31 AM
> To: Justen, Jordan L ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] github development process
> 
> Justen,
> 
> Yes I see now that there is duplicate between:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Process
> and
> https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-
> Github-Quick-Start
> 
> 
> And yes, step "7. Update the master branch (pull or fetch/merge" is what
> triggered me to create a pull request (that, and my incorrect assumption
> that we are using github for development process, not just to host the
> pull requests).
> 
> Thanks,
> --Samer
> 
> 
> 
> 
> 
> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Wednesday, February 10, 2016 6:32 PM
> To: El-Haj-Mahmoud, Samer ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] github development process
> 
> On 2016-02-10 16:03:26, El-Haj-Mahmoud, Samer wrote:
> > So I have been itching to submit patches after the transition to
> > github, when I stumbled across this. It looks like the development
> > process described in:
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
> > nt-Process , does not match the process described in:
> > https://raw.githubusercontent.com/tianocore/edk2/master/MdePkg/Contrib
> > utions.txt
> >
> 
> There seems to be duplicated content on
> 
> https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-
> Github-Quick-Start
> 
> And, I think the EDK-II-Development-Process version was a little older.
> I updated it to match the other one.
> 
> Before and after, I only saw one mention of 'pull':
> 
> "7. Update the master branch (pull or fetch/merge)"
> 
> Is this what caused the confusion? Or, was there something else that
> generated a pull request?
> 
> -Jordan
> 
> > I followed the process in the wiki, and ended up creating a pull
> > request for tiancore/edk for my contribution
> > (https://github.com/tianocore/edk2/pull/55). I was also going to send
> > a patch to EDK2 list (as the wiki suggests). Then I quickly realized
> > that the maintainers are still working only with e-mail patches, and
> > not pull requests, as clear from the conversations in closed/rejected
> > pull requests:
> >
> > https://github.com/tianocore/edk2/pull/45
> > https://github.com/tianocore/edk2/pull/51
> > https://github.com/tianocore/edk2/pull/41
> > etc..
> >
> >
> > I have no problem of sticking with the edk2-devel e-mail patches like
> > we have been doing (all of my team from HPE contributes that way). But
> > if that is the only/proper way to submit contributions, then the wiki
> > need to be updated to drop the pull requests steps.
> >
> > Thanks,
> > --Samer
> >
> >
> >
> > ___
> > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel