On Mon, Sep 24, 2018 at 7:04 AM Adam Samalik wrote:
> I thought about this for a while, and I can see some conceptual
> similarities between upgrading a major Fedora release and changing a module
> stream. I tried to think about major Fedora releases (I mean f28, f29, etc)
> as "streams" of Fedor
I thought about this for a while, and I can see some conceptual
similarities between upgrading a major Fedora release and changing a module
stream. I tried to think about major Fedora releases (I mean f28, f29, etc)
as "streams" of Fedora, the same way as streams of modules, with stable API.
Until
On 9/20/18 1:56 PM, Matthew Miller wrote:
> If it's "they'll find out when dnf system-upgrade errors out!", then see
> above. I'm ... not enthused. Something in dnf system-upgrade needs to do it;
> possibly a "dnf system-upgrade prep" step before "download".
I agree. Would it be feasible for the s
On Thu, Sep 20, 2018 at 04:20:49PM +0200, Adam Samalik wrote:
> > > And when that module is EOL, what is the user experience?
> > What I described in my reply earlier: the upgrade should not work and
> > the user should be required to switch to a new stream on their current
> > environment first. W
On Thu, Sep 20, 2018 at 09:35:41AM -0400, Stephen Gallagher wrote:
> > > Independently of this, you could also retire 1.7 with the end of F27 if
> > > there was no need to have it in the future releases.
> > Is there a way for users to say "keep me on whatever module is the default"
> > when upgrad
On Thu, Sep 20, 2018 at 9:12 AM Matthew Miller wrote:
>
> On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> > There is another concept in Modularity we can use here: defaults. You could
> > have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> > releases, but have dif
On Thu, Sep 20, 2018 at 4:17 PM Stephen Gallagher
wrote:
> On Thu, Sep 20, 2018 at 10:16 AM Matthew Miller
> wrote:
> >
> > On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > > > Is there a way for users to say "keep me on whatever module is the
> default"
> > > > when upgrading?
>
On Thu, Sep 20, 2018 at 10:16 AM Matthew Miller
wrote:
>
> On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > > Is there a way for users to say "keep me on whatever module is the
> > > default"
> > > when upgrading?
> > If they enable the module explicitly, they will keep that strea
On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > Is there a way for users to say "keep me on whatever module is the default"
> > when upgrading?
> If they enable the module explicitly, they will keep that stream,
> regardless of what the current defaults are.
And when that module i
On Thu, Sep 20, 2018 at 09:11:57AM -0400, Matthew Miller wrote:
> On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> > There is another concept in Modularity we can use here: defaults. You could
> > have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> > releases, but h
On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> There is another concept in Modularity we can use here: defaults. You could
> have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> releases, but have different default for each. So in your case, F27 could
> have 1.7 as
On Mon, Sep 17, 2018 at 12:20 PM Petr Šabata wrote:
> On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote:
> > This is a summary of a recent thread [1].
> >
> > Traditional branches (such as "f29") have their EOL (end of life) encoded
> > in the name. But what about stream branches [2] (
On Wed, Sep 12, 2018 at 10:19 PM Matthew Miller
wrote:
> On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote:
> > There would be a policy that a module can reach its EOL in the middle of
> a
> > Fedora release to prevent madness.
>
> Can or can't? I assume you mean "can't", because "can"
On Wed, Sep 12, 2018 at 10:54 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Tuesday, 11 September 2018 at 21:43, Richard Shaw wrote:
> [...]
> > This would take care of most of the complains about people using "git
> merge
> > master" across release branches (even though
On Tue, Sep 11, 2018 at 10:08 PM Richard Shaw wrote:
> On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik wrote:
>
>> On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw wrote:
>> As a packager, what is your experience with lifecycles of your packages?
>> Do you get a specific EOL date from the upstream? If
On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote:
> This is a summary of a recent thread [1].
>
> Traditional branches (such as "f29") have their EOL (end of life) encoded
> in the name. But what about stream branches [2] (such as "2.4" or "latest")?
>
> Stream branches of RPM package
On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote:
> There would be a policy that a module can reach its EOL in the middle of a
> Fedora release to prevent madness.
Can or can't? I assume you mean "can't", because "can" doesn't sound like
preventing madness. :)
--
Matthew Miller
Fe
On Tuesday, 11 September 2018 at 21:43, Richard Shaw wrote:
[...]
> This would take care of most of the complains about people using "git merge
> master" across release branches (even though that's the workflow documented
> in the wiki). I know I CAN use git cherry-pick but I've never used it
> bef
On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik wrote:
> On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw wrote:
> As a packager, what is your experience with lifecycles of your packages?
> Do you get a specific EOL date from the upstream? If not, at what
> circumstances you would retire an old version
On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw wrote:
> On Mon, Sep 3, 2018 at 8:36 AM Adam Samalik wrote:
>
>>
>> So... any comments to the concept? Any ideas about workflows or processes
>> of managing the EOL values?
>>
>
> Looking forward to this but I would say the devil is in the details.
> P
On Mon, Sep 3, 2018 at 8:36 AM Adam Samalik wrote:
>
> So... any comments to the concept? Any ideas about workflows or processes
> of managing the EOL values?
>
Looking forward to this but I would say the devil is in the details.
Packagers are not necessarily programmers (I include myself in thi
This is a summary of a recent thread [1].
Traditional branches (such as "f29") have their EOL (end of life) encoded
in the name. But what about stream branches [2] (such as "2.4" or "latest")?
Stream branches of RPM packages would always have an EOL associated with
them. The format would be on of
22 matches
Mail list logo
