[gentoo-dev] Hold on portage feature requests

[gentoo-dev] Hold on portage feature requests

[Jason Stubbs]

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

Hello all,

The subject says it all: no more feature requests for portage (the package
manager) until further notice. This does not include submitting of patches
that add new features. "Further notice" will likely mean when the next major
version of portage becomes stable.

The reason behind this is that at approximately two thirds of bugs received
are feature requests and they are drowning at the real bugs. More importantly,
the critical bugs are becoming very hard to keep track of. This, at a time
when we are focusing on fixing major and critical bugs only so as to get the
next version completed quicker.

Most of the current feature requests will be available at the time when the
next version goes stable (and that which isn't should be relatively painless
to implement) so don't worry that things will go stagnant.

However, if you are worried, I'll be posting a weekly summary of portage bug
activity to gentoo-portage-dev@gentoo.org from now on. If you'd like to join
the portage team or just feel like giving a quick hand, have a browse through
the bugs and see what fixes you can come up with.

-- 
Jason Stubbs

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

Re: [gentoo-dev] Hold on portage feature requests

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Stubbs wrote:

| The reason behind this is that at approximately two thirds of bugs
received
| are feature requests and they are drowning at the real bugs. More
importantly,
| the critical bugs are becoming very hard to keep track of. This, at a time
| when we are focusing on fixing major and critical bugs only so as to
get the
| next version completed quicker.

Are you having a tough time filtering out enhancements in your queries
or something? I don't understand how feature requests could possibly
interfere with anything besides other enhancements.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC6QZgXVaO67S1rtsRAqkKAJ4+/fQUkkYaUOXVmYGobLTRh+tHeACcDnHU
ZsYj4ABIrHcnoYHzLPOWmu4=
=36q7
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Hold on portage feature requests

[Alec Joseph Warner]

Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jason Stubbs wrote:
> 
> | The reason behind this is that at approximately two thirds of bugs
> received
> | are feature requests and they are drowning at the real bugs. More
> importantly,
> | the critical bugs are becoming very hard to keep track of. This, at a 
> time
> | when we are focusing on fixing major and critical bugs only so as to
> get the
> | next version completed quicker.
> 
> Are you having a tough time filtering out enhancements in your queries
> or something? I don't understand how feature requests could possibly
> interfere with anything besides other enhancements.
> 

Many of the enhancements aren't marked as such, dev-portage has a lot of 
bugs ( I've been watching it for 4 months ) and they are varied, old and 
  extremely difficult to manage at present.  As long as the bugs are 
still in bugzilla I din't see a problem with them being closed.

> Thanks,
> Donnie
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFC6QZgXVaO67S1rtsRAqkKAJ4+/fQUkkYaUOXVmYGobLTRh+tHeACcDnHU
> ZsYj4ABIrHcnoYHzLPOWmu4=
> =36q7
> -----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Hold on portage feature requests

[Brian D. Harring]

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

On Thu, Jul 28, 2005 at 09:22:56AM -0700, Donnie Berkholz wrote:
> Jason Stubbs wrote:
> 
> | The reason behind this is that at approximately two thirds of bugs
> received
> | are feature requests and they are drowning at the real bugs. More
> importantly,
> | the critical bugs are becoming very hard to keep track of. This, at a time
> | when we are focusing on fixing major and critical bugs only so as to
> get the
> | next version completed quicker.
> 
> Are you having a tough time filtering out enhancements in your queries
> or something? I don't understand how feature requests could possibly
> interfere with anything besides other enhancements.

Well... we have over 350 bugs open (roughly).  How do 
continual "we want xyz implemented" screw with things?  Dupes up the 
wing wang, lot of continual requests for the same thing, etc, lot of 
old bugs that need attention but get drowned out by new bugs (or new 
bugs that flat out miss old bugs due to their age).

Basically, this is a bit along the lines of trying to keep things 
easily filterable so that people who want to work on portage can 
quickly see what relevant (stable) bugs exist, and can dig up the 
feature requests (fricking multitude of them).

The feature requests aren't being ignored, the issue comes down to 
what I stated in an earlier email on this ml; with the current code, 
if it were easy to pull it off, we would do so without hesitation 
already- most of the features *can* be pulled off without too much 
hackery, but it requires (long needed) changes to portage innards.

Two main thrusts of work at this point, stable bug squashing, and 
rewriting sizable chunks of the underlying portagelib code so that the 
feature requests (sync per repo, seperated caches per repo, use deps, 
slot deps, EAPI changes, glep33, glep37 (potentially), better binpkg 
handling, drop md5/mtime as default for unmerge checks and use 
refcounts, framework for remote, etc) are doable.

Essentially it's squashing old noise on the bugs till we can actually 
address it.  Like I said above, two main thrusts of work are stable, 
and mangling the codebase so that we can actually pull this stuff off, 
and with the limited # of people hacking on portage, more time devoted 
to that the better.

So... yeah.  not dodging bugs, just need a way to do something about 
massive # of older bugs and noise on the bugs ml.  Man power issues 
somewhat, but mainly trying to focus on taking care of what needs to 
be taken care of right now.  Patches make a world of difference, since 
it A) involves people in the code, B) allows us to work on what needs 
to be addressed *now*, without digging about for a feature that in the 
grand scheme, doesn't matter too much.  Clarifiaction of B, which 
matters most in the long run, a UI change, or use deps?  Etc.

