-
Notifications
You must be signed in to change notification settings - Fork 6
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
Worth having a page of history of project homes, including latest greatest? #48
Comments
On a related note, in some case for the 'old homes', it would be nice if someone had permission to add a link to such a page, e.g. on the README for Github project https://github.com/Raynes/fs I do not know if that is possible, who might currently have write access, and/or what Github's policies might be for allowing edits to 'abandoned' projects. |
Yep, this would be great, I'm a big fan of this idea. Currently the clj-commons.org website doesn't really give much info on which projects have been adopted. I think it'd also be good to show who the maintainers are for different projects, ideally driven off of a
AFAIK this isn't supported, isaacs/github#1385 asks for a similar feature. In the cases where the original maintainer has transferred the repo to CLJ Commons, the old URL will redirect to the new one. I still think it's a good idea to list it, as people may recognise it, but clicking it will redirect to the new home. |
Are there currently any projects with a Or is that something you are hoping to add to clj-commons projects in the future? |
Ah, I think I found one in the tentacles repo here: https://github.com/clj-commons/tentacles/tree/master/.github I guess one question to ask is: Do you want the 'ground truth' for this data to come from files inside if each clj-commons repo, but it is OK to periodically run some process that extracts it from all clj-commons repos, and publishes it in one place? Or is it OK for the data's home to be in one single clj-commons repo? |
That would be ideal, but requires more work. In the first instance I'd be happy having the website be the home of this information, perhaps using something like Hugo which has data templates which we could use for this. |
So the following vector of maps, one per project, is a first quick draft of what such a data file could look like, of course with more data like that extracted from CODEOWNERS files added later, plus whatever else we think of. It would take only a fairly small amount of code to generate HTML/whatever for a web page for people to look at, from such data. It would also take only a fairly small amount of code to create a file like this from whatever files you might later decide should be a common convention for all clj-commons projects. Comments/questions welcome:
|
Another thought -- having this in data format could also be useful for a future enhancement to tools like |
There is a spec for handling this called relocation that Maven supports, though I've never seen it done, and Clojars doesn't support it AFAIK. Possibly having a manual data file to provide this info would be a useful short-term step for tools like lein-ancient though? |
I've created a |
For example, it could be a single page one could link to from all 'old home/README page' of projects when they transfer maintainership elsewhere, including to clj-commons, but perhaps having that page in one place would be useful for projects that transfer maintainership elsewhere besides clj-commons, too.
Example entry:
Project: fs
Current home: https://github.com/clj-commons/fs
Date transferred to current home: (Fill in a date that I do not know yet)
Former homes:
https://github.com/Raynes/fs
This is definitely the kind of thing that a more rigorous data model could be used to structure it, and that data programmatically accessed, if anyone had tools they thought would be useful to write for it, but at the very least having the information in text form would be a way for people to look for the latest greatest versions of things.
Thinking of corner cases for a moment, I understand there can be forks that diverge from a common point, so "latest greatest" isn't necessarily a uniquely defined thing. The page/data could represent such cases explicitly, perhaps even explicitly listing forks that seem not to be following the rules of the license of the original project from which they were derived, for a "here be licensing dragons" warning to people considering using the fork.
The text was updated successfully, but these errors were encountered: