[edk2] [Announcement] Tianocore Community Leadership
Dear Community, I want to take this opportunity to announce that I will be stepping aside as the Tianocore Community Manager. Michael Kinney, one of our stewards, is taking on the role. Nothing changes, all the initiatives move forward. And we have a gentlemen you will soon meet, Neil, who will drive Bugzilla to completion! I wish you all the best, and don't be surprised if I resurface in this community in the coming months, with a different company. If you have any questions or concerns, do not hesitate to contact one of the stewards (Michael, Leif, or Andrew). Best Wishes, and see you soon... Tony --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Email tags for Bugzilla and administrative events
Server is now 5.0.3, and we updated the mail server to send emails that will likely not end up in the SPAM folder. For those on the list, if you haven't please take some time to go there and at minimum create your account. No need to move bugs there just yet, we're about a week(ish) away from doing that. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Mangefeste, Tony > Sent: Thursday, May 26, 2016 4:16 PM > To: Bruce Cran ; edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative events > > We will be doing that, and the server is in pre-testing mode right now. Next > week, I'll be finalizing the server, and in the meantime it will be going > offline > periodically. > > > > -Original Message- > > From: Bruce Cran [mailto:br...@cran.org.uk] > > Sent: Thursday, May 26, 2016 1:04 PM > > To: Mangefeste, Tony ; edk2- > > de...@lists.01.org > > Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative > > events > > > > On 5/23/2016 12:33 PM, Mangefeste, Tony wrote: > > > 3. The server URL is (https://tianocore.acgmultimedia.com). At this > > > time I'd > > like to ask all maintainers to please logon and create an account. I > > will use this information to assign package maintainers to specific > > security groups, email and such. > > > > It should probably be updated to v5.0.3 before going live > > (https://www.bugzilla.org/releases/5.0.3/release-notes.html). > > > > -- > > Bruce > ___ > 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] [RFC] Email tags for Bugzilla and administrative events
We will be doing that, and the server is in pre-testing mode right now. Next week, I'll be finalizing the server, and in the meantime it will be going offline periodically. > -Original Message- > From: Bruce Cran [mailto:br...@cran.org.uk] > Sent: Thursday, May 26, 2016 1:04 PM > To: Mangefeste, Tony ; edk2- > de...@lists.01.org > Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative events > > On 5/23/2016 12:33 PM, Mangefeste, Tony wrote: > > 3. The server URL is (https://tianocore.acgmultimedia.com). At this time > > I'd > like to ask all maintainers to please logon and create an account. I will use > this information to assign package maintainers to specific security groups, > email and such. > > It should probably be updated to v5.0.3 before going live > (https://www.bugzilla.org/releases/5.0.3/release-notes.html). > > -- > Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Email tags for Bugzilla and administrative events
The server had a bit of a hiccup, but it's back :)
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, May 23, 2016 2:57 PM
> To: Mangefeste, Tony
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative events
>
> On 05/23/16 20:33, Mangefeste, Tony wrote:
> > Folks,
> >
> > I'm ramping up work on deploying the Bugzilla server for our
> > community. A few things you will begin to see, and your comments are
> > appreciated on the below.
> >
> > 1. I'm going to send updates to the list. I'm going to add the tag
> > [INFO] to the subject line to pass down information to the community.
> > This is going to include some information related to bugzilla, or
> > anything else community related.
> >
> > 2. Our bugzilla server is being hosted by ACG Multimedia. They are a
> > vendor contracted by Intel, managed by me, and they own the physical
> > hardware that is hosting the server. Data submitted to our community
> > bugzilla server does not reside on Intel machines, and as such only
> > content pertaining to Tianocore should be added to our server.
> >
> > 3. The server URL is (https://tianocore.acgmultimedia.com). At this
> > time I'd like to ask all maintainers to please logon and create an
> > account. I will use this information to assign package maintainers to
> > specific security groups, email and such.
>
> At first the server threw different error messages at me ("Forbidden"
> and something about not finding "Auth.pm" or similar). Ultimately I managed
> to enter my email address, but the confirmation email doesn't seem to
> arrive. (It might arrive later I guess.)
>
> > 4. Feel free to submit issues, but for now, it is *not yet live*.
> > I'm working on it in real time, and anticipate making a broader
> > announcement to the community on June 6, 2016.
> >
> > The big ask right now pertains to maintainers. Please create your
> > accounts, with secure passwords. Everyone else may create their
> > account, but please do not load the database with issues right now.
> >
> > Lastly, please wind down usage of Github Issues!
>
> We have live tickets where we're communicating with users. I think I
> shouldn't abort that communication immediately.
>
> If the GitHub issue tracker can be convinced to reject new issues (with a
> pointer to this mailing list message), that could allow for an easier
> transition.
> (I.e., minimize the number of tickets that are severed in half by the
> bugtracker switch-over.)
>
> Looking forward to using Bugzilla!
We will migrate the issues from GitHub to BZ, before we shut it down!
>
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC] Email tags for Bugzilla and administrative events
Folks, I'm ramping up work on deploying the Bugzilla server for our community. A few things you will begin to see, and your comments are appreciated on the below. 1. I'm going to send updates to the list. I'm going to add the tag [INFO] to the subject line to pass down information to the community. This is going to include some information related to bugzilla, or anything else community related. 2. Our bugzilla server is being hosted by ACG Multimedia. They are a vendor contracted by Intel, managed by me, and they own the physical hardware that is hosting the server. Data submitted to our community bugzilla server does not reside on Intel machines, and as such only content pertaining to Tianocore should be added to our server. 3. The server URL is (https://tianocore.acgmultimedia.com). At this time I'd like to ask all maintainers to please logon and create an account. I will use this information to assign package maintainers to specific security groups, email and such. 4. Feel free to submit issues, but for now, it is *not yet live*. I'm working on it in real time, and anticipate making a broader announcement to the community on June 6, 2016. The big ask right now pertains to maintainers. Please create your accounts, with secure passwords. Everyone else may create their account, but please do not load the database with issues right now. Lastly, please wind down usage of Github Issues! More incoming. Tony --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, and perhaps into a platform branch or staging branch (depending on a number of factors). Abner, run this through the PIWG as you stated, that's external to our Tianocore community. He can at least stage the code somewhere, so that the community can use the code, play with it, and give him feedback. Good discussion. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Monday, May 9, 2016 10:46 AM > To: Yao, Jiewen ; Chang, Abner (HPS SW/FW > Technologist) ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > DxeIpl. > > On 2016-05-09 08:53:12, Yao, Jiewen wrote: > > Jordan > > Do you know why we have ArmPkg and ArmPlatformPkg? > > > > One reason is because we don't have a DriversPkg. Another reason is > probably because the effort wasn't made to put them into common > packages. > > > If you take a look at that, you will find many Arm specific driver > > there, including CpuDxe/CpuPei/BaseMemoryLib/ > > PeiServicesTablePointerLib/etc... > > > > Should we create a package for IA32 and X64 to do the same? I think instead > we put the IA32/X64 modules in other locations, and I think that made sense. > If it made sense for IA32 and X64, then it should make sense for other > architectures as well. > > > I do not think it is bad idea to have RiscVPkg, when we are not clear > > on where to put it. > > > > So this is the place to dump things that we don't know where else to put > them? That doesn't inspire too much confidence. :) > > I agree that it might be needed, but can we try to minimize it? > > -Jordan > > > > > > -Original Message- > > > From: Justen, Jordan L > > > Sent: Monday, May 9, 2016 11:46 PM > > > To: Yao, Jiewen ; Chang, Abner (HPS SW/FW > > > Technologist) ; edk2-devel@lists.01.org > > > Cc: Gao, Liming > > > Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > DxeIpl. > > > > > > On 2016-05-09 08:12:20, Yao, Jiewen wrote: > > > > Thank Abner. > > > > For RiscVPkg, my personally feeling is that it should stick to > > > > RiscV architecture, like ArmPkg. > > > > > > > > > > I don't agree. Why don't we have an X64Pkg? I think it is because > > > we've defined good locations already for most modules, and many of > > > those modules already support multiple architectures. > > > > > > Can't the first try be to see if we can get by without adding new > > > architecture specific packages? > > > > > > > Below module seems to be software concept only. They are > > > > independent to RISV-V architecture, right? > > > > I am not sure if it is proper to put to RiscVPkg. > > > > > > > > > RiscVPkg/Universal/Logo/Logo.uni | Bin 0 -> > > > 1948 bytes > > > > > RiscVPkg/Universal/Logo/LogoExtra.uni | Bin 0 -> > > > 1342 bytes > > > > > RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp | Bin 0 -> > > > 12446 bytes > > > > > RiscVPkg/Universal/Logo/RiscvUefiLogo.inf | 34 + > > > > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.c | 107 +++ > > > > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.h | 32 + > > > > > .../Universal/RiscvBadgingDxe/RiscvBadgingDxe.inf | 54 ++ > > > > > > > > Maybe we can put to a RiscV platform pkg? > > > > > > > > > > I think it would be better to add the logo to a common location > > > like, perhaps MdeModulePkg/Universal/Logo/RiscV. > > > > > > Actually, I don't think the new logo is needed. We don't have > > > architecture specific logos in other cases, and I don't think it is > > > needed here. > > > > > > -Jordan > > > > > > > > > > > > -Original Message- > > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On > > > > > Behalf > > > Of > > > > > Chang, Abner (HPS SW/FW Technologist) > > > > > Sent: Monday, May 9, 2016 10:10 PM > > > > > To: Justen, Jordan L ; > > > edk2-devel@lists.01.org > > > > > Cc: Yao, Jiewen ; Gao, Liming > > > > > > > > > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > > > DxeIpl. > > > > > > > > > > Hi Jordan, > > > > > I will send out another draft version of patches which address > > > > > all > > > comments. > > > > > Then upstream RISC-V code to the branch. > > > > > Sure, I am pleased to check if there is any reusable modules for RISC- > V. > > > > > Thanks > > > > > Abner > > > > > > > > > > -Original Message- > > > > > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > > > > > Sent: Monday, May 09, 2016 2:25 PM > > > > > To: Chang, Abner (HPS SW/FW Technologist) > ; > > > > > edk2-devel@lists.01.org > > > > > Cc: liming@intel.com; Yao, Jiewen > > > > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > > > DxeIpl. > > > > > > > > > > On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > > Hi Jordan, > > > > > > The UEFI/PI E
[edk2] Security Issues for Tianocore
I'm working on refining how the community handles security issues found in Tianocore. Expect an update soon(tm), however, in the meantime, please refer to the update on our portal at: http://tianocore.org/security. The TL;DR we're asking all security issues discovered in Tianocore be reported to the UEFI USRT as a stop-gap measure. Issues should not be reported through any other unencrypted, insecure mechanism. I'll be discussing our process with the UEFI USRT next week. ***do not send further emails on tianocore-secur...@lists.sourceforge.net*** --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong verification logic in DBX & DBT
Yes, this process needs refinement, it's on my list of things to worry about. We will have a standard way for handling security issues, and part of the upcoming rollout of our defect management system, procedure will target security bugs. Got the memo, it's a problem we'll work on a fix. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Peter Jones > Sent: Friday, April 15, 2016 8:44 AM > To: Dick Wilkins > Cc: edk2-de...@ml01.01.org; Kevin Davis ; Laszlo > Ersek ; Zhang, Chao B ; > Long, Qin > Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong > verification logic in DBX & DBT > > On Fri, Apr 15, 2016 at 08:10:50AM -0700, Dick Wilkins wrote: > > Peter, > > > > Yes, we definatly have a broken procedure here. I think that Tony M. > needs to work with the USRT to develop a procedure for handling security > issues in the open-source code. The general flow should be: > > > > 1- A security vulnerability is found and is reported to the USRT as well as > the Tianocore security alias. > > 2- The USRT opens a tracking ticket and evaluates the severity and decides > on how to proceed. > > 3- In most cases, we report the problem to our "notify" email alias, > preferably with the fix, and IBVs and OEMs adopt the fix. > > 4- After a suitable timeframe, the problem and fix are disclosed by checking > in the code change to the open-source repository. > > 5- If appropriate, after the fix is widely available and adopted, a CVE is > created. > > CVE should be step 3 here, not step 5. You don't actually have to disclose > what's broken or what the fix is to get a CVE allocated - often we get them as > soon as we know there's a problem, sometimes without even knowing if it's > possible to write an exploit. It's best to do it before the notification > step if > possible - that way the fix's commit message (and the USRT ticket) can say > what CVE it's for, and when any level of public disclosure happens later, > it'll > include that. That in turn also means firmware updates' change logs can > include the same CVE number. > Even if it's in something that doesn't get publicly disclosed (say a BSP > driver or > other hardware support package), the same is true. That way it's easy for > IBVs and OEMs to match up the private thing with the publicly disclosed info, > and for consumers to figure out if they got the fix for a given vulnerability. > > > This is my proposal as chair of the UEFI Security Response team. For > > those not familiar with us, please visit http://uefi.org/security. > > Please feel free to provide input on this proposed process. > > > > > Thanks, > > Dick Wilkins > > > > > > From: edk2-devel [edk2-devel-boun...@lists.01.org] On Behalf Of Peter > > Jones [pjo...@redhat.com] > > Sent: Friday, April 15, 2016 10:51 AM > > To: Zhang, Chao B > > Cc: edk2-de...@ml01.01.org; Kevin Davis; Laszlo Ersek; Long, Qin > > Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix > > wrong verification logic in DBX & DBT > > > > On Fri, Apr 15, 2016 at 12:40:14AM +, Zhang, Chao B wrote: > > > Hi all: > > > Thank you very much for the info. Do you agree to add "[USRT > > > 0001604]: Bug found in SecuritPkg: DxeImageVerificationLib" into the > > > log & check in this patch? > > > > What's the point of adding our internal tracker to it? If anything > > the CVE should be part of the commit message. So we should still do > > that, and tracking the progress in doing so with a USRT ticket is > > reasonable. > > But there's a bigger problem: right now the bug is public info, and > > this discussion is public: > > http://thread.gmane.org/gmane.comp.bios.edk2.devel/10693 . > > > > The time for a ticket to be opened with USRT, having a CVE assigned, > > and contacting vendors who may have shipped this code was *before* the > > patch was posted to the list. Now we need to clean up the mess. > > > > Our saving grace here is that Jeremiah hasn't actually /issued/ any > > DBT updates, so it's unlikely anybody is really vulnerable to the > > attack unless vendors have added DBT entries to their own shipping > > firmwares (which I also doubt). But what that distinction affords us > > is the ability to learn the right procedures now, so when there's a > > worse vulnerability found, we don't make the same mistakes again. > > > > -- > > Peter > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > -- > Peter > ___ > 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] Tianocore Staging Process
You can find the final revision of the staging process is now live. https://github.com/tianocore/edk2-staging README.md is updated with the process description, supporting links are updated throughout the site. If you find something is off, don't hesitate to let me know. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Tianocore Community Update - March 30, 2016
It is Indeed appropriate to thank them. I did so in the tweet this AMCheck out @tianocore's Tweet: https://twitter.com/tianocore/status/715016134982930432?s=09 And thank you for alerting the Debian community. They were dependent on this as well. -- Original message-- From: Laszlo Ersek Date: Wed, Mar 30, 2016 4:53 PM To: Mangefeste, Tony; Cc: edk2-devel@lists.01.org;Justen, Jordan L;Doran, Mark;Andrew Fish;Leif Lindholm (ARM address);Paolo Bonzini;Gerd Hoffmann;Cole Robinson;Richard W.M. Jones;Karen Noel;Ademar de Souza Reis Jr.;Peter Jones;Ard Biesheuvel;Francesco Poli (wintermute);Paul Wise;Steve Langasek;Drew Jones;Alexander Graf; Subject:Re: [edk2] Tianocore Community Update - March 30, 2016 On 03/30/16 04:40, Mangefeste, Tony wrote: > Good morning from Taipei! > > I'd like to take this opportunity to bring you all up to date one > several developments. > > This morning, I'll be giving a state of the Tianocore program to the > UEFI Plugfests. Please see the attached Roadmap update. I'll be > delivering details on these topics, which I have already highlighted > in my previous communications. > > And, today I'm excited to announce that Microsoft has agreed to > remove the use restriction in the license for the UEFI FAT sources > maintained as part of the EDK II project on tianocore.org. The > license and file headers of the UEFI FAT sources will be updated to > match the standard OSI BSD license. I'm thrilled to be making this > announcement today at the Spring 2016 UEFI plugfest when I present on > the current state of Tianocore, and to include this news as part of > today's announcement. As I wrote in <http://thread.gmane.org/gmane.comp.bios.edk2.devel/9930/focus=9956>, this is hugely beneficial to the open source community, and I think I can say on behalf of all of us that we're thrilled to learn about this development. In my other message I didn't credit Microsoft by name -- Jordan's blurb didn't mention Microsoft explicitly, so I wasn't sure if I should address them either. I am now -- thank you, Microsoft. Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Tianocore Community Update - March 30, 2016
Good morning from Taipei! I'd like to take this opportunity to bring you all up to date one several developments. This morning, I'll be giving a state of the Tianocore program to the UEFI Plugfests. Please see the attached Roadmap update. I'll be delivering details on these topics, which I have already highlighted in my previous communications. And, today I'm excited to announce that Microsoft has agreed to remove the use restriction in the license for the UEFI FAT sources maintained as part of the EDK II project on tianocore.org. The license and file headers of the UEFI FAT sources will be updated to match the standard OSI BSD license. I'm thrilled to be making this announcement today at the Spring 2016 UEFI plugfest when I present on the current state of Tianocore, and to include this news as part of today's announcement. BRs, Tony --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] EDK2 Staging Proposal 3rd draft, final?
Folks, Here's the 3rd iteration based on your input. Please take one last opportunity to review, we'll settle on this if there are no major requests by Friday of this week. 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. The specific process used to add the feature to edk2 is at the discretion of the person doing the merge. Some examples are use of 'git rebase' and 'git pull'. A merge commit must always contain the final 'Reviewed-by:' tags. d) Remove feature branch from edk2-staging and archive at https://github.com/tianocore/edk2-archive. 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 and archived at https://github.com/tianocore/edk2-archive. 8) Process to evaluate a feature in edk2-staging a) Clone edk2 b) Create local branch with optional platform packages c) Build platform in local branch and verify it is stable d) Clone edk2-staging/[branch name] e) Create local branch with optional platform packages f) Build platform in local branch and evaluate new feature BRs, Tony ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK2 Staging Repository 2nd Draft
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<mailto:;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.Th<http://done.Th>e '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<mailto:%20centredavid.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
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 t
Re: [edk2] EDK2 Staging Repository 2nd Draft
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
[edk2] EDK2 Staging Repository 2nd Draft
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 platform packages c) Build platform in local branch and verify it is stable d) Clone edk2-staging/[branch name] e) Create local branch with optional platform packages f) Build platform in local branch and evaluate new feature BRs, Tony ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK2 Staging Repository
Yep, I've heard that loud and clear. It must not be only web UI, but can be over email _if_ we move with Gerrit or something similar. -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, March 10, 2016 9:34 AM To: Mangefeste, Tony ; Gerd Hoffmann ; Bruce Cran Cc: Justen, Jordan L ; edk2-devel@lists.01.org Subject: Re: [edk2] EDK2 Staging Repository On 03/10/16 17:55, Mangefeste, Tony wrote: > This is fantastic, because the other two things I would like for us all to > consider is Gerrit+Jenkins support. Sorry for repeating myself :(, but: Please make sure that all reviews done on the web are forwarded to the mailing list, and that I can chime in using only my MUA. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Tianocore Community Update 2016 #1
Very good thoughts, Laszlo. The more I think about GitHub integration, the more I'm leaning against it. Another reason is that we can assign groups to certain organizational emails to allow/grant special rights to specific classes of issues. For example, it's plausible that we would give anyone from *@redhat.com for instance a group that identified them as part of that organization and then grant tha ability to perform special triage tasks or other organization specific tasks, while keeping the content visible to the community. -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, March 10, 2016 2:33 AM To: Mangefeste, Tony Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Tianocore Community Update 2016 #1 On 03/09/16 19:49, Mangefeste, Tony wrote: > I. Defect & Issue Tracking > There are several topics we're investigating, and your input is appreciated: First of all, thank you very much for going forward with Bugzilla! > * Considering tying the Bugzilla login to GitHub using GitHub as the > provider. This would mean that anyone wishing to submit an item into > BZ would require a GitHub account. I vote against this. I find 3rd party authentication providers insecure. While I find Single Sign On extremely useful (and also secure) in a single, centrally managed organization, GitHub and the edk2 Bugzilla (to be operated by Intel) are separate entities. A breach of GitHub could lead to a breach of the Bugzilla, and leakage of sensitive data (private comments, private bugs, private attachments). Downtime of GitHub would prevent us from logging into Bugzilla. Modern browsers have built-in password managers. The practice I generally follow is to have a unique, complex, machine-generated password for every public-facing website, and to store those in a reliable password manager (behind a very strong master password of coruse). --*-- Another practical remark: I insist on having access to the personal email addresses of people who report bugs, for two reasons. Less importantly, I want to be able to contact them in email, outside of bugzilla (they might have some files I need for debugging, but their data is too sensitive or too big to attach to the bug). More importantly, if I write patches for a BZ entry (bug or feature request), I always CC the reporter on the patches. Now, purely for informing the reporter about the patches, my "other" best practice would suffice in itself -- that best practice being: I link every patch submisson from the mailing list archive immediately into the bug --, but the main goal is that I want his/her testing feedback. For that the reporter should be able to build my patches, hence I CC him/her directly. Therefore I need his/her email address on the bug. Fishing the emails of reporters out of GitHub's issue tracker has been a pain. One clicks the "@reporter_nick" style link in the discussion, and hopes that the reporter's profile page lists his/her email address publicly. If it doesn't, then I have to ask for it in the tracker entry explicitly, or I can try googling it. Bugzilla normally gives me the email addresses of all commenters on the bug automatically, and so it should be. (Example: my profile page <https://github.com/lersek/> does not list my email address either. Why? Because I don't like spam, and my email is trivially googleable for humans, from my name & employer. The point with Bugzilla is that it only exposes email addresses to logged in users (no bots), but then logged in users do get all the addresses without further obstacles.) I'm worried that if GitHub provided the authentication for Bugzilla, it could withhold email addresses from Bugzilla, and break the above use case. Thank you Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK2 Staging Repository
I've used Gerrit personally, but I hear what you're saying on the UI. There's always other options available we can discuss as a community. We're not there yet either, so this is all forward looking "stuff". -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Thursday, March 10, 2016 9:05 AM To: Mangefeste, Tony ; Gerd Hoffmann Cc: Justen, Jordan L ; edk2-devel@lists.01.org Subject: Re: [edk2] EDK2 Staging Repository On 3/10/16 9:55 AM, Mangefeste, Tony wrote: > This is fantastic, because the other two things I would like for us all to > consider is Gerrit+Jenkins support. Why Gerrit? Everyone I've seen talk about it hate its UI. FWIW I seem to be leading a bit of a rebellion at $work, since I setup a demo Phabricator instance (for the repo browser and code review) and most people love it, to the extent that they're saying they wish we'd used it from the start and wondering if any engineers were involved in the decision to use the tool that we're supposed to be using. -- Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK2 Staging Repository
This is fantastic, because the other two things I would like for us all to consider is Gerrit+Jenkins support. I'll be talking to you to get more details. -Original Message- From: Gerd Hoffmann [mailto:kra...@redhat.com] Sent: Thursday, March 10, 2016 12:39 AM To: Bruce Cran Cc: Justen, Jordan L ; Mangefeste, Tony ; edk2-devel@lists.01.org Subject: Re: [edk2] EDK2 Staging Repository On Mi, 2016-03-09 at 16:57 -0700, Bruce Cran wrote: > On 3/9/16 2:59 PM, Jordan Justen wrote: > > > So far I have a setup that can test building BaseTools and OVMF on > > Linux. The Windows setup is a little more complicated, but I don't > > think it should be too difficult. > > I guess that's Linux x86_64? Any solution we come up with should also > be extendable to AARCH64. I do have jenkins running, doing the builds for https://www.kraxel.org/repos/, including aarch64 and arm builds (using a cross compiler). If there is interest I configure jenkins to send build failures to the list too. There are some drawbacks though: (1) There are false positives now and then for various reasons: * Now and then manual invention is needed to keep things going (for example on openssl updates). * The rpm package has patches which need a rebase now and then. * Occasionally infrastructure hickups. (2) Sometimes it takes me a few days to deal with those issues, jenkins will keep on reporting the build failures until I did. (3) The system runs on a private network behind a NAT router, so you wouldn't be able to click on the links for build logs etc, all you get is the mail reporting the failure. (4) It's designed to provide rpms for the master branch, that it test-builds the master branch is more a side-effect. I most likely wouldn't extend this to also build staging branches. If you ever wondered how Laszlo notices quickly if someone breaks the build, he gets the jenkins reports ;) cheers, Gerd ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Link not reachable
Jim, Does this help? https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II This is from the homepage -> Projects -> EDKII -> Getting Started for Developers There's a number of useful links in the wiki page that flow from that. Tony -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jim Slaughter Sent: Wednesday, March 9, 2016 1:02 PM To: edk2-devel@lists.01.org Subject: [edk2] Link not reachable I cannot reach https://edk2.tianocore.org/step-by-step-instructions.html Has it been replaced? Jim S. ___ 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] EDK2 Staging Repository
Below are the details of the proposal for a staging branch, please review and comment. 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 name]: 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 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 rebased to edk2/master 5) Process to update sources in feature branch a) Patch email send to edk2-devel b) Commit message subject format [staging][branch name][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. 5) 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?). 6) 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?). 7) Process to evaluate a feature in edk2-staging a) Clone edk2 b) Create local branch with optional platform packages c) Build platform in local branch and verify it is stable d) Clone edk2-staging/[branch name] e) Create local branch with optional platform packages f) Build platform in local branch and evaluate new feature --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Tianocore Community Update 2016 #1
Hello Tianocore Community! It's been a few weeks since my last update, or rather introductions, into the community. It's time for a sync. As always the goal is to be transparent with how we work as a community, and with that in mind here are some updates to provide to you all. I. Defect & Issue Tracking As you may have read on the list, we're going to move towards having a Bugzilla system in place for us to track work items, defects, and features asks. This is part of a broader plan that we'll roll out and discuss regarding how we improve the Tianocore program cadence, and how improve the quality of our code. But for now, the update is that we're moving forward with a Bugzilla server. Unfortunately, that server is inside of Intel's firewall, and I'm working to get it on the DMZ so that the community can poke at it, provide feedback, and we can iterate before going live. There are several topics we're investigating, and your input is appreciated: * Considering tying the Bugzilla login to GitHub using GitHub as the provider. This would mean that anyone wishing to submit an item into BZ would require a GitHub account. * Requirements from the previous exchange on this list about the need for groups in general to protect sensitive issues that may be filed. (e.g. security) * And we're going to consider adding a test repository along with the ability to link issues with test cases. The next steps are fluid at the moment, but I promise an update in the next few weeks. I will be providing an update by the end of the month. II. Governance We're naming three individuals who will act as Tianocore stewards. These three individuals and I will work with the community to facilitate design conversations, carry through difficult decisions, and in general as their name suggest offer "stewardship" of the code. I'm happy to announce that: * Andrew Fish (Apple) * Leif Lindholm (Linaro) * Mike Kinney (Intel) Are our first set of folks who will be acting in this role. We'll be rolling out more details soon on their specific functions and duty, but for now I wanted to make sure everyone is aware of this change. We're going to be rolling out several areas of focus for the community, which will also include improved codification of the edk2 development process. III. Staging Area Along with an announcement in governance, we've made a decision to offer up a standing repository so that the community can prototype, validate, and otherwise experiment with features before they get rolled into the main EDK2 trunk. Please review the follow-up email (sent separately) to comment on the process. We'll also add it to the wiki after initial comments. Regards, Tony PS. I'll be uploading these into the wiki as time goes on for these updates. --- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Task: Issue Tracking System for Tianocore
BTW, I will start experimenting with it myself in the coming days setting up a virtual server, so I'll know better myself. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mangefeste, Tony Sent: Wednesday, February 10, 2016 5:53 PM To: Leif Lindholm Cc: edk2-devel@lists.01.org ; Laszlo Ersek ; Ard Biesheuvel Subject: Re: [edk2] Task: Issue Tracking System for Tianocore 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. -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 +0000, 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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Task: Issue Tracking System for Tianocore
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. -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] Task: Issue Tracking System for Tianocore
Now that's a great idea. I'm already leaning towards whatever system we employ to have well documented methods for maintenance so that anyone (including myself) can contribute time to maintain. Arguably, we can extend that to allow trusted members of the community rights to help maintain as well. +1 And as for hosting, it's too early to tell, but like you I want it hosted off of Tianocore.org, there's some voodoo that can be employed to make that happen, and we'll work with our web backend contractor to see about making that happen. -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Wednesday, February 10, 2016 5:02 PM To: Mangefeste, Tony ; Justen, Jordan L ; Laszlo Ersek ; Leif Lindholm (Linaro address) ; Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 2/10/16 5:58 PM, Mangefeste, Tony wrote: > Yes, the funding for a service (like Bugzilla) is not at present time a > concern. But we're still investigating and modeling out what it will take to > use it, and of course if it turns out to be unjustifiable, we'll find > something else (including using GitHub issue tracking). Could an instance of bugzilla be hosted on tianocore.org if necessary? I presume tianocore.org is a dedicated Linux server somewhere that someone has root privileges on, and could probably be maintained by volunteers if we don't have sufficient sysadmins already? -- Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Task: Issue Tracking System for Tianocore
Leif, 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. BRs, Tony -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] Task: Issue Tracking System for Tianocore
Yes, the funding for a service (like Bugzilla) is not at present time a concern. But we're still investigating and modeling out what it will take to use it, and of course if it turns out to be unjustifiable, we'll find something else (including using GitHub issue tracking). -Original Message- From: Justen, Jordan L Sent: Wednesday, February 10, 2016 4:57 PM To: Mangefeste, Tony ; Laszlo Ersek ; Leif Lindholm (Linaro address) ; Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: RE: [edk2] Task: Issue Tracking System for Tianocore On 2016-02-10 16:21:33, Mangefeste, Tony wrote: > GitHub doesn't allow for data import/export or report generation as They have an API that should allow for this: https://developer.github.com/v3/issues/ > much as I'd like to stick with the GitHub issue management, and other > limitations that will be pushed as we grow in GitHub usage. > What other limitations? > I agree on the Bugzilla maintenance, we're looking into the specific > scopes there too. Can you confirm that a non-free (as in money) service will be funded for a substantial period of time? If we can pay someone reliable to run bugzilla for us, that would be nice. -Jordan > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Wednesday, February 10, 2016 4:01 PM > To: Laszlo Ersek ; Leif Lindholm (Linaro address) > ; Ard Biesheuvel > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Task: Issue Tracking System for Tianocore > > On 2016-02-10 15:08:16, 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/ > > > > Oh wait, there seems to be a new URL (still JIRA): > > https://projects.linaro.org > > > > 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? > > > > As an user of GitHub, Bugzilla and Jira. > > Jira: No advantages over Bugzilla. Bigger, and slower than bugzilla. I think > it tries to be flashier than bugzilla (and bugzilla is admittedly a bit dated > looking). > > Bugzilla: Works fine. Pain in the but to administer. You have to pay for > hosting. > > GitHub: Easy, but simplistic. > > I think GitHub is the easier choice, and is good enough. Users will likely > expect to find it used since the source is currently hosted there. > > Actually, we are currently using GitHub, so we would be talking about > a change if we moved to anything else. We have 17 open and 18 closed > bugs currently which far surpasses the activity in the bug tracking > 'trac' system that we had on sourceforge for several years. :) (And, I > think the same for the collabnet hosted bugs before that.) > > I think bugzilla is an okay choice if it can be paid for (with several years > of funding...). I guess I'd recommend finding a service dedicated to hosting > bugzilla, and not try to set up a server and self-host. It'd be a little > annoying to have a separate bug tracker account. > > My vote is to stick with GitHub for now. > > -Jordan > > > > > > > > > -Original Message- > > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > > Sent: Wednesday, February 10, 2016 2:44 PM > > > To: Mangefeste, Tony > > > Cc: edk2-devel@lists.01.org > > > Subject: Re: [edk2] Task: Issue Tracking System for Tianocore > > > > > > On 02/10/16 22:45, Mangefeste, Tony wrote: > > >> We need an issue tracking system for Tiano. > > >> > > >> The built-in issue tracking system t
Re: [edk2] Task: Issue Tracking System for Tianocore
+1, we'll hit some rough spots in the coming months, but the end result will be achieved. Thanks for the input. -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Wednesday, February 10, 2016 4:21 PM To: Mangefeste, Tony ; Laszlo Ersek Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 2/10/16 3:59 PM, 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. I'm currently hosting a mirror of the edk2 repo at https://edk2.bluestop.org/diffusion/EDK/ - Phabricator has a bug/task tracker module Maniphest that looks rather capable - https://phacility.com/phabricator/maniphest/ . I just think it's a shame we've lost so many bugs by telling people to report them to the mailing list for a couple of years, so any issue tracker is good at this point! -- Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Task: Issue Tracking System for Tianocore
GitHub doesn't allow for data import/export or report generation as much as I'd like to stick with the GitHub issue management, and other limitations that will be pushed as we grow in GitHub usage. I agree on the Bugzilla maintenance, we're looking into the specific scopes there too. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Wednesday, February 10, 2016 4:01 PM To: Laszlo Ersek ; Leif Lindholm (Linaro address) ; Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 2016-02-10 15:08:16, 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/ > > Oh wait, there seems to be a new URL (still JIRA): > https://projects.linaro.org > > 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? > As an user of GitHub, Bugzilla and Jira. Jira: No advantages over Bugzilla. Bigger, and slower than bugzilla. I think it tries to be flashier than bugzilla (and bugzilla is admittedly a bit dated looking). Bugzilla: Works fine. Pain in the but to administer. You have to pay for hosting. GitHub: Easy, but simplistic. I think GitHub is the easier choice, and is good enough. Users will likely expect to find it used since the source is currently hosted there. Actually, we are currently using GitHub, so we would be talking about a change if we moved to anything else. We have 17 open and 18 closed bugs currently which far surpasses the activity in the bug tracking 'trac' system that we had on sourceforge for several years. :) (And, I think the same for the collabnet hosted bugs before that.) I think bugzilla is an okay choice if it can be paid for (with several years of funding...). I guess I'd recommend finding a service dedicated to hosting bugzilla, and not try to set up a server and self-host. It'd be a little annoying to have a separate bug tracker account. My vote is to stick with GitHub for now. -Jordan > > > > > -Original Message- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Wednesday, February 10, 2016 2:44 PM > > To: Mangefeste, Tony > > Cc: edk2-devel@lists.01.org > > Subject: Re: [edk2] Task: Issue Tracking System for Tianocore > > > > On 02/10/16 22:45, Mangefeste, Tony wrote: > >> We need an issue tracking system for Tiano. > >> > >> The built-in issue tracking system that comes with GitHub isn't > >> sufficient to satisfy a key requirement. There needs to be support > >> for multiple Tianocore-related programs. > > > > I agree. The Bugzilla instance that Red Hat operates supports many pieces > > of metadata, and "product" and "component" are two key fields. I would find > > it useful if the metadata reflected even the edk2 module in question, at > > least for long-established modules (library instances and drivers). This > > would also enable fine-grained automatic assignment to a maintainer. > > > >> As you know Intel has a > >> system today that's internal to Intel where we track issues. That > >> does not meet the needs of the community. And to help improve > >> transparency, and better engage with the community I'm driving the > >> discussion and bring up of a bug tracking system. > >> > >> The goal is to have one operational by March 21, 2016 (WW13). > >> We're > >> 6 weeks and counting from that deadline. I'm interested in > >> community feedback, gathering requirements, and feedback on > >> proposals for which system to use. > > > > - Launchpad > > <https:/
Re: [edk2] Task: Issue Tracking System for Tianocore
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. -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, February 10, 2016 2:44 PM To: Mangefeste, Tony Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 02/10/16 22:45, Mangefeste, Tony wrote: > We need an issue tracking system for Tiano. > > The built-in issue tracking system that comes with GitHub isn't > sufficient to satisfy a key requirement. There needs to be support > for multiple Tianocore-related programs. I agree. The Bugzilla instance that Red Hat operates supports many pieces of metadata, and "product" and "component" are two key fields. I would find it useful if the metadata reflected even the edk2 module in question, at least for long-established modules (library instances and drivers). This would also enable fine-grained automatic assignment to a maintainer. > As you know Intel has a > system today that's internal to Intel where we track issues. That > does not meet the needs of the community. And to help improve > transparency, and better engage with the community I'm driving the > discussion and bring up of a bug tracking system. > > The goal is to have one operational by March 21, 2016 (WW13). We're > 6 weeks and counting from that deadline. I'm interested in community > feedback, gathering requirements, and feedback on proposals for which > system to use. - Launchpad <https://bugs.launchpad.net/> Cons: - proportional width font - forcefully reflows comments, even if it means breaking git commit hashes into several parts, breaking copy & paste on double-click - truncates long comments in the "full bug view". If you'd like to read a careful, detailed comment to end, you have to open the comment in isolation. And then you can't look at the other comments at the same time. - Github issue tracker <https://github.com/tianocore/edk2/issues> Pros: - some integration with the code repository (automatic highlighting of commit hashes, for example; link leads to commit when clicked) Cons: - social interaction oriented, with @person style "callouts" - doesn't support binary attachments - very basic, lacking metadata - bug data is held hostage, no way to mass-export it in an open format / schema - proportional width font, with MarkDown enabled by default (interferes with ASCII diagrams and code pasting) - lackluster integration with email (can't send updates of one's own bug actions) - unwieldy permalinks for comments, even from within other comments on the same bug - allows anyone to reedit their own posted comments (that's a negative, yes) - Bugzilla <https://bugzilla.redhat.com> <http://bugzilla.kernel.org/> <https://gcc.gnu.org/bugzilla/> <https://bugzilla.gnome.org/> Pros: - the gold standard for serious free and open source software - heavy local customization possible - splendid outgoing emails, including about your own actions; metadata changes rendered in simple ASCII tables - heaps of metadata - public and private bugs - public and private comments and attachments - access to any individual bug can be restricted to specific groups (partners, customers, security response team) - flags for release planning and stakeholder signoff - well defined and customizable bug states and transitions - monospace font for comments - simple permalinks (can be hand-constructed if you know the bug nr and comment nr you want to refer to) - no markup beyond simple highlighting (as links) of a few patterns, like "bug NNN", "comment ZZZ", and "bug PPP comment QQQ". - bug aliases (like CVE-2016-N) that are highlighted and resolved to their respective bug numbers - dependency tracking between bugs, displayable in a tree-like view as well - support for cloning bugs for other components and products - elaborate queries can be composed and saved - you can watch people, regardless on what bug they comment or work o
[edk2] Task: Issue Tracking System for Tianocore
We need an issue tracking system for Tiano. The built-in issue tracking system that comes with GitHub isn't sufficient to satisfy a key requirement. There needs to be support for multiple Tianocore-related programs. As you know Intel has a system today that's internal to Intel where we track issues. That does not meet the needs of the community. And to help improve transparency, and better engage with the community I'm driving the discussion and bring up of a bug tracking system. The goal is to have one operational by March 21, 2016 (WW13). We're 6 weeks and counting from that deadline. I'm interested in community feedback, gathering requirements, and feedback on proposals for which system to use. We're going to transform issue tracking on Tianocore a transparent, community driven behavior. Key requirements for the system include (but not limited to): * OSS (does not have to be free) * Ability to bulk import/export databases, data (CSV) * Secure, ability to shield sensitive issues * Group credential management * Supports mobile views (phone/tablet) * Ability to generate reports * Can be used to generate quick tasks for community members (e.g. Find a Task) * Integrate with GitHub I appreciate anyone's time and passion on this. Let me know if you want to participate in such a task force. BRs, Tony ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Hello World
Hello There. Im Tony. I had the intent of writing an introduction that went into all sorts details about who I am, what I love, and why Im emailing this community. Pardon the clichéd, over used subject line; I failed at thinking of something that wouldnt turn out to be super stuffy. Instead I decided Im going to keep this short, direct and to the point. Why am I emailing this list? Im your new Tianocore community manager. As best as I can tell, no one has had this role, and Im the first. And Im thrilled to have the opportunity to help Tianocore evolve into an awesome-er OSS program. So why you? Why not? I have years of experience with UEFI, I know many of you, and now the time is right for me to inject my passion and interests into Tianocore. If I dont know you, I want to know you. I have a vision and passion for Tianocore. That vision includes a desire to increase contribution levels by all members of the community into Tianocore. Whats going to change with Tianocore? I hope much positive change will come. More details will follow in the coming weeks. As many of you know, several of our members (led by Erik, Jordan) have been leading the efforts to move to GitHub. Thats just the tip of the iceberg of improvements that are coming. If there are barriers to contribution levels, I want to help knock those down. If we cant knock them down, I want to navigate around them. How do I contact you? Email, g+, twitter are acceptable methods. If you get my phone number, thats also acceptable. Morse code is OK too, just give me enough time to brush up on my morse skills. If you feel inclined feel free to send me a direct email. But tell me what you like about Tianocore program, what you dont like, and what youre passionate about seeing implemented or not. You may include your view of any upcoming RPG titles, in particular Im very excited about Dark Souls 3 being released in April. Ill be at the March UEFI Plugfest in Taipei and the latter ones in addition to Linuxcon and other events. If theres an event that I should be, shoot me an email. More to come, but this is good for now. And if youre into twitter, follow @tianocore (I own that), and theres a Tianocore community on g+ now (https://goo.gl/YstPzT). You can also follow my personal twitter, g+ as well. Best Regards, Tony -- Tony Mangefeste Intel Corporation STO/SMC Community Technology Lead Tianocore Community Manager g+: https://goo.gl/l5B5JH t: @tonymangefeste ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
