Hi distribution maintainers,
thank you for your feedback! This was valuable information.
Overall I think that it's worth the effort to try more releases. I think it
should help all the different distribution approaches. Those distributions
which are not able to deliver at that high rate: please
On Thu, Oct 29, 2015 at 9:11 AM, Sandro Knauß wrote:
> Moin,
Hi,
>
> Let's look at an example: we wanna push the patch releases to debian:
>
> On the one side we have unstable and testing. There the mantainer can upload
> most time a new version (if it is not frozen for the upcomming stable rele
Am 2015-10-28 21:11, schrieb Sandro Knauß:
But there is also debian stable (also kubuntu LTS,...), that most users
are
using. And debian stable is time based, and no updates are allowd by
default.
Debian stable should not be affected by the proposal. I doubt it will
ever ship a .0 or a .1 rel
Am 2015-10-28 19:27, schrieb Sandro Knauß:
Hey,
While l10n might not seem to be that important to you, it might be the
difference between an unusable system and a useable system. So let's
not
start downplaying the importance of translations ;-)
The point with translations is, if you change
On Wednesday, October 28, 2015 09:11:13 PM Sandro Knauß wrote:
> I see it more as meta informations about patches, to be able to use
> it as argument for pushing things more easily futher down to the user.
The git log contains this metainformation in the form of the BUG field.
--
sebas
http://w
Moin,
Let's look at an example: we wanna push the patch releases to debian:
On the one side we have unstable and testing. There the mantainer can upload
most time a new version (if it is not frozen for the upcomming stable release
~ three moth before the release). And any new version inside uns
On 28/10/15 14:49, Martin Gräßlin wrote:
>> So my suggestion would be to publish a 5.5 version and use the dot releases
>> to
>> publish bug fixes without a fixed schedule.
> Sorry I don't understand what you mean with that. Do you want a new bug fix
> release for each commit to stable branch? Th
Moin,
Let's look at an example: we wanna push the patch releases to debian:
On the one side we have unstable and testing. There the mantainer can upload
most time a new version (if it is not frozen for the upcomming stable release
~ three moth before the release). And any new version inside uns
Hey,
> While l10n might not seem to be that important to you, it might be the
> difference between an unusable system and a useable system. So let's not
> start downplaying the importance of translations ;-)
The point with translations is, if you change i18n strings in stable patches,
than you a
Am Mittwoch, 28. Oktober 2015, 14.00:03 schrieb Jonathan Riddell:
Morning Jonathan
> On Wed, Oct 28, 2015 at 02:49:34PM +0100, Martin Gräßlin wrote:
> > >We can keep up with bug fixes, in most cases the bugs will affect
> > >our users anyway and having the bug fixes released would reduce the time
Jonathan Riddell wrote:
> On Wed, Oct 28, 2015 at 02:49:34PM +0100, Martin Gräßlin wrote:
>>
>> understood. Maybe we can do some scripting to only create tarballs
>> if there were changes. Jonathan?
>
> It should be possible to only publish tars for modules that have got
> updates but the danger
On Wed, Oct 28, 2015 at 02:49:34PM +0100, Martin Gräßlin wrote:
> >We can keep up with bug fixes, in most cases the bugs will affect
> >our users anyway and having the bug fixes released would reduce the time
> >spent dealing with bugs, but it would be a waste of time and resources to
> >package th
Am 2015-10-28 13:34, schrieb Maximiliano Curia:
On 27/10/15 13:51, Martin Graesslin wrote:
I was thinking about the problem of how we can get bug fixes quicker
to our
user. With a three month release cycle a one-month bug fix cycle
sounds too
long to me.
Fair enough.
So I thought we should
On 27/10/15 13:51, Martin Graesslin wrote:
> I was thinking about the problem of how we can get bug fixes quicker to our
> user. With a three month release cycle a one-month bug fix cycle sounds too
> long to me.
Fair enough.
> So I thought we should make bug fix releases faster and more often.
On Tuesday, October 27, 2015 10:58:34 PM Albert Astals Cid wrote:
> El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
> > On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> > > El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> > >
> > > Yes, of course yes.
On Tuesday, October 27, 2015 06:05:48 PM Scott Kitterman wrote:
> On Tuesday, October 27, 2015 10:01:47 PM Luca Beltrame wrote:
> > Il Tue, 27 Oct 2015 14:18:01 -0700, Eric Hameleers ha scritto:
> > > No, of course not. I consider the git branch to be in eternal flux. The
> > > git HEAD may contain
On Wed, 28 Oct 2015, Martin Graesslin wrote:
On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
I like the idea of getting more visibility for bugfixes that will give
the enduser a better Plasma experience. Ideal for me would be a patch
tracker (not the same as a bug tracker) where
On Tuesday, October 27, 2015 10:03:43 PM CET tetr...@openmailbox.org wrote:
> Hi everyone,
>
> At first glance the proposed release schedule by Martin seems very
> dense, but Chakra should be able to keep up as the Plasma 5 builds do
> not take that long.
>
> The effort and automation required fo
On Tuesday, October 27, 2015 10:51:47 PM CET Heinz Wiesinger wrote:
> On Tuesday 27 October 2015 22:34:06 Albert Astals Cid wrote:
> > El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> > > On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> > > > On Tuesday, October 27, 2015 06:2
On Tuesday, October 27, 2015 2:18:01 PM CET Eric Hameleers wrote:
> On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> > On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> >> I like the idea of getting more visibility for bugfixes that will give
> >> the enduser a better Plasma experience
Il Tue, 27 Oct 2015 18:05:48 -0400, Scott Kitterman ha scritto:
> How does CI or automated testing prevent commits of marginal value in a
> stable branch (i.e. "meh stuff")?
I said "the majority of cases", not "all of cases". Nevertheless, meh stuff
or not, it is incorrect to assume that stable
El Tuesday 27 October 2015, a les 15:31:45, Eric Hameleers va escriure:
> On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> > El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
> >> On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> >>> El Tuesday 27 October 2015, a les 14:18:01, Er
On Tue, 27 Oct 2015, Albert Astals Cid wrote:
El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
On Tue, 27 Oct 2015, Albert Astals Cid wrote:
El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
On Tue, 27 Oct 2015, Sebastian Kügler wrote:
On Tuesday,
On Tuesday, October 27, 2015 10:01:47 PM Luca Beltrame wrote:
> Il Tue, 27 Oct 2015 14:18:01 -0700, Eric Hameleers ha scritto:
> > No, of course not. I consider the git branch to be in eternal flux. The
> > git HEAD may contain valuable usability patches but also other meh stuff
>
> Thanks to tech
Il Tue, 27 Oct 2015 14:18:01 -0700, Eric Hameleers ha scritto:
> No, of course not. I consider the git branch to be in eternal flux. The
> git HEAD may contain valuable usability patches but also other meh stuff
Thanks to technical (CI, automated testing) and social (widespread code
review) mea
El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
> On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> > El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> >> On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> >>> On Tuesday, October 27, 2015 06:25:42 AM Eric H
On Tuesday 27 October 2015 22:34:06 Albert Astals Cid wrote:
> El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> > On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> > > On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> > >> I like the idea of getting more visibil
On Tue, 27 Oct 2015, Albert Astals Cid wrote:
El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
On Tue, 27 Oct 2015, Sebastian Kügler wrote:
On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
I like the idea of getting more visibility for bugfixes that will g
El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> On Tue, 27 Oct 2015, Sebastian Kügler wrote:
> > On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> >> I like the idea of getting more visibility for bugfixes that will give
> >> the enduser a better Plasma expe
On Tue, 27 Oct 2015, Sebastian Kügler wrote:
On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
I like the idea of getting more visibility for bugfixes that will give
the enduser a better Plasma experience. Ideal for me would be a patch
tracker (not the same as a bug tracker) where
On 27-10-2015 13:51, Martin Graesslin wrote:
Hi distribution maintainers,
I was thinking about the problem of how we can get bug fixes quicker to
our
user. With a three month release cycle a one-month bug fix cycle sounds
too
long to me.
So I thought we should make bug fix releases faster an
On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> I like the idea of getting more visibility for bugfixes that will give
> the enduser a better Plasma experience. Ideal for me would be a patch
> tracker (not the same as a bug tracker) where intermediate patches are
> made availabl
On Tue, 27 Oct 2015, Martin Graesslin wrote:
On Tuesday, October 27, 2015 6:25:42 AM CET Eric Hameleers wrote:
On Tue, 27 Oct 2015, Martin Graesslin wrote:
Hi distribution maintainers,
I was thinking about the problem of how we can get bug fixes quicker to
our
user. With a three month release
On Tuesday, October 27, 2015 6:25:42 AM CET Eric Hameleers wrote:
> On Tue, 27 Oct 2015, Martin Graesslin wrote:
> > Hi distribution maintainers,
> >
> > I was thinking about the problem of how we can get bug fixes quicker to
> > our
> > user. With a three month release cycle a one-month bug fix c
On Tuesday, October 27, 2015 01:51:55 PM Martin Graesslin wrote:
> I was thinking about the problem of how we can get bug fixes quicker to our
> user. With a three month release cycle a one-month bug fix cycle sounds too
> long to me.
>
> So I thought we should make bug fix releases faster and mo
On Tue, 27 Oct 2015, Martin Graesslin wrote:
Hi distribution maintainers,
I was thinking about the problem of how we can get bug fixes quicker to our
user. With a three month release cycle a one-month bug fix cycle sounds too
long to me.
So I thought we should make bug fix releases faster and
Hi distribution maintainers,
I was thinking about the problem of how we can get bug fixes quicker to our
user. With a three month release cycle a one-month bug fix cycle sounds too
long to me.
So I thought we should make bug fix releases faster and more often. In 5.4 we
already went for this p
37 matches
Mail list logo
