Last DNF-1 version, DNF-2 coming to rawhide

[Honza Silhan]

Hi,

DNF-1.1.10 and DNF-PLUGINS-CORE-0.1.21 has been released. Note this
will be the last version and only critical bug fixes will be
backported into DNF-1. Look into release notes [1][2] for more
details. DNF-2 (current DNF upstream) will be actively developed and
take the lead.

DNF-2 release candidate will land into rawhide. It will bring many new
features and bug fixes. DNF-2 is using libdnf instead of hawkey or
libhif. Unfortunately it brings some incompatibilities with previous
version which were either needed to preserve compatibility with yum
CLI or where bigger redesigns were needed (parsing command line
arguments). If you own any DNF plugin or component depending on DNF,
please, see the DNF-1 and DNF-2 changes [3] and adjust your package
accordingly. Moreover bump the DNF requirement as DNF honors semantic
versioning [4] to prevent future breakage when another major version
is deployed. To majority of components requiring
DNF in Fedora repository were sent patches to adapt them to DNF-2.

Thanks,
Honza


[1] http://dnf.baseurl.org/2016/08/22/dnf-1-1-10-and-dnf-plugins-core-0-1-21-...

[2] http://dnf.readthedocs.io/en/latest/release_notes.html#release-notes

[3] http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html

[4] http://dnf.readthedocs.io/en/latest/api.html#versioning

[Tomasz Torcz]

On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote:
>  
>  DNF-2 release candidate will land into rawhide. It will bring many new
>  features and bug fixes. DNF-2 is using libdnf instead of hawkey or
>  libhif. Unfortunately it brings some incompatibilities with previous
>  version which were either needed to preserve compatibility with yum
>  CLI or where bigger redesigns were needed (parsing command line
>  arguments). If you own any DNF plugin or component depending on DNF,
>  please, see the DNF-1 and DNF-2 changes [3] and adjust your package
>  accordingly. Moreover bump the DNF requirement as DNF honors semantic
>  versioning [4] to prevent future breakage when another major version
>  is deployed. To majority of components requiring
>  DNF in Fedora repository were sent patches to adapt them to DNF-2.
>   
  Sounds like this scope would warrant a Change?
  

-- 
Tomasz Torcz                 Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl                -- Baron Vladimir Harkonnen

[Honza Silhan]

On Fri, Sep 2, 2016 at 5:20 PM, Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>  On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote:
> >
> > DNF-2 release candidate will land into rawhide. It will bring many new
> > features and bug fixes. DNF-2 is using libdnf instead of hawkey or
> > libhif. Unfortunately it brings some incompatibilities with previous
> > version which were either needed to preserve compatibility with yum
> > CLI or where bigger redesigns were needed (parsing command line
> > arguments). If you own any DNF plugin or component depending on DNF,
> > please, see the DNF-1 and DNF-2 changes [3] and adjust your package
> > accordingly. Moreover bump the DNF requirement as DNF honors semantic
> > versioning [4] to prevent future breakage when another major version
> > is deployed. To majority of components requiring
> > DNF in Fedora repository were sent patches to adapt them to DNF-2.
> >
>
>    Sounds like this scope would warrant a Change? 
The components should be already prepared for DNF-2 and the changes
are not huge. There's the FESCO ticket [5]. If it is not accepted then
we will submit a Change.

Honza

[5] https://fedorahosted.org/fesco/ticket/1625

[Stephen Gallagher]

