Mailing List Archive

Jeroen Roovers wrote:
> Dear ebuild maintainers,
>
>
> thirty days is the norm for the minimal period between an ebuilds last
> non-keywording change while in the tree and the usual call for
> stabilisation. If you cannot find a pressing reason to push
> stabilisation forward, then don't ask. In the last few days I have seen
> several early calls for stabilisation (bugs #217148, #217845, #217841
> and #217839 for instance) where no adequate reason was given, in my
> opinion.

Given that 3 of the 4 are from one person, I wouldn't draw broad
conclusion from this.

> A good reason might be an important fix of a severe bug, a fix for a
> build problem that couldn't be applied to a stable version but had to
> go into an ebuild revision, or a version/revision that fixes a security
> problem.
>
> On the other hand, maybe these early stabilisation bug reports are a
> sign of the times and we need to shorten the normal thirty day period,
> become even more of a cutting edge distro - or at least discuss the
> options.

I'd say leave the current norm and smack the misbehaving maintainers :)

Caster
--
gentoo-dev@lists.gentoo.org mailing list

Vlastimil Babka wrote:
> Jeroen Roovers wrote:
>> On the other hand, maybe these early stabilisation bug reports are a
>> sign of the times and we need to shorten the normal thirty day period,
>> become even more of a cutting edge distro - or at least discuss the
>> options.
>
> I'd say leave the current norm and smack the misbehaving maintainers :)

++

The whole point of stable is that it ISN'T completely cutting edge, and
30 days is hardly super-stale. If there is a pressing need to
accelerate we should do so, but otherwise I'd stick to the general
policy. Anybody who wants cutting edge can use ACCEPT_KEYWORDS as desired.
--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
> > thirty days is the norm for the minimal period between an ebuilds last

It is the norm. It is not a requirement. In fact, it is specifically a
"guideline" rather than a hard rule. It is up to the maintainer's
discretion when to ask for stabilization, just like it is up to the arch
team's discretion when to actually *do* the stabilization. If you don't
think that it's ready on your arch, say so, but be prepared to defend
why you think so when the package maintainer, who should be much more
familiar with the package, thinks that it is ready.

> > On the other hand, maybe these early stabilisation bug reports are a
> > sign of the times and we need to shorten the normal thirty day period,
> > become even more of a cutting edge distro - or at least discuss the
> > options.
>
> I'd say leave the current norm and smack the misbehaving maintainers :)

Who says that they're misbehaving? Again, the maintainers probably know
their packages better than anyone else, so why are we not trusting their
judgement again?

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list

Wed, 16 Apr 2008 12:09:24 -0700
Chris Gianelloni <wolf31o2@gentoo.org> kirjoitti:

> On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
> > > thirty days is the norm for the minimal period between an ebuilds
> > > last
>
> It is the norm. It is not a requirement. In fact, it is
> specifically a "guideline" rather than a hard rule. It is up to the
> maintainer's discretion when to ask for stabilization, just like it
> is up to the arch team's discretion when to actually *do* the
> stabilization. If you don't think that it's ready on your arch, say
> so, but be prepared to defend why you think so when the package
> maintainer, who should be much more familiar with the package, thinks
> that it is ready.
>
> > > On the other hand, maybe these early stabilisation bug reports
> > > are a sign of the times and we need to shorten the normal thirty
> > > day period, become even more of a cutting edge distro - or at
> > > least discuss the options.
> >
> > I'd say leave the current norm and smack the misbehaving
> > maintainers :)
>
> Who says that they're misbehaving? Again, the maintainers probably
> know their packages better than anyone else, so why are we not
> trusting their judgement again?
>

Thanks for this, I was going to reply in similar fashion but didn't
want to (accidentally) start flaming..

- drac
--
gentoo-dev@lists.gentoo.org mailing list

Samuli Suominen wrote:
> Wed, 16 Apr 2008 12:09:24 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> kirjoitti:
>
>> On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
>>>> thirty days is the norm for the minimal period between an ebuilds
>>>> last
>> It is the norm. It is not a requirement. In fact, it is
>> specifically a "guideline" rather than a hard rule. It is up to the
>> maintainer's discretion when to ask for stabilization, just like it
>> is up to the arch team's discretion when to actually *do* the
>> stabilization. If you don't think that it's ready on your arch, say
>> so, but be prepared to defend why you think so when the package
>> maintainer, who should be much more familiar with the package, thinks
>> that it is ready.

Okay. So we can just agree it's better if the maintainer tells his
reasons when opening the bug, to spare the later clarifications?

>>>> On the other hand, maybe these early stabilisation bug reports
>>>> are a sign of the times and we need to shorten the normal thirty
>>>> day period, become even more of a cutting edge distro - or at
>>>> least discuss the options.
>>> I'd say leave the current norm and smack the misbehaving
>>> maintainers :)
>> Who says that they're misbehaving? Again, the maintainers probably
>> know their packages better than anyone else, so why are we not
>> trusting their judgement again?
>>
>
> Thanks for this, I was going to reply in similar fashion but didn't
> want to (accidentally) start flaming..

Sorry I used a harsh word myself, didn't want to flame neither.

Caster
--
gentoo-dev@lists.gentoo.org mailing list

Thu, 17 Apr 2008 09:43:59 +0200
Vlastimil Babka <caster@gentoo.org> kirjoitti:

> Okay. So we can just agree it's better if the maintainer tells his
> reasons when opening the bug, to spare the later clarifications?

"It works. Do it."

- drac
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, 17 Apr 2008 15:33:17 +0300
Samuli Suominen <drac@gentoo.org> wrote:

