On 09/06/2013 03:05 PM, Rob Crittenden wrote:
> Martin Kosek wrote:
>> On 09/05/2013 07:50 PM, Rob Crittenden wrote:
>>> Martin Kosek wrote:
>>>> On 08/29/2013 12:22 PM, Tomas Babej wrote:
>>>>> On 08/29/2013 11:55 AM, Petr Viktorin wrote:
>>>>>> On 08/28/2013 12:20 PM, Tomas Babej wrote:
>>>>>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote:
>>>>>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote:
>>>>>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote:
>>>>>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote:
>>>>>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group.
>>>>>>>>>>>> Please chime in if you're OK with package selection / description.
>>>>>>>>>>>> For illustration, see the attached image. FreeIPA will be added as 
>>>>>>>>>>>> an
>>>>>>>>>>>> add-on in an installer under the Infrastructure server environment,
>>>>>>>>>>>> that means, in the included images it will be at the same level
>>>>>>>>>>>> as DNS or FTP server.
>>>>>>>>>>>> It will also appear in the Software Selection tool (PackageKit).
>>>>>>>>>>>> It should also be available under as yum groupinstall "FreeIPA
>>>>>>>>>>>> server",
>>>>>>>>>>>> and in PackageKit, as I understand comps is also source for that 
>>>>>>>>>>>> too.
>>>>>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups
>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630
>>>>>>>>>>> IMO the Audit part in the description is false advertisement. Same
>>>>>>>>>>> issue is in package descriptions.
>>>>>>>>>> I know, it's taken directly from there.
>>>>>>>>>> I'd rather have it consistent, if we're going to change it here, we
>>>>>>>>>> should do
>>>>>>>>>> there too, so that we do not end up with multiple (seemingly
>>>>>>>>>> incomplete)
>>>>>>>>>> descriptions at various places.
>>>>>>>>> Anybody else does have any other concerns? We need to move with this
>>>>>>>>> effort since string freeze for F20 is coming.
>>>>>>>>> I'm particulary dubious about including the freeipa-tests package.
>>>>>>>> I don't think that should be included, developer tests are unnecessary
>>>>>>>> for a server.
>>>>>>> It was marked as optional in the initial proposal, but I agree it's
>>>>>>> unnecessary for
>>>>>>> it to be there at all.
>>>>>>>>> We discussed the A (as Audit) part in the description with Rob. The
>>>>>>>>> fact is
>>>>>>>>> that this is taken from the freeipa-server package description and
>>>>>>>>> nobody
>>>>>>>>> complained in 7 years.
>>>>>>> Updated tests attached.
>>>>>> Oh, one more thing I remembered just now -- is it too late?
>>>>>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as
>>>>>> default.
>>>>> I included it there.
>>>>> If anyone else wants to chime in, please do now, I'll create a ticket with
>>>>> rel-eng at the end of the day.
>>>> Thanks for this effort. What is the status of the bug - did you create the
>>>> request already?
>>>> We will need to do one more change and remove freeipa-server-strict 
>>>> package as
>>>> up on the decision on today's developer meeting we decided to drop this
>>>> subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous
>>>> Integration system instead.
>>> I missed that meeting so maybe I'm re-hashing things, but I don't see how CI
>>> solves the problem that the strict subpackage does. Sure, it won't be as 
>>> much a
>>> surprise to us when other packages are updated, but this doesn't prevent a 
>>> user
>>> from also updating to the package. The strict package prevents upgrade until
>>> we've confirmed that things are actually working. CI does not.
>> CI should prevent problems at the begging, before they happen - right when 
>> the
>> new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to
>> give negative Karma and have that package fixed before it hits stable 
>> updates.
>> IMO freeipa-server-strict subpackage is too heavy weight and does not provide
>> the benefit we would want. So far, IMHO, it was rather a burden for 
>> maintainers
>> and broke quite frequently.
> I'm not a huge fan of the strict package, I resisted it for a long time. But 
> it
> does serve its intended purpose: stability for users. I agree it is a pain,
> particularly in rawhide.

Yeah, this is exactly a point where I am not sure if it serves it's purpose. We
do not have some policy or official testing of new DS/CS/KRB releases. So I
just do not know when exactly should be update the strict package. After the
new DS version is used for a month in a community? Or after a smoke/unit test
performed ad-hoc by somebody in the team? I do not know.

But until we do that, we will have broken dependency.

> I guess I'm just not convinced that CI is going to catch everything.

I am not sure if the strict versioning makes a difference, given that version
is also bumped by a human/package maintainer who cannot catch everything either.


Freeipa-devel mailing list

Reply via email to