On 09/02/2016 11:52 AM, Honza Silhan wrote:
>  On Fri, Sep 2, 2016 at 5:20 PM, Tomasz Torcz
> <tomek(a)pipebreaker.pl&gt; wrote:
> > On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote:
> >>
> >> DNF-2 release candidate will land into rawhide. It will bring many new
> >> features and bug fixes. DNF-2 is using libdnf instead of hawkey or
> >> libhif. Unfortunately it brings some incompatibilities with previous
> >> version which were either needed to preserve compatibility with yum
> >> CLI or where bigger redesigns were needed (parsing command line
> >> arguments). If you own any DNF plugin or component depending on DNF,
> >> please, see the DNF-1 and DNF-2 changes [3] and adjust your package
> >> accordingly. Moreover bump the DNF requirement as DNF honors semantic
> >> versioning [4] to prevent future breakage when another major version
> >> is deployed. To majority of components requiring
> >> DNF in Fedora repository were sent patches to adapt them to DNF-2.
> >>
> >
> >   Sounds like this scope would warrant a Change?
>  
>  The components should be already prepared for DNF-2 and the changes
>  are not huge. There's the FESCO ticket [5]. If it is not accepted then
>  we will submit a Change.
>   
Actually, the preferred approach would be for this to come to FESCo *as* a
Change. Mostly because the Change Process requires you to explain the situation
fully and establish a contingency plan.

[Peter Robinson]

