[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Tomáš Chvátal]

Hi guys,
as I am now messing around libreo I am meeting a lot packages that
none bothered to stablereq since 2009 or so, the versions in ~ are
cleaner, more up to date, and possibly contain less bugs.

The issue here is that if some part of the tree looses lots of its
maintainers we as devs usually manage to shape it up enough for us in
testing but nobody ever bothers to wait that 30 days and open
stablereq.

So, the issue is obvious, we have packages in testing that are in
better shape than stable ones.

Testing requests for bumps are now handled by euscan +-, cool job for
that website by Iksaf, and I thing we need something similary scanning
the main tree for stables and instead of bugreports the arch
teams would have queue.

How would such thing work?

Well it would be something like priority based queue with maximum 60
points value.
Each update after the month in main tree would get 0 points for
stabilisation, any-developer / maintainer would be able to add up to
40 points to any package and security team members would be able to
add all 60 points. Security team/any developer would also have
possibility to add new packages to queue manualy.
Each user could vote for any package giving out 1 point up to 10
points (eg max voteup for 10 concurent packages).
For each folowing month the package would gain another 10 points,
unless disqualified by qa/maintainer where it has to be off the queue
for 1 month (or disqualified indefinetly based on some version range,
eg beta series is 2.5 so we don't want to stable).
Then arch team would just go and stabilise based up on the queue where
each AT or arch dev could mark it as working. If there are 3 acks from
Arch testers then even maintainer can proceed with the addition of the
keyword not having to wait for arch dev to test the package, reducing
the workload on arch devs (hopefully).

The key problem for whole app is that you need to make sure the queue
is a) properly sorted b) each request has proper depgraph so things
does not break for AT/devs.
This could be achieved by running the script and solving the depgraph
prior creating the request. Example:
We have stable possibility for harfbuzz and libreoffice, libreoffice
depends on harfbuzz.
The application would open just one stablerequest for libreoffice
where it would put everything pulled in by its depgraph including
harfbuzz and no separate request for harfbuzz is opened. If harfbuzz
would not be ready yet for stabilisation then the libreoffice would
not be YET added to the queue untill the harfbuzz passes the 30 days
too.

Here the queue of course have to differ for other arches as sparc have
keyword for harfbuzz but not libreoffice.

So do you thing it is possible to write such web app/ do you know if
anyone would be able to write so? If no I think I have proposal for
next GSoC as mentor :P but I would really like to see it sooner.

Cheers

Tom

PS: no i can't write it, I seriously lack a time for such thing so I
am just trying to find out if anyone is interested to work on it or if
you even thing this is a good idea.

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Tony "Chainsaw" Vroon]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote:
> Well it would be something like priority based queue with maximum 60
> points value.
> Each update after the month in main tree would get 0 points for
> stabilisation, any-developer / maintainer would be able to add up to
> 40 points to any package and security team members would be able to
> add all 60 points. Security team/any developer would also have
> possibility to add new packages to queue manualy. 

This sounds to me like you are trying to automate common sense. If you
see packages that have good ~arch ebuilds that appear to be fermenting,
please file a bug. Rumours of unresponsive arch teams have been greatly
exaggerated!

The worst that could happen is that a more exotic arch sees your bug and
decides "sorry, we would rather unkeyword it" rather than "okay, we will
stable that". Either way seems a valid outcome though?

I can't speak for other arches than AMD64, but we are happy to receive
more than the current influx of bugs, particularly if you are willing to
take suggestions to heart (a lot of QA niggles get shaken out in AT
reports lately).

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Tomáš Chvátal]

2011/9/20 Tony "Chainsaw" Vroon <chainsaw@gentoo.org>:
> On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote:
>> Well it would be something like priority based queue with maximum 60
>> points value.
>> Each update after the month in main tree would get 0 points for
>> stabilisation, any-developer / maintainer would be able to add up to
>> 40 points to any package and security team members would be able to
>> add all 60 points. Security team/any developer would also have
>> possibility to add new packages to queue manualy.
>
> This sounds to me like you are trying to automate common sense. If you
> see packages that have good ~arch ebuilds that appear to be fermenting,
> please file a bug. Rumours of unresponsive arch teams have been greatly
> exaggerated!
>
> The worst that could happen is that a more exotic arch sees your bug and
> decides "sorry, we would rather unkeyword it" rather than "okay, we will
> stable that". Either way seems a valid outcome though?
>
> I can't speak for other arches than AMD64, but we are happy to receive
> more than the current influx of bugs, particularly if you are willing to
> take suggestions to heart (a lot of QA niggles get shaken out in AT
> reports lately).
>
> Regards,
> Tony V.
>

