4:30 p.m.
Hi all,
I have been keeping up with the threads surrounding the git forge move from
Pagure to Gitlab. There are three things I would like the council to
address:
Evaluating this situation, taking some time to document what went badly,
what maybe went well, how we can roll out decisions like this more
effectively in the future. Perhaps even writing something publicly so that
the community sees we see it went badly, and that we are listening.
For the teams that want to stay on Pagure, is that an option?
How do we ease the path of acceptance around Gitlab for those teams that
have to and/or want to move there. The decision to go with it has been
made. We need to help the community see, understand, and accept why the
decision was made, and then hopefully become inspired to contribute to it.
We are working against a lot for this second piece, though I have a couple
ideas. I would really love to get input from everyone else.
Looking forward to everyone's thoughts.
Best,
Marie Nordin
Fedora Community Action and Impact Coordinator
Red Hat <https://www.redhat.com/> • Fedora Project <https://getfedora.org/>
She/Her/Hers
T: +1.973.800.4967
IRC: riecatnor
<https://red.ht/sig>
4:48 p.m.
Hi Marie!
I know you are intending to start public, transparent discussion around
communication, but maybe to put this upfront to avoid steering
off-course, I assume that there was an affirmative decision to move
forward with GitLab over Pagure. :)
On 4/1/20 10:30 AM, Marie Nordin wrote:
How do we ease the path of acceptance around Gitlab for those teams
that
have to and/or want to move there. The decision to go with it has been
made. We need to help the community see, understand, and accept why the
decision was made, and then hopefully become inspired to contribute to
it. We are working against a lot for this second piece, though I have a
couple ideas. I would really love to get input from everyone else.
If I could make a single wish, it would be to migrate issues/PR history
from Pagure to GitLab.
From my perspective, I like GitLab over Pagure from features/tooling
perspective for issue management, which is what (most) non-software
teams use Pagure for. But the historical archive of issues, PRs, and git
commits is important to me. I can set up new labels, new workflows, and
get used to a new UI, but I can't reference historical discussions and
perspectives without going to an archived site and fishing out a link,
when today I can type #XYZ to reference something in less than five seconds.
When Fedorahosted/Trac was sunset, folks went to great lengths to write
a Python CLI tool to migrate Trac tickets to Pagure issues. This was
immensely helpful to me. While I would have liked some help to actually
move the Trac repos over to Pagure, just having a tool to go from Pagure
to GitLab would be dandy.
--
Cheers,
Justin W. Flory (he/him)
justinwflory.com
TZ=America/New_York
10:17 p.m.
On Wed, Apr 1, 2020 at 1:59 PM Justin W. Flory <jflory7(a)gmail.com> wrote:
I know you are intending to start public, transparent discussion around
communication, but maybe to put this upfront to avoid steering
off-course, I assume that there was an affirmative decision to move
forward with GitLab over Pagure. :)
Yes. See: https://communityblog.fedoraproject.org/making-a-git-forge-decision/
and several devel mailing list threads.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
5:03 p.m.
On Wed, Apr 1, 2020 at 10:31 AM Marie Nordin <mnordin(a)redhat.com> wrote:
Evaluating this situation, taking some time to document what went badly, what maybe went
well, how we can roll out decisions like this more effectively in the future. Perhaps even
writing something publicly so that the community sees we see it went badly, and that we
are listening.
Independently of what people think of the outcome, I think the
exercise of collecting and vetting user stories was good and we should
do this for future application-related decisions. As Matthew noted in
the meeting, we agreed in the past that "the Council is willing to
accept closed source or non-free tools in Fedora’s infrastructure
where free and open source tools are not viable or not available." Of
course, the definition of "viable" is open to a lot of debate. Having
a list of requirements (whether expressed as user stories or in some
other form) helps to make "viable" more clear. There's still room for
disagreement, of course, but at least there's a concrete starting
point.
For the teams that want to stay on Pagure, is that an option?
I don't see why not. In the same way that we allow teams to choose
what communication channels they use, they are also free to use what
git forge/issue tracker they choose.
How do we ease the path of acceptance around Gitlab for those teams
that have to and/or want to move there. The decision to go with it has been made. We need
to help the community see, understand, and accept why the decision was made, and then
hopefully become inspired to contribute to it. We are working against a lot for this
second piece, though I have a couple ideas. I would really love to get input from everyone
else.
We could have someone from GitLab be a guest on one of the upcoming
Council Video Meetings. Right now we're open from June on. If June is
too soon, we can schedule it for later.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1480
days inactive
1480
days old
council-discuss@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
Ben Cotton -
Justin W. Flory -
Marie Nordin