Mark 101, 108, 113 as replaced, due to out of date

[wjwwood]

Mark 101, 108, 113 as replaced, due to out of date

See:

• http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

[wjwwood]

(reference http://ros.org/reps/rep-0122.html#id38 for load_manifest block)

[wjwwood]

Ok, so for each of these:

• 101, this is the release schedule for ROS 1.4, which is old, but as far as I know hasn't been replaced.
• 108, this defines the variants for diamondback, which are specific to diamondback but have sort of been replaced by REP-0142 which define new metapackages.
• 113, same as 108, but for electric

In each case, replaced doesn't seem appropriate, maybe retired or archived or inactive. I don't know. Should they be explicitly replaced by nothing? That seems like a misuse of the mechanism. I would guess we should have an inactive state for retired REP's which became "active". Thoughts?

[dirk-thomas]

If we don't want to introduce new states to the REP process we can just keep them as they are.

May be adding a note add the beginning mentioning that they are referring to an EOL ROS distro would help?

[wjwwood]

That's fine by me, any objections to just adding a message the beginning of each of these?

[tfoote]

Looking at the PEPs there's a section for Historical PEPs (in particular
Meta PEPs like these REPs) Since we're using their engine, I think there
must be a way to flag them as historical. I see final status on
informational ones both in historical and active.

They added the historical sorted section here:
https://hg.python.org/peps/rev/51d0f2905597
I think importing the changes from pep0 into rep0 should be considered.
https://hg.python.org/peps/file/59dfaaf19a14/pep0/output.py

On Tue, Jan 13, 2015 at 6:38 PM, William Woodall notifications@github.com
wrote:

That's fine by me, any objections to just adding a message the beginning
of each of these?

—
Reply to this email directly or view it on GitHub
#48 (comment)
.

[wjwwood]

@tfoote I agree we should track the PEP system, but from the first link it seems unresolved still:

Hack until the conflict between the use of "Final"

for both API definition PEPs and other (actually

obsolete) PEPs is addressed

Historical seems to only apply with Information reps if it isn't active and it doesn't have Release Schedule in the title:

https://hg.python.org/peps/file/59dfaaf19a14/pep0/output.py#l70

That seems pretty odd to me, and would mean that REP 101 would never be marked historical because of the title. It may also be possible to just modify our REP 0 to allow for explicitly setting something to historical.

I'm not sure what we should do, lets continue discussion here and make a decision at the next ROS team meeting.

[wjwwood]

We discussed this, we'll just add notes for now, and if someone has time we'll import upstream changes.