I am not saying that Archs are unresponsive (well they are on ppc for
example sometimes) but I try to solve other problem about finding what
packages CAN go stable and nobody ever bothered to do a bugreport.

Yeah we can do it by hand like robot and open bugs for zilions of
packages just to get all the spell packages stable etc etc, but look
on the euscan, it is quite usefull to have automatically generated
report of what can you bump and what did you miss to update.

Instead of waiting on maintainer/anyone to notice that you can stable
something this would give you nice report itself.

And usually when i update and qa clean some package in 30 days I don't
even really remember which one it was :)

Tom

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Patrick Lauer]

On 09/20/11 23:18, Tomáš Chvátal wrote:
[snipped to bits]
> So, the issue is obvious, we have packages in testing that are in
> better shape than stable ones.
I'm aware that some of my packages could use a stablereq, but since I
don't run any stable machines at the moment it just never bothers me.


> Well it would be something like priority based queue with maximum 60
> points value.
> 
> So do you thing it is possible to write such web app/ do you know if
> anyone would be able to write so? If no I think I have proposal for
> next GSoC as mentor :P but I would really like to see it sooner.

Sounds like something that can be done, is not too complex ...

Maybe we should agree on some standards for such webapps so that they
are easy to support
- what languages / toolkits / frameworks does infra support / tolerate ?
- what data exchange formats can we define? There's things like
packages.g.o that already do parts of it, there's euscan and other
tools. Can we maybe unify that a bit?
- how do we coordinate people that want to help out?

For now I'll not be the one trying to carry such things forward, there's
enough other distractions for me at the moment. But I see what can be
done and think "that'd be, like, awesome" :)

Patrick

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Rich Freeman]

2011/9/20 Tomáš Chvátal <scarabeus@gentoo.org>:
> The issue here is that if some part of the tree looses lots of its
> maintainers we as devs usually manage to shape it up enough for us in
> testing but nobody ever bothers to wait that 30 days and open
> stablereq.

An issue your suggestion doesn't address is when packages don't even
stick around 30 days/etc.

I know I've seen many packages where there is an ancient stable
version that is never touched, and a much newer ~arch version that
gets tweaked every 3-6 weeks.  When it gets tweaked, often the old
version is just removed immediately, or shortly after it is bumped.
So, packages often don't stick around the 30 days it takes to
stabilize them.

Granted, this is a bit anecdotal so I can't speak for how big a
problem this is in reality.  However, for any stabilization scheme to
work packages have to be, well, stable.  :)

Rich

[gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Duncan]

Rich Freeman posted on Wed, 21 Sep 2011 10:46:38 -0400 as excerpted:

> An issue your suggestion doesn't address is when packages don't even
> stick around 30 days/etc.
> 
> I know I've seen many packages where there is an ancient stable version
> that is never touched, and a much newer ~arch version that gets tweaked
> every 3-6 weeks.  When it gets tweaked, often the old version is just
> removed immediately, or shortly after it is bumped. So, packages often
> don't stick around the 30 days it takes to stabilize them.
> 
> Granted, this is a bit anecdotal so I can't speak for how big a problem
> this is in reality.  However, for any stabilization scheme to work
> packages have to be, well, stable.  :)

Talking about...  Just today I was reading that the firefox folks are
debating shortening the current 6-week cycle to 5-weeks or less.

http://www.h-online.com/open/news/item/Mozilla-developers-consider-even-shorter-release-cycle-1347013.html

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Rich Freeman]

On Wed, Sep 21, 2011 at 11:57 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Talking about...  Just today I was reading that the firefox folks are
> debating shortening the current 6-week cycle to 5-weeks or less.

Upstream issues are a whole different kettle of fish, but obviously
still cause problems.  Online game clients tend not to become stable
now simply because they can suddenly stop working when the server
software is upgraded, requiring a rapid upgrade to the client.

Maybe we need to rethink the definition of "stable" in these
situations.  I think it still doesn't hurt to have some kind of QA
cycle internally for something like firefox.  Plus at least with
firefox the old versions don't suddenly stop working/etc, assuming
they still get upstream security notices.

Rich

[gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Duncan]

