Jordan Justen
2015-07-09 18:09:12 UTC
Fork a new thread from the "BaseTools/GCC: allow unused but set
variables" thread...
I see they have a separate email list. I prefer to leverage the
edk2-devel list but use the alternate name field in the Cc. I've seen
another project use the main email list address, but alter the name to
ping stable branches.
So, for example, we could also consider:
Cc: UDK2014.SP1 <edk2-***@lists.sourceforge.net>
These can still be searched for, but don't require the hassle of a
separate email list. :)
the same when I saw Bill's answer.
Your idea about streamlining the current fixup process is a good one;
let's adopt it. Does it need to be codified somewhere (Maintainers.txt,
Contributions.txt, ...)?
I would say Maintainers.txt since it documents email addresses.
However, it might also want to list to a web page that explains it in
more detail.
I think we should hold off on it until we move to the new email list,
but maybe we can figure out a plan that sounds reasonable now.
-Jordan
variables" thread...
What about a lower bar for committing build break fixes? What if we
said that compiler warning fixes could be committed by any package
maintainer for any package as long as it is an obvious trivial fix and
it has at least one r-b?
That sounds pretty good to me!said that compiler warning fixes could be committed by any package
maintainer for any package as long as it is an obvious trivial fix and
it has at least one r-b?
I think qemu has a 'trivial' patch process. I can't remember the
details, but it may involve just Cc'ing the list with a different
http://wiki.qemu.org/Contribute/TrivialPatchesdetails, but it may involve just Cc'ing the list with a different
edk2-devel list but use the alternate name field in the Cc. I've seen
another project use the main email list address, but alter the name to
ping stable branches.
So, for example, we could also consider:
Cc: UDK2014.SP1 <edk2-***@lists.sourceforge.net>
These can still be searched for, but don't require the hassle of a
separate email list. :)
Anyway, I don't really support this build flag change, but I suppose
it could be acceptable for RELEASE builds.
I think Ard abandoned the idea on seeing Olivier's followup, and I didit could be acceptable for RELEASE builds.
the same when I saw Bill's answer.
Your idea about streamlining the current fixup process is a good one;
let's adopt it. Does it need to be codified somewhere (Maintainers.txt,
Contributions.txt, ...)?
However, it might also want to list to a web page that explains it in
more detail.
I think we should hold off on it until we move to the new email list,
but maybe we can figure out a plan that sounds reasonable now.
-Jordan