Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wjwwood opened this issue Jun 26, 2013 · 7 comments
Open

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

wjwwood opened this issue Jun 26, 2013 · 7 comments
Assignees

Comments

@wjwwood
Copy link
Contributor

wjwwood commented Jun 26, 2013

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

See:

@wjwwood
Copy link
Contributor Author

wjwwood commented Jun 26, 2013

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

@wjwwood
Copy link
Contributor Author

wjwwood commented Jan 14, 2015

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
Copy link
Member

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
Copy link
Contributor Author

wjwwood commented Jan 14, 2015

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

@tfoote
Copy link
Member

tfoote commented Jan 14, 2015

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
Copy link
Contributor Author

wjwwood commented Jan 14, 2015

@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
Copy link
Contributor Author

wjwwood commented Jan 20, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants