[scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03)

[Honza Horak]

On 12/04/2014 07:39 PM, Petr Kovar wrote:
> Hi,
>
> On Thu, 04 Dec 2014 13:20:04 +0100
> Honza Horak <hhorak at redhat.com> wrote:
>
>> On 12/04/2014 09:53 AM, Radek Vokal wrote:
>>> On 12/03/2014 07:35 PM, Honza Horak wrote:
>>>> Initial content:
>>>>    * there were concerns what will happen with downstream collections
>>>> already in git.c.o -- we'll let the existing SCLs as they are now, at
>>>> least for beginning
>>>>    * the sig can/could/should provide them as a build (not priority for
>>>> beginning)
>>>>    * we should see what the biggest consumers need -- openshift origins
>>>> or foreman
>>>>    * since there is quite big demand for php and mariadb, we will begin
>>>> with those two collections
>>>>
>>>> New scl-utils:
>>>>    * next version of scl-utils will offer environment modules, but it is
>>>> not ready so far
>>>>
>>>> Access to git/koji:
>>>>    * since nobody objected against proposed git structure, we'll start
>>>> with what is proposed at
>>>> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal
>>>>    * in order to start we need to submit a bug with login, gpg public
>>>> key, email and request git/koji access for both services in parallel
>>>>    * in koji, alphacc is executioner on the koji setup, but mikem,
>>>> imcleod_ and MerlinTHP might be able to help as well
>>>>
>>>> Bug reporting:
>>>>    * we do not know how to track bugs so far
>>>
>>> Honzo, so what's the connection now to scl.org? Will build collections
>>> appear there eventually?
>>
>> I believe this is the best way to go, and at that point we don't need to
>> rebuild collections in copr any more, since it does not make sense to
>> build almost same collections twice. That would mean to add a new way to
>> sync bits from centos koji, but should not be hard to do.
>>
>>> Can the bug tracker be hosted there?
>>
>> It could. CentOS currently suggests to use bugs.centos.org [1], but
>> having a bug tracker on scl.org for all collections available there
>> (near where the bits are announced) makes sense to me.
>>
>> [1] http://wiki.centos.org/AdditionalResources/Repositories/SCL
>>
>>> I know we
>>> had a testing askbot instance at scl.org - should that be used for user
>>> feedback?
>>
>> You mean instead of proper bug tracker? We can give it a try and see if
>> it works.
>
> Docs recently discussed running an askbot instance at scl.org with the
> site maintainers and we thought it would be better to point people to
> stackoverflow where there is already a vivid community of people who might
> be interested in joining the scl community.

I wonder what the opinion of site maintainers was. From my PoV, that 
makes great sense to me, since using this kind of service depends mostly 
on community size.

The only disadvantage of using stackoverflow would be dividing content 
for RH's product RHSCL and non- scl.org (if we even care about that), 
which could be improved by proper tags used. Or are there some other issues?

> But then again, if we want to host an upstream bug tracker of some sort at
> scl.org, then that could give us a bit more traffic than before...

So, just couple of my thoughts, since I have no perfect solutions right 
now..
* we should have something else than RHSCL product in RHBZ, as it is 
defined right now, since there might be some collections missing and 
also content could be slightly different
* but if it could be located in RHBZ that would be beneficial since 
centos users are already used to report bugs there
* it should be common for centos and scl.org
* it should be easy (ideally less complicated than current setup of RHBZ 
for RHSCL)
* it should be transparent and clear how to report bugs

I've just found there is already something in RHBZ under Community 
project and I kind of like it simplicity:
https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.org

So, why not to use that one? Or is it something new we start using now?

Honza