Here's a new GLEP submission: Architecture stability status file The current draft can be found at https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1002 If this looks OK to you please assign a GLEP number and copy (not move) it to the GLEP namespace. The topic has already been discussed on g-dev (and the GLEP is to a large extent identical to my last proposal there with some feedback worked in). So when it's got a number, I'm going to send it one last time to the list and then to the council...
Sure, GLEP 72.
Last draft has been committed. Please reopen when you have something new.
The last visible change for this GLEP was on 2017-05-06. Is there any activity going on? Otherwise, I suggest that we mark it as Deferred due to inactivity (per GLEP 28).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glep.git/commit/?id=f9555002655787d89af8b9a97a2b3702fc0831da commit f9555002655787d89af8b9a97a2b3702fc0831da Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-06-10 16:31:20 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-06-10 16:31:20 +0000 glep-0072: Deferred due to inactivity. Bug: https://bugs.gentoo.org/617612 Signed-off-by: Ulrich Müller <ulm@gentoo.org> glep-0072.rst | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
I've pushed the updated version to glep72-update branch. It's the same as on ml + changed transitional to request stabilization bugs as requested by dilfridge. If that's ok, please merge to master and I'll request Council vote then.
Rebased onto master and pushed.
Council, the new version of GLEP is now visible at: https://www.gentoo.org/glep/glep-0072.html Please vote on accepting it.
Vote: yes
(In reply to Michał Górny from comment #7) > Please vote on accepting it. I don't want to block progress on this, but given that the GLEP is in the making since 2017, is it suddenly so urgent that deviation from the regular work flow would be justified? GLEP 1 explicitly says that "GLEPs are then reviewed at a Council meeting".
(In reply to Ulrich Müller from comment #9) > (In reply to Michał Górny from comment #7) > > Please vote on accepting it. > > I don't want to block progress on this, but given that the GLEP is in the > making since 2017, is it suddenly so urgent that deviation from the regular > work flow would be justified? GLEP 1 explicitly says that "GLEPs are then > reviewed at a Council meeting". +1 Unless there's really an urgent reason, let's do this by the books and vote at the meeting in two weeks.
(In reply to Ulrich Müller from comment #9) > (In reply to Michał Górny from comment #7) > > Please vote on accepting it. > > I don't want to block progress on this, but given that the GLEP is in the > making since 2017, is it suddenly so urgent that deviation from the regular > work flow would be justified? GLEP 1 explicitly says that "GLEPs are then > reviewed at a Council meeting". eshowkw currently carries hack for one architecture. Two new ~arch arches are display incorrectly. ekeyword is completely broken and stabilizes completely wrong subset of arches. Is there really anything that's going to happen at the meeting? Some discussion that you're withholding from mailing lists? The idea of waiting for Council meeting to handle GLEPs is just silly, as all the discussion is supposed to happen publicly on the GLEP threads.
It is the workflow specified by GLEP 1, and its rationale is "to avoid the appearance of 'slipping' a GLEP in without proper public review by the Gentoo developer community." (In reply to Michał Górny from comment #11) > eshowkw currently carries hack for one architecture. Two new ~arch arches > are display incorrectly. ekeyword is completely broken and stabilizes > completely wrong subset of arches. No argument there. Then again, nothing prevents you from working on the implementation before the GLEP is formally approved.
Approved unanimously in todays meeting (6 yes, 1 absent)
Why was this bug closed? The GLEP is not final yet.
What is the status of the implementation? Can this GLEP be moved to "Final" status?
It's supported by current versions of gentoolkit (eshowkw) and pkgcore/pkgcheck. I think we didn't need any other implementation so far.
Ask the Council for final approval then?
Marked as Final per 2021-06-13 Council decision.
