Pagure.io as legacy codebases/distribution files/documentation hosting (Was: Moving cluster project)
(too old to reply)
Jan Pokorný
2017-03-02 23:12:15 UTC
[I've realized I should give a heads up to linux-cluster as well,
beside cluster-devel and developers-at-clusterlabs lists, especially
since I am reusing it's name for a projects group/namespace
in pagure.io]
So I think we should arrange for a move to pagure.io for this cluster
project as well if possible, if only to retain the ability to change
something should there be a need.
Good plan.
I can pursuit this if there are no complaints. Just let me know
(off-list) who aspires to cluster-maint group (to be created)
Could you give the gfs2-utils-maint group push access to the cluster project
once it's been set up? (It is possible to add many groups to a project.) I
think that would be the most logical way to do it.
Sure and thanks for a cumulative access assignment tip.
I'll proceed on Friday or early next week, then.
Well, scheduler of mine didn't get to it until now, so sorry
to anyone starting to worry.
- git repo moved over to https://pagure.io/linux-cluster/cluster
+ granted commit rights for gfs2-utils-maint group
(and will add some more folks to linux-cluster group,
feel free to bug me off-list about that)
+ mass-committed an explanation change to every branch at
the discontinued fedorahosted.org (fh.o) provider I could,
as some are already frozen
. I've decided to use a namespace (because there are possibly
more projects to be migrated under that label),
Actually, there are quite a few legacy project copied over, some
merely for plain archival bits-preserving:
[did I miss anything? AFAIK, gfs-utils and dlm components migrated
on their own, and corosync is on GitHub for years]

Actually also some components otherwise found under ClusterLabs label
(note that *-agents are common to both worlds) are affected, and for
that I created a separate ClusterLabs group on pagure.io:

The respective projects there are just envelopes that I used for
uploading distribution files and/or documentation that were so
far served by fedorahosted.org [*], not used for active code
hosting (at this time, anyway).

[*] locations like:
and have stuck with linux-cluster referring to the mailing list
of the same name that once actively served to discuss the
cluster stack in question (and is quite abandoned nowadays)
[i.e. this very list that I somehow originally ignored, sigh]
- quickly added backup location links at
https://fedorahosted.org/cluster/ and
I've converted the latter to Markdown and exposed at
The maintenance or just source access should be as simple as
cloning from ssh://***@pagure.io/docs/ClusterLabs/fence-agents.git
or https://pagure.io/docs/ClusterLabs/fence-agents.git, respectively.
i.e., the pages that seem most important to me, to allow for
smooth "forward compatibility"; the links currently refer to vain
stubs at ClusterLabs wiki, but that can be solved later on -- I am
still unsure if trac wikis at fh.o will be served in the next
phase or shut down right away and apparently this measure will
help only in the former case
Done for cluster:

Tarballs for split components from here will eventually be uploaded
to respective release directories for the particular projects, e.g.,
http://releases.pagure.org/ClusterLabs/fence-agents/, it's a WIP.
- possibly migrate some original wiki content to proper
"doc pages" exposed directly through pagure.io
So far I am just collecting the cluster wiki texts for possible
later ressurecting.
- resolve the question of the linked wiki stubs and
cross-linking as such
Any comments? Ideas?
Jan (Poki)