On 4/9/14, 10:08 AM, Jan Lieskovsky wrote:
----- Original Message -----
> >From: "Josh Kayse"
> >Sent: Wednesday, April 9, 2014 3:48:10 PM
> >
> >Forgot to mention, thanks for starting this list.
No problem.
> >
> >On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky<jlieskov(a)redhat.com> wrote:
> >
>> > >----- Original Message -----
>>> > >>From: "Shawn Wells"<shawn(a)redhat.com>
>>> > >>Sent: Tuesday, April 8, 2014 7:53:38 PM
>>> > >>
>>> > >>On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
>>>> > >>>Just out of curiosity, what happened with this in the
end?
>>>> > >>>
>>>> > >>>I just noticed a few more suggestions that Github-style
pull requests
>>>> > >>>would be really useful.
>>> > >>
>>> > >>There were valid opinions expressed for both staying on
FedoraHosted and
>>> > >>migrating to GitHub. So, effectively, a stalemate.
>>> > >>
>>> > >>The SSG community has grown amazingly -- both in contributors
and usage
>>> > >>-- and because of this success Red Hat is preparing to ship SSG
in
>>> > >>future versions of RHEL [1]. This exacerbates the need for a
manageable
>>> > >>ticketing system with easy patch submission as very shortly
every RHEL
>>> > >>installation will have a copy of SSG. FedoraHosted simply
wasn't
>>> > >>designed to include the same tooling and developer ecosystem as
afforded
>>> > >>on GitHub (and that's NOT a ding against it's
designers!).
>>> > >>
>>> > >>The community is a coalition of the willing. Our shared purpose
drives
>>> > >>the community, and I strongly feel the need to build out tools
that will
>>> > >>allow us to scale. I'm concerned -- likely overly so -- at
how to
>>> > >>prepare for a wave of interest once we begin shipping in RHEL.
>>> > >>
>>> > >>With that said, who am I to*mandate* the migration to GitHub?
>>> > >>Admittedly part of me wants to just go ahead and do it, however
that
>>> > >>could come at making a non-trivial amount of people (esp.
committers,
>>> > >>who would be effected by the change) feel alienated/ignored.
Certainly
>>> > >>we can't make everyone happy all the time, though.
>>> > >>
>>> > >>Thoughts would be*most* welcome.
>> > >
>> > >I think the part problem of the stalemate you mention above being we
didn't
>> > >create the analysis yet:
>> > >* to identify current bottlenecks,
>> > >* to identify current features we need,
>> > >* to identify future features we might need to smoothly support scaling
>> > >etc.
>> > >
>> > >In my opinion it's strange to switch from one hosting vendor to the
another
>> > >without performing this. On one hand as you said the move will take
some
>> > >time /
>> > >resources, so the motivation should be clearly expressed why it's
worthy to
>> > >spend that time on the move (+ additional time current users to get
>> > >familiar
>> > >with the new scheme / process). On the other hand such analysis is
>> > >necessary
>> > >yet before we actually perform the move to know for sure, that the move
>> > >will
>> > >actually make the things better (that's why we need to identify the
>> > >bottlenecks).
For what it's worth, when I was playing around, importing the source
from FedoraHosted to GitHub was exceedingly trivial. It took just minutes.
IIRC, I refreshed my local repo, reset my remote origin URL in
.git/config to GitHub, and did a push.
Current commiters would need to do the same. Once the URL was updated
everything just worked. Also, as a wonderful surprise, it kept 'git log'
information in tact. If your GitHub EMail matches the one for prior
commits, everything syncs up.
>> > >
>> > >So instead of asking if we should move from Fedorahosted to GitHub, we
>> > >should
>> > >try to identify the list of items a smooth and easy patch proposal &
review
>> > >process should have. We can maintain that list on the mailing list
(within
>> > >this thread) or even create a dedicated wiki page for that (gathering
such
>> > >requirements
>> > >and allowing mailing list participants to offer enhancements).
>> > >
>> > >To start with such a list, the items which come to mind are as follows:
>> > >* bottlenecks:
>> > > - patch proposal / review process differs from GitHub's one =>
it's
>> > > non-trivial
>> > > for users accustomed to use GitHub way easy to flip to our scheme,
>> > >
>> > > - small ratio of using ticketing system functionality => new users
don't
>> > > have
>> > > a way how to find out list of issues currently being worked at or
find
>> > > the
>> > > most burning problem,
>> > >
>> > > - patch review process not separated by complexity of the fix (in
other
>> > > words
>> > > same rules are applied for simple typo fixes on one hand, while for
the
>> > > complex rewrites on the other. While obviously simple typo fixes /
fixes
>> > > not actually changing the functionality, but rather fixing some
error
>> > > [failing
>> > > make etc.] should have higher urgency and could have been [once
tested]
>> > > pushed
>> > > to the repository without the need for even one ACK),
>> > >
> >
> >I’d like to point out that tracking patches on the mailing list seems to be a
> >bottleneck. There have been multiple occasions where contributors have had
> >to remind the list of patch sets that need to be reviewed. This requires
> >the contributor to keep track of what patches need to be approved and what
> >mail message the patch is tied to.
Yes, this seems to be a big one. From what I have looked further, the fact
the patch might get lost / unnoticed without additional pings was (one of the)
reasons why Spacewalk project moved to GitHub from Fedorahosted too:
https://www.redhat.com/archives/spacewalk-devel/2014-February/msg00078.html
+1
> >
>> > > - missing user's roles on patch review process. One part what
Gerrit
>> > > brings (besides
>> > > the patches being available online without the need for additional
email
>> > > communication)
>> > > being the patch reviewer's role separation - there are users
with ad hoc
>> > > / a priori
>> > > permission to submit patches (selected into the group once they
provided
>> > > required
>> > > "level of trust") without the need to wait for ACKs (the
"core
>> > > upstream"). Then there
>> > > are occasional contributors who based on their time possibilities
might
>> > > comment on
>> > > particular issue / provide a patch for it, but who actually require
some
>> > > of the admins
>> > > to submit their patch into the repo after the review. I think this
point
>> > > the current
>> > > email communication doesn't allow us to implement.
>> > >
>> > >* the features:
>> > > …
> >
> >Based on some of the bottlenecks identified, I believe there needs to be a
> >tool that tracks patch submissions and their status. Additionally there
> >needs to be a ticketing system to identify what needs to be worked on.
Yeah, looks so (if we decide to stay at Fedorahosted).
We can setup a
gerrit.ssgproject.org for this purpose. I've arranged
free web hosting provided by Red Hat on OpenShift. We haven't utilized
it much though.
##
> >
>> > >* the future features:
>> > > - feel free to comment here what we are currently missing, and might
want
>> > > in the future
>> > > (what GitHub has support for, and Fedorahosted doesn't)
>> > >
>> > >Maybe once there is conclusion from this thread / more points, as
proposed
>> > >we should move
>> > >it to dedicated wiki page to track the already obtained consensus.
>> > >
>> > >Comments welcome.
>> > >
>> > >Thank you && Regards, Jan.
>> > >--
>> > >Jan iankko Lieskovsky / Red Hat Security Technologies Team
>> > >
>>> > >>
>>> > >>
>>> > >>[1]https://bugzilla.redhat.com/show_bug.cgi?id=1038655
>> > >_______________________________________________
--
Shawn Wells
Director, Innovation Programs
shawn(a)redhat.com | 443.534.0130
@shawndwells