> >>> DNF-2 release candidate will land into rawhide. It will
> bring many new
> >>> features and bug fixes. DNF-2 is using libdnf instead of hawkey or
> >>> libhif. Unfortunately it brings some incompatibilities with previous
> >>> version which were either needed to preserve compatibility with yum
> >>> CLI or where bigger redesigns were needed (parsing command line
> >>> arguments). If you own any DNF plugin or component depending on DNF,
> >>> please, see the DNF-1 and DNF-2 changes [3] and adjust your package
> >>> accordingly. Moreover bump the DNF requirement as DNF honors semantic
> >>> versioning [4] to prevent future breakage when another major version
> >>> is deployed. To majority of components requiring
> >>> DNF in Fedora repository were sent patches to adapt them to DNF-2.
> >>>
> >>
> >>   Sounds like this scope would warrant a Change?
> >
> > The components should be already prepared for DNF-2 and the changes
> > are not huge. There's the FESCO ticket [5]. If it is not accepted then
> > we will submit a Change.
> >
>
>  Actually, the preferred approach would be for this to come to FESCo *as* a
>  Change. Mostly because the Change Process requires you to explain the situation
>  fully and establish a contingency plan. 
Completely agree, we (rel-eng and I'm sure others) don't want to find
out one day everything is broken due to this change and the compose is
up the spout. Core components such as dnf need to follow the process
properly and communicate far and wide so people are aware of the
changes in flight that could affect everything from builds to users
updating.

Peter

[Dominik 'Rathann' Mierzejewski]

On Friday, 02 September 2016 at 19:32, Peter Robinson wrote:
[...]
>  >>>   Sounds like this scope would warrant a Change?
>  >>
>  >> The components should be already prepared for DNF-2 and the changes
>  >> are not huge. There's the FESCO ticket [5]. If it is not accepted then
>  >> we will submit a Change.
>  >
>  > Actually, the preferred approach would be for this to come to FESCo *as* a
>  > Change. Mostly because the Change Process requires you to explain the situation
>  > fully and establish a contingency plan.
>  
>  Completely agree, we (rel-eng and I'm sure others) don't want to find
>  out one day everything is broken due to this change and the compose is
>  up the spout. Core components such as dnf need to follow the process
>  properly and communicate far and wide so people are aware of the
>  changes in flight that could affect everything from builds to users
>  updating. 
FESCo requested that a System Wide Change should be submitted for this.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Michal Luscon]

On 09/05/2016 03:52 PM, Dominik 'Rathann' Mierzejewski wrote:
>  On Friday, 02 September 2016 at 19:32, Peter Robinson wrote:
>  [...]
> >>>>    Sounds like this scope would warrant a Change?
> >>> The components should be already prepared for DNF-2 and the changes
> >>> are not huge. There's the FESCO ticket [5]. If it is not accepted then
> >>> we will submit a Change.
> >> Actually, the preferred approach would be for this to come to FESCo *as* a
> >> Change. Mostly because the Change Process requires you to explain the situation
> >> fully and establish a contingency plan.
> > Completely agree, we (rel-eng and I'm sure others) don't want to find
> > out one day everything is broken due to this change and the compose is
> > up the spout. Core components such as dnf need to follow the process
> > properly and communicate far and wide so people are aware of the
> > changes in flight that could affect everything from builds to users
> > updating.
>  FESCo requested that a System Wide Change should be submitted for this.
>
>  Regards,
>  Dominik 
Ok, we will file a System Wide Change then.

Thank you.

Michal

[Dominik 'Rathann' Mierzejewski]

On Monday, 05 September 2016 at 16:05, Michal Luscon wrote:
>  On 09/05/2016 03:52 PM, Dominik 'Rathann' Mierzejewski
> wrote:
>  > On Friday, 02 September 2016 at 19:32, Peter Robinson wrote:
>  > [...]
>  > > > > >    Sounds like this scope would warrant a Change?
>  > > > > The components should be already prepared for DNF-2 and the changes
>  > > > > are not huge. There's the FESCO ticket [5]. If it is not accepted
> then
>  > > > > we will submit a Change.
>  > > > Actually, the preferred approach would be for this to come to FESCo *as*
> a
>  > > > Change. Mostly because the Change Process requires you to explain the
> situation
>  > > > fully and establish a contingency plan.
>  > > Completely agree, we (rel-eng and I'm sure others) don't want to find
>  > > out one day everything is broken due to this change and the compose is
>  > > up the spout. Core components such as dnf need to follow the process
>  > > properly and communicate far and wide so people are aware of the
>  > > changes in flight that could affect everything from builds to users
>  > > updating.
>  > FESCo requested that a System Wide Change should be submitted for this.
>  > 
>  Ok, we will file a System Wide Change then. 
Excellent, thank you!

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Peter Robinson]

> >>>>>    Sounds like this scope would warrant a
> Change?
> >>>>
> >>>> The components should be already prepared for DNF-2 and the changes
> >>>> are not huge. There's the FESCO ticket [5]. If it is not accepted
> then
> >>>> we will submit a Change.
> >>>
> >>> Actually, the preferred approach would be for this to come to FESCo *as*
> >>> a
> >>> Change. Mostly because the Change Process requires you to explain the
> >>> situation
> >>> fully and establish a contingency plan.
> >>
> >> Completely agree, we (rel-eng and I'm sure others) don't want to find
> >> out one day everything is broken due to this change and the compose is
> >> up the spout. Core components such as dnf need to follow the process
> >> properly and communicate far and wide so people are aware of the
> >> changes in flight that could affect everything from builds to users
> >> updating.
> >
> > FESCo requested that a System Wide Change should be submitted for this.
> >
> > Regards,
> > Dominik
>
>  Ok, we will file a System Wide Change then. 
Yet it's not filed here [1] as a system wide change. Why? Given it's
the updates system there, at least IMO, needs to be full contingency
plans etc. Sorry, the history of the dnf team not breaking stuff even
on small bumps gives me little faith this will be smooth.

[1] https://fedoraproject.org/wiki/Changes/DNF-2.0

[Stephen Gallagher]

On 09/08/2016 07:05 AM, Peter Robinson wrote:
> >>>>>>    Sounds like this scope would warrant a
> Change?
> >>>>>
> >>>>> The components should be already prepared for DNF-2 and the changes
> >>>>> are not huge. There's the FESCO ticket [5]. If it is not accepted
> then
> >>>>> we will submit a Change.
> >>>>
> >>>> Actually, the preferred approach would be for this to come to FESCo *as*
> >>>> a
> >>>> Change. Mostly because the Change Process requires you to explain the
> >>>> situation
> >>>> fully and establish a contingency plan.
> >>>
> >>> Completely agree, we (rel-eng and I'm sure others) don't want to
> find
> >>> out one day everything is broken due to this change and the compose is
> >>> up the spout. Core components such as dnf need to follow the process
> >>> properly and communicate far and wide so people are aware of the
> >>> changes in flight that could affect everything from builds to users
> >>> updating.
> >>
> >> FESCo requested that a System Wide Change should be submitted for this.
> >>
> >> Regards,
> >> Dominik
> >
> > Ok, we will file a System Wide Change then.
>  
>  Yet it's not filed here [1] as a system wide change. Why? Given it's
>  the updates system there, at least IMO, needs to be full contingency
>  plans etc. Sorry, the history of the dnf team not breaking stuff even
>  on small bumps gives me little faith this will be smooth.
>  
>  [1] https://fedoraproject.org/wiki/Changes/DNF-2.0 

Give them a little time, Peter. It's still marked as ChangePageIncomplete :)

[Michal Luscon]

On 09/08/2016 01:05 PM, Peter Robinson wrote:
> >>>>>>     Sounds like this scope would warrant a
> Change?
> >>>>> The components should be already prepared for DNF-2 and the changes
> >>>>> are not huge. There's the FESCO ticket [5]. If it is not accepted
> then
> >>>>> we will submit a Change.
> >>>> Actually, the preferred approach would be for this to come to FESCo *as*
> >>>> a
> >>>> Change. Mostly because the Change Process requires you to explain the
> >>>> situation
> >>>> fully and establish a contingency plan.
> >>> Completely agree, we (rel-eng and I'm sure others) don't want to
> find
> >>> out one day everything is broken due to this change and the compose is
> >>> up the spout. Core components such as dnf need to follow the process
> >>> properly and communicate far and wide so people are aware of the
> >>> changes in flight that could affect everything from builds to users
> >>> updating.
> >> FESCo requested that a System Wide Change should be submitted for this.
> >>
> >> Regards,
> >> Dominik
> > Ok, we will file a System Wide Change then.
>  Yet it's not filed here [1] as a system wide change. Why? 
The change proposal
is in WIP state.

>  Given it's the updates system there, at least IMO, needs to be
> full contingency
>  plans etc. Sorry, the history of the dnf team not breaking stuff even
>  on small bumps gives me little faith this will be smooth. 
The internal DNF testing
stack undergone radical improvements during the 
last year. Core DNF functionality is now covered by functional tests. 
Therefore, we expect only minor issues with adoption of 2.0.

Michal

[Dominik 'Rathann' Mierzejewski]

On Thursday, 08 September 2016 at 13:37, Michal Luscon wrote:
>  On 09/08/2016 01:05 PM, Peter Robinson wrote: 
[...]
>  > Given it's the updates system there, at least IMO, needs to
> be full contingency
>  > plans etc. Sorry, the history of the dnf team not breaking stuff even
>  > on small bumps gives me little faith this will be smooth.
>  The internal DNF testing stack undergone radical improvements during the
>  last year. Core DNF functionality is now covered by functional tests. 
>  Therefore, we expect only minor issues with adoption of 2.0. 
Those are famous last word, you know. ;)

It's better to have a solid contingency plan and never use it than
not have it and be forced to scramble in the unlikely case something
goes wrong because you "expected only minor issues".

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Michal Luscon]

On 09/08/2016 01:48 PM, Dominik 'Rathann' Mierzejewski wrote:
>  On Thursday, 08 September 2016 at 13:37, Michal Luscon wrote:
> > On 09/08/2016 01:05 PM, Peter Robinson wrote:
>  [...]
> >> Given it's the updates system there, at least IMO, needs to be full
> contingency
> >> plans etc. Sorry, the history of the dnf team not breaking stuff even
> >> on small bumps gives me little faith this will be smooth.
> > The internal DNF testing stack undergone radical improvements during the
> > last year. Core DNF functionality is now covered by functional tests.
> > Therefore, we expect only minor issues with adoption of 2.0.
>  Those are famous last word, you know. ;)
>
>  It's better to have a solid contingency plan and never use it than
>  not have it and be forced to scramble in the unlikely case something
>  goes wrong because you "expected only minor issues".
>
>  Regards,
>  Dominik 
Yes, we are on the same page here.

Michal