> Thu, 17 Apr 2008 09:43:59 +0200
> Vlastimil Babka <caster@gentoo.org> kirjoitti:
>
> > Okay. So we can just agree it's better if the maintainer tells his
> > reasons when opening the bug, to spare the later clarifications?
>
> "It works. Do it."

Then it will work just as well after a few more weeks. :)


Kind regards,
JeR
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, 17 Apr 2008 15:33:17 +0300
Samuli Suominen <drac@gentoo.org> wrote:

> "It works. Do it."

Oh by the way. This isn't directed toward you personally, but I
personally detest this "do it" attitude. You wouldn't say that to my
face, would you? (Trust me, you would regret it.) :)


JeR
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, 2008-04-17 at 19:38 +0200, Jeroen Roovers wrote:
> On Thu, 17 Apr 2008 15:33:17 +0300
> Samuli Suominen <drac@gentoo.org> wrote:
>
> > "It works. Do it."
>
> Oh by the way. This isn't directed toward you personally, but I
> personally detest this "do it" attitude. You wouldn't say that to my
> face, would you? (Trust me, you would regret it.) :)

What attitude do you prefer? How about the prevailing "let's talk about
it forever and do nothing" attitude, instead?

Seriously, we should be "doing it" much more than we should be sitting
around patting each other on the backs. We're not here to stroke each
other's egos. We're here to write software. Any chance we can get
ourselves back to getting things *done* and getting them done in a
decent time-frame? It's very simple. If you don't have time to do
something, don't do it. However, the common courtesy in such cases
would be to inform the requester of said time constraint, so he can
either adjust his expectations, or find someone else to do the work.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, 17 Apr 2008 11:04:36 -0700
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> On Thu, 2008-04-17 at 19:38 +0200, Jeroen Roovers wrote:
> > On Thu, 17 Apr 2008 15:33:17 +0300
> > Samuli Suominen <drac@gentoo.org> wrote:
> >
> > > "It works. Do it."
> >
> > Oh by the way. This isn't directed toward you personally, but I
> > personally detest this "do it" attitude. You wouldn't say that to my
> > face, would you? (Trust me, you would regret it.) :)

> Seriously, we should be "doing it" much more than we should be sitting
> around patting each other on the backs. We're not here to stroke each
> other's egos. We're here to write software.

The leap from Personal Dislikes to (almost, but not quite) Calling
Slacker puzzles me. I think it's not a path that needed treading.


Kind regards,
JeR
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen <drac@gentoo.org> wrote:
> Thu, 17 Apr 2008 09:43:59 +0200
> Vlastimil Babka <caster@gentoo.org> kirjoitti:
>
> > Okay. So we can just agree it's better if the maintainer tells his
> > reasons when opening the bug, to spare the later clarifications?
>
> "It works. Do it."
>

While I agree with you, and I think we are free to request
stabilization before the 30 days window, I also love when people give
details about the stabilization and not just a "do it".

Emacs team's "test plans" [1] are the better example. Thanks to them
I'm able to save a _lot_ of time figuring out how a package works and
which features should test.

Some details about changes since last stable are usually useful too.
In latest wgetpaste stabilization [2] we are told that this is a
trivial bugfix release fixing osl support, so we can just test osl
support and skip most of other tests.

Also, when a program needs a sample file with some obscure format, I
really appreciate when maintainers give a URL to a sample file so I
don't need to search for suitable files and can strictly focus on
testing.

Of course, everyone could continue with the "do it" style, but keep in
mind that adding info like I described above can save a lot of AT work
and, as a result, make stabilization process faster.

[1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans
[2] http://bugs.gentoo.org/show_bug.cgi?id=211894


Regards,
--
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
--
gentoo-dev@lists.gentoo.org mailing list

On Thu, Apr 17, 2008 at 09:40:22PM +0200, Santiago M. Mola wrote:
> On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen <drac@gentoo.org> wrote:
> > Thu, 17 Apr 2008 09:43:59 +0200
> > Vlastimil Babka <caster@gentoo.org> kirjoitti:
> >
> > > Okay. So we can just agree it's better if the maintainer tells his
> > > reasons when opening the bug, to spare the later clarifications?
> >
> > "It works. Do it."
> >
>
> While I agree with you, and I think we are free to request
> stabilization before the 30 days window, I also love when people give
> details about the stabilization and not just a "do it".
>
> Emacs team's "test plans" [1] are the better example. Thanks to them
> I'm able to save a _lot_ of time figuring out how a package works and
> which features should test.
>
> Some details about changes since last stable are usually useful too.
> In latest wgetpaste stabilization [2] we are told that this is a
> trivial bugfix release fixing osl support, so we can just test osl
> support and skip most of other tests.
++, this really helps the testing get done quicker.
> Also, when a program needs a sample file with some obscure format, I
> really appreciate when maintainers give a URL to a sample file so I
> don't need to search for suitable files and can strictly focus on
> testing.
Agreed, the fonts team link to a page using the fonts in the package,
which makes the package trivial to test. ++ to them.
>
> Of course, everyone could continue with the "do it" style, but keep in
> mind that adding info like I described above can save a lot of AT work
> and, as a result, make stabilization process faster.
Most of the time I see the "doit" bugs is when the package has broad
uses(i.e. coreutils and most things owned by base-system), and I
generally don't have a problem when the package has many various uses
that all had changes.
> [1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans
> [2] http://bugs.gentoo.org/show_bug.cgi?id=211894
>
>
> Regards,
> --
> Santiago M. Mola
> Jabber ID: cooldwind@gmail.com
> --
> gentoo-dev@lists.gentoo.org mailing list