pardon the long winded explanation... It's something that has been 
toyed with for a while, and so far we (portage devs) seem to think 
it's a good way to at least get a handle on the current mess.
~harring

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

Re: [gentoo-dev] Hold on portage feature requests

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian D. Harring wrote:
| Essentially it's squashing old noise on the bugs till we can actually
| address it.  Like I said above, two main thrusts of work are stable,
| and mangling the codebase so that we can actually pull this stuff off,
| and with the limited # of people hacking on portage, more time devoted
| to that the better.

I definitely share your feeling on the limited number of people. But
what I think this will do is (1) nothing about the noise from bugs;
people will still post on them if it's LATER, and (2) produce a bunch of
dupes from people who are only searching for open bugs. So in my mind,
it has all the benefits of simply classifying enhancements correctly
plus the downside of actually creating more work.

Best of luck with it, though. Keep us posted on how it works.

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC6R4xXVaO67S1rtsRArbRAJ9CtEm7RvdjFFYBAd+0qlv0lTv3FQCfcLCA
bocASAAm08kY7uuJ7pA6zcc=
=AOCP
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Hold on portage feature requests

[R Hill]

Alec Joseph Warner wrote:
> Donnie Berkholz wrote:
>>
>> Are you having a tough time filtering out enhancements in your queries
>> or something? I don't understand how feature requests could possibly
>> interfere with anything besides other enhancements.
>>
> 
> Many of the enhancements aren't marked as such,

Then they should be. ;)  There's nothing wrong with reclassifying your 
bugs to make it easier to manage them.  The features are there exactly 
for this reason - so critical bugs don't get drowned out by less 
important bugs or enhancement requests.  I guess it doesn't really 
matter, but it would have been just as easy to set the severity of these 
bugs to min or enh rather than close them, and then they would still 
show up on a simple search.

The planned portage changes sound great.  I'll be looking forward to 
seeing them in action. :)

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Hold on portage feature requests

[Jason Stubbs]

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

On Monday 01 August 2005 02:07, R Hill wrote:
> Alec Joseph Warner wrote:
> > Donnie Berkholz wrote:
> >>
> >> Are you having a tough time filtering out enhancements in your queries
> >> or something? I don't understand how feature requests could possibly
> >> interfere with anything besides other enhancements.
> >>
> > 
> > Many of the enhancements aren't marked as such,
> 
> Then they should be. ;)  There's nothing wrong with reclassifying your 
> bugs to make it easier to manage them.  The features are there exactly 
> for this reason - so critical bugs don't get drowned out by less 
> important bugs or enhancement requests.  I guess it doesn't really 
> matter, but it would have been just as easy to set the severity of these 
> bugs to min or enh rather than close them, and then they would still 
> show up on a simple search.

Several people have asked why the available bug attributes don't suffice.
The reasons are quite simple:

1) Feature requests won't be addressed any time soon.

It was suggested that closing the bugs as LATER will cause more duplicates
and effect more work. I deferred (not closed!) 150 feature requests at least
a third of which were duplicates. Because feature requests are not being
addressed, they are piling up and users are not able to find duplicates
with the bugs being open anyway. However, publicizing that feature requests
have been put on hold has had the desired affect. There have been no new
requests this past week.

2) Every bug change has to be dealt with at least twice.

I try to monitor bugs via the emails sent as much as possible. With the
amount generated by new feature requests and the numerous "+1" posts on
existing requests, it is simply not feasible to parse the incoming mail
without making at least two passes. Here, I can hear people suggesting
that I just /dev/null the email and monitor bugs via bugzilla. My answer?
Opening listing 100+ bugs (that's assuming the bugs were properly categorized
(which they are not) - there is actually about 300 bugs open other than the
150 feature requests closed) as well as the bugs is a slow painful process
on a 32000bps connection.

3) To be able to utilize bug mails beyond notification.

I've written a simple script to create a report of what bugs have changed
and how many times within a set period. I'm posting the results to the
portage mailing list in order to try and fish out some fresh blood. Having
these reports littered with feature requests means that the important stuff
that is causing users problems is hidden between all the "oh wouldn't it be
lovely" bugs. Yes, this has also been successful already. There's been
patches posted on various bugs that actually fix the root cause of the
problems outlined.

4) Less user frustration.

The two most frequent comments at the moment are "is anybody looking at
this?" and "it's been over a year!" Users knowing what's going on and
especially finding that their minor bugs are starting to gain some activity
can only be a good thing.

I could figure out some more reasons if it's really necessary, but the past
week has shown that the path chosen (even if there is some better path) is
not a bad one as things are working out well thus far.

--
Jason Stubbs

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