Rich Freeman posted on Wed, 21 Sep 2011 12:10:27 -0400 as excerpted:

> Plus at least with firefox the old versions don't suddenly stop
> working/etc, assuming they still get upstream security notices.

That's the thing.  AFAIK, they don't.  FF4 is still getting them I 
believe, due to longer term commitments made there, but from FF5 onward, 
no.  The upstream policy is that with rare urgent (0-day) exceptions like 
the recent bump for SSL certs invalidation that necessitate a mid-cycle 
bump, updates will be to the next major version.  Thus, once a new major 
version is out, previous versions are already considered vulnerable by 
definition and no further notices are given.

In fact, there has even been discussion of removing the numeric version 
info from the about box, etc.  It would say something like either "You 
are running the latest version" or "Updates are available and you are 
urged to upgrade", that's it.  However, from the coverage I've read, the 
current release manager, at least, decided that numeric version info 
would remain available.  (Partly, that was due to already getting push-
back on the 6-week-cycle and given that, someone having at least enough 
sanity not to push it all the way to binary current/not-current.)

So yes, either current stable policy will need to change, or Gentoo might 
as well give up on a stable firefox.  It's as if they're deliberately 
forcing the issue, strongly encouraging distros and their users to simply 
give up on distro versions entirely, and go direct-upstream-sourced pre-
compiled binaries.  I guess that's one way to solve the bundled library 
and patches vs. trademarks issues! =:^(  (Of course, firefox is more or 
less being pushed into it since chrome with its extremely similar 
policies, is eating their lunch ATM, thus all these chrome-clone policy 
changes.  Unfortunately, most of the world is still proprietary, and 
that's SOP in the proprietary world.)

... And I don't have a clue when the scheduled cutoff is, but ff4 won't 
be supported forever.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On 12:10 Wed 21 Sep 2011, Rich Freeman wrote:
> Maybe we need to rethink the definition of "stable" in these
> situations.  I think it still doesn't hurt to have some kind of QA
> cycle internally for something like firefox.  Plus at least with
> firefox the old versions don't suddenly stop working/etc, assuming
> they still get upstream security notices.

I agree that these new 'channel' concepts are not very compatible with
out stable/testing tree model and security stabilizations.  Every single
stabilization (except the first) of www-client/chromium for instance is
a security stabilization.  Chromium goes stable early and with the 'it's
a security-bug, small problems can be ingored'-hat on.

The reason that the same is not true for firefox is kind of stupid: They
provide security updates for their legacy version.  So in this case all
the bugs need to be considered and we don't stable version 6, 7, ...  in
a timely manner.

Cheers,
Thomas

-- 
Thomas Kahle 
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Rich Freeman]

On Wed, Sep 21, 2011 at 12:53 PM, Thomas Kahle <tomka@gentoo.org> wrote:
> I agree that these new 'channel' concepts are not very compatible with
> out stable/testing tree model and security stabilizations.  Every single
> stabilization (except the first) of www-client/chromium for instance is
> a security stabilization.  Chromium goes stable early and with the 'it's
> a security-bug, small problems can be ingored'-hat on.

If it gets too out of hand we could always do the Debian thing and
backport patches (but for a period of weeks to months, not moths to
years).  That obviously has problems of its own.

I get that if I want to be a btrfs pioneer I might have to live with
doing daily git updates or whatever.  What I don't get is that a
mainstream vendor should be pushing patches every third day.  And, on
linux I'd consider chromium more mainstream than chrome - especially
on Gentoo since we've decrufted it a bit.

I LIKE the contribution of linux distros, and I don't really want to
see a move towards the Windows world where I have 10 different
auto-updaters running (or worse - no auto-update and I'm just stuck
with manual checks).  I also don't like every browser having its own
copy of everything from libz to webkit to sqllite.

Rich

Re: [gentoo-dev] Re: [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On 13:37 Wed 21 Sep 2011, Rich Freeman wrote:
> I LIKE the contribution of linux distros, and I don't really want to
> see a move towards the Windows world where I have 10 different
> auto-updaters running (or worse - no auto-update and I'm just stuck
> with manual checks).  I also don't like every browser having its own
> copy of everything from libz to webkit to sqllite.

For chrome at least versions and updating are going to become invisible.
Google has indicated that they are going to do all the updating
invisibly in the background and once that is working they'll remove the
version number too.  They'll push the security fixes (and just whatever
they think enhances your browsing experience) directly to your computer.





-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]