Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 23:23:06 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 22:10:40 +0200 Michał Górny wrote:
> > On Thu, 16 Jun 2016 20:40:39 +0200
> > Fabian Groffen  wrote:
> >   
> > > On 16-06-2016 19:37:55 +0200, Michał Górny wrote:  
> > > > On Thu, 16 Jun 2016 18:52:32 +0200
> > > > Fabian Groffen  wrote:
> > > > 
> > > > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > > > since I'm already subscribed to the list.  
> > > > > > 
> > > > > > Please don't expect others to keep blacklists of people who can't
> > > > > > handle their mail properly, or to generally harm others and ignore 
> > > > > > good
> > > > > > practices because you can't handle your mail.  
> > > > > 
> > > > > You mean ignoring the Reply-To header is "good practice"?
> > > > 
> > > > It's not being ignored, as you can see by the occurrence of the mailing
> > > > list in CC.
> > > 
> > > From RFC 5322:
> > > 
> > > When the "Reply-To:" field is present, it indicates the address(es) to
> > > which the author of the message suggests that replies be sent.  In the
> > > absence of the "Reply-To:" field, replies SHOULD by default be sent to
> > > the mailbox(es) specified in the "From:" field unless otherwise
> > > specified by the person composing the reply.
> > > 
> > > In other words, you sent it to me, while I requested you to send it to
> > > the list.  
> > 
> > 'Suggests'. But if you insist, file a bug and stop bothering me. I'm
> > not maintaining nor developing any mail client.  
> 
> Claws mail definitely allows proper replies; just grep for
> X-Mailer header containing "Claws Mail" in this list and see how
> replies are made.
> 
> It looks like that problem is in how client is configured. That's
> why we are borthering you :)

If by 'proper replies', you mean not using 'reply all', then it's
a serious problem with the people using them. Anyway, your offtopic is
over on my end. If you have any more problems, please bother comrel.

-- 
Best regards,
Michał Górny



pgpxfpieA7O1t.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Andreas K. Huettel]

> > > Keeping the big pseudo-category split doesn't make much sense as most
> > > of the packages can't be fit easily into a specific group and it only
> > > confuses users. GNOME & KDE aren't very clear either, especially for
> > > non-core packages (like: is systemd a GNOME package?). Having them
> > > skip bug-wranglers doesn't sound really helpful.
> > 
> > Keeping the big desktop environments would be nice; anything that is a
> > large, logical group of packages maintained by one team.
> > 
> > Like, auto-assigning kde to kde and gnome to gnome.
> > 
> > Of course upstream doesn't really help with their destructive tendencies.
> > ("There is no KDE5, only Frameworks, Plasma and Applications.")
> 
> But there are non-core KDE apps that are not maintained by KDE team,
> and GNOME apps that are not maintained by GNOME team. Users usually
> don't check maintainers before choosing a component...

Well, the point of having a default assignee of categories is to remove load 
from the bug wranglers. [*]

(Who haven't pitched in yet here afaics, maybe we should hear them out.)

I see a value for a separate category if there is 

1) a user-recognizable large group of packages
2) that is to an overwhelming degree maintained (or at least co-maintained) by 
one project. 

About 1), examples would be 
* the packages of a large desktop environment (like KDE, Gnome, ...)
* the packages of fringe languages (like Haskell, Erlang, Java, ... :)

About 2) - even if a few packages are maintained by other people, the 
"wrangling" can be done by the project - who probably also know better what 
info to look for compared to the bugwranglers


[*] No, I'm NOT opposed to bug auto-assignment. I just think we should run and 
test it first, and once we've concluded that it works fine, then tear down our 
old auxiliary constructs. 

Usually you don't tear down the old bridge over the river before building the 
new one.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kristian Fiskerstrand]

On 06/16/2016 11:57 PM, Andreas K. Huettel wrote:
> How about introducing a state that explicitly means "resolved but needs 
> stabilization"? 

We already have InVCS keyword for this

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Andreas K. Huettel]

> 
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).
> 

Indeed. Kill VERIFIED with fire.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Andreas K. Huettel]

> 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 

Right now I dont think we agree what "RESOLVED" means. 

* Some people close bugs when there is an ~arch version that fixes them. 
* Some people wait until there is a stable version that fixes them. 

How about introducing a state that explicitly means "resolved but needs 
stabilization"? "NEEDSTABLE" or similar, with same resolutions as "RESOLVED"?

So, for a stable package a bug would go 
CONFIRMED -> NEEDSTABLE FIXED -> RESOLVED FIXED

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 22:10:40 +0200 Michał Górny wrote:
> On Thu, 16 Jun 2016 20:40:39 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> > > On Thu, 16 Jun 2016 18:52:32 +0200
> > > Fabian Groffen  wrote:
> > >   
> > > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:  
> > > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > > since I'm already subscribed to the list.
> > > > > 
> > > > > Please don't expect others to keep blacklists of people who can't
> > > > > handle their mail properly, or to generally harm others and ignore 
> > > > > good
> > > > > practices because you can't handle your mail.
> > > > 
> > > > You mean ignoring the Reply-To header is "good practice"?  
> > > 
> > > It's not being ignored, as you can see by the occurrence of the mailing
> > > list in CC.  
> > 
> > From RFC 5322:
> > 
> > When the "Reply-To:" field is present, it indicates the address(es) to
> > which the author of the message suggests that replies be sent.  In the
> > absence of the "Reply-To:" field, replies SHOULD by default be sent to
> > the mailbox(es) specified in the "From:" field unless otherwise
> > specified by the person composing the reply.
> > 
> > In other words, you sent it to me, while I requested you to send it to
> > the list.
> 
> 'Suggests'. But if you insist, file a bug and stop bothering me. I'm
> not maintaining nor developing any mail client.

Claws mail definitely allows proper replies; just grep for
X-Mailer header containing "Claws Mail" in this list and see how
replies are made.

It looks like that problem is in how client is configured. That's
why we are borthering you :)

Best regards,
Andrew Savchenko


pgpj6frn0Kxw9.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 20:40:39 +0200
Fabian Groffen  wrote:

> On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> > On Thu, 16 Jun 2016 18:52:32 +0200
> > Fabian Groffen  wrote:
> >   
> > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:  
> > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > since I'm already subscribed to the list.
> > > > 
> > > > Please don't expect others to keep blacklists of people who can't
> > > > handle their mail properly, or to generally harm others and ignore good
> > > > practices because you can't handle your mail.
> > > 
> > > You mean ignoring the Reply-To header is "good practice"?  
> > 
> > It's not being ignored, as you can see by the occurrence of the mailing
> > list in CC.  
> 
> From RFC 5322:
> 
> When the "Reply-To:" field is present, it indicates the address(es) to
> which the author of the message suggests that replies be sent.  In the
> absence of the "Reply-To:" field, replies SHOULD by default be sent to
> the mailbox(es) specified in the "From:" field unless otherwise
> specified by the person composing the reply.
> 
> In other words, you sent it to me, while I requested you to send it to
> the list.

'Suggests'. But if you insist, file a bug and stop bothering me. I'm
not maintaining nor developing any mail client.

-- 
Best regards,
Michał Górny



pgpymVmqeQkMO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 18:52:32 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > since I'm already subscribed to the list.  
> > > 
> > > Please don't expect others to keep blacklists of people who can't
> > > handle their mail properly, or to generally harm others and ignore good
> > > practices because you can't handle your mail.  
> > 
> > You mean ignoring the Reply-To header is "good practice"?
> 
> It's not being ignored, as you can see by the occurrence of the mailing
> list in CC.

From RFC 5322:

When the "Reply-To:" field is present, it indicates the address(es) to
which the author of the message suggests that replies be sent.  In the
absence of the "Reply-To:" field, replies SHOULD by default be sent to
the mailbox(es) specified in the "From:" field unless otherwise
specified by the person composing the reply.

In other words, you sent it to me, while I requested you to send it to
the list.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Paweł Hajdan , Jr .]

On 15/06/16 21:11, Michał Górny wrote:
> I would personally go for the following layout:
> 
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.

Sounds good to me.

Some cleanup is definitely due.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 18:52:32 +0200
Fabian Groffen  wrote:

> On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > since I'm already subscribed to the list.  
> > 
> > Please don't expect others to keep blacklists of people who can't
> > handle their mail properly, or to generally harm others and ignore good
> > practices because you can't handle your mail.  
> 
> You mean ignoring the Reply-To header is "good practice"?

It's not being ignored, as you can see by the occurrence of the mailing
list in CC.

-- 
Best regards,
Michał Górny



pgpj5AI7rLICI.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: kde-misc/akonadi-facebook

[Michael Palimaka]

# Michael Palimaka  (16 Jun 2016)
# No longer does anything. Masked for removal in 30 days.
# Bug 585786.
kde-misc/akonadi-facebook

OT: Mail handling (Was Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW)

[Andrew Savchenko]

On Thu, 16 Jun 2016 16:37:10 +0200 Michał Górny wrote:
> > P.S. Please don't CC me when replying to my e-mails on the list,
> > since I'm already subscribed to the list.
> 
> Please don't expect others to keep blacklists of people who can't
> handle their mail properly, or to generally harm others and ignore good
> practices because you can't handle your mail.

Why blacklisting? Just fix your mail client to honour Reply-to
header.

Best regards,
Andrew Savchenko


pgpgC7vggxciK.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > P.S. Please don't CC me when replying to my e-mails on the list,
> > since I'm already subscribed to the list.
> 
> Please don't expect others to keep blacklists of people who can't
> handle their mail properly, or to generally harm others and ignore good
> practices because you can't handle your mail.

You mean ignoring the Reply-To header is "good practice"?


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Michał Górny]

On Thu, 16 Jun 2016 09:40:53 -0500
james  wrote:

> On 06/16/2016 10:04 AM, Michał Górny wrote:
> > On Thu, 16 Jun 2016 08:59:44 -0500
> > james  wrote:
> >  
> >> On 06/16/2016 02:51 AM, Alexander Berntsen wrote:  
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>>
> >>> On 16/06/16 09:39, Daniel Campbell wrote:  
>  I guess what I mean is these outside developers could continue
>  hacking and/or breaking things, or whatever else, without worrying
>  about their "official" branch. We could have a standard that
>  assumes Gentoo pulls their 'master' branch and they keep other
>  stuff in 'dev', or some other model. We'll need to decide on *some*
>  branch, but putting it in writing would make things clearer for
>  prospective repo maintainers.  
> >>  
> >>> OK, then I think that it would be a good idea to have a gentoo-ci
> >>> branch, or similar, if the assumption is merely that this is where
> >>> Gentoo developers will look when evaluating your repository.
> >>>  
> >> Ok, if we go this route, here is a basic simple question. Why can't the
> >> "gentoo-ci" be a package, or group of packages that runs in a private
> >> persons own resources, regardless it is a single gentoo server or a
> >> small cluster (openstack)? That way, those gentoo-ciruns can be
> >> performed by the proxy or the author thus reducing the workload for QA
> >> or other devs.  I guess what I'm really asking is/will the gentoo-ci be
> >> packaged up for the gentoo community to use, on a small set of packages?  
> >
> > dev-util/pkgcheck is the QA tool used (you want -).
> >
> > https://github.com/gentoo/travis-repo-checks is the wrapper that is
> > used to run it in parallel. A lot of hackery, and master is outdated
> > for -. No time to fix it. The repo-mirror-ci branch is better but
> > then, I updated it recently for some local hacks.
> >
> > https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
> > to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
> > especially with the error & warning lists hardcoded.
> >
> > https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
> > used to run it all. No time to clean it up more than I already did.
> >  
> 
> EXCELLENT !  I seem to be mostly interested in orphaned, broken and 
> controversial packages these daysnot sure if that is a good thing or 
> not.
> 
> Do these ci tools work on gentoo snaps? [1]

I have no clue. And I doubt I'll be interested in testing that thing.

> [1] 
> http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

-- 
Best regards,
Michał Górny



pgpaVi2p9M_HX.pgp
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[james]

On 06/16/2016 10:04 AM, Michał Górny wrote:

On Thu, 16 Jun 2016 08:59:44 -0500
james  wrote:


On 06/16/2016 02:51 AM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:

I guess what I mean is these outside developers could continue
hacking and/or breaking things, or whatever else, without worrying
about their "official" branch. We could have a standard that
assumes Gentoo pulls their 'master' branch and they keep other
stuff in 'dev', or some other model. We'll need to decide on *some*
branch, but putting it in writing would make things clearer for
prospective repo maintainers.



OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.


Ok, if we go this route, here is a basic simple question. Why can't the
"gentoo-ci" be a package, or group of packages that runs in a private
persons own resources, regardless it is a single gentoo server or a
small cluster (openstack)? That way, those gentoo-ciruns can be
performed by the proxy or the author thus reducing the workload for QA
or other devs.  I guess what I'm really asking is/will the gentoo-ci be
packaged up for the gentoo community to use, on a small set of packages?


dev-util/pkgcheck is the QA tool used (you want -).

https://github.com/gentoo/travis-repo-checks is the wrapper that is
used to run it in parallel. A lot of hackery, and master is outdated
for -. No time to fix it. The repo-mirror-ci branch is better but
then, I updated it recently for some local hacks.

https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
especially with the error & warning lists hardcoded.

https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
used to run it all. No time to clean it up more than I already did.



EXCELLENT !  I seem to be mostly interested in orphaned, broken and 
controversial packages these daysnot sure if that is a good thing or 
not.


Do these ci tools work on gentoo snaps? [1]

thx,
James

[1] 
http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Michał Górny]

On Thu, 16 Jun 2016 08:59:44 -0500
james  wrote:

> On 06/16/2016 02:51 AM, Alexander Berntsen wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 16/06/16 09:39, Daniel Campbell wrote:  
> >> I guess what I mean is these outside developers could continue
> >> hacking and/or breaking things, or whatever else, without worrying
> >> about their "official" branch. We could have a standard that
> >> assumes Gentoo pulls their 'master' branch and they keep other
> >> stuff in 'dev', or some other model. We'll need to decide on *some*
> >> branch, but putting it in writing would make things clearer for
> >> prospective repo maintainers.  
> 
> > OK, then I think that it would be a good idea to have a gentoo-ci
> > branch, or similar, if the assumption is merely that this is where
> > Gentoo developers will look when evaluating your repository.
> >  
> Ok, if we go this route, here is a basic simple question. Why can't the
> "gentoo-ci" be a package, or group of packages that runs in a private
> persons own resources, regardless it is a single gentoo server or a 
> small cluster (openstack)? That way, those gentoo-ciruns can be 
> performed by the proxy or the author thus reducing the workload for QA 
> or other devs.  I guess what I'm really asking is/will the gentoo-ci be 
> packaged up for the gentoo community to use, on a small set of packages?

dev-util/pkgcheck is the QA tool used (you want -).

https://github.com/gentoo/travis-repo-checks is the wrapper that is
used to run it in parallel. A lot of hackery, and master is outdated
for -. No time to fix it. The repo-mirror-ci branch is better but
then, I updated it recently for some local hacks.

https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
especially with the error & warning lists hardcoded.

https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
used to run it all. No time to clean it up more than I already did.

-- 
Best regards,
Michał Górny



pgpUmPCchLKzJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Davide Pesavento]

On Thu, Jun 16, 2016 at 4:39 PM, Ian Stakenvicius  wrote:
> On 16/06/16 09:47 AM, Michał Górny wrote:
>> On Thu, 16 Jun 2016 16:22:32 +0300
>> Andrew Savchenko  wrote:
>>>
>>> CONFIRMED state is useful, it means that dev or powerful user
>>> confirmed this bug and gives it more value. I'd like to keep it.
>>
>> Are you saying that bugs that haven't been marked as CONFIRMED have
>> less value? Maybe they don't have to be handled at all, unless someone
>> you consider more worthy confirms them?
>>
>
> To me it's not about increased or decreased value per se, it's about
> workflow:
>
> - An UNCONFIRMED bug I have to reproduce myself and diagnose to
> determine if it's really a bug or if it's something else.
>
> - A CONFIRMED bug to me means this has already been done (by myself,
> others in the project, or dev's that should know the difference) and I
> can skip directly to identifying and fixing the issue.
>
> So when I look at the list of bugs for firefox I know what the state
> is more or less for things that are outstanding.  If I have just a
> little bit of time to hack away at things I'd rather try to close a
> CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
> don't have access to my dev system but have plenty of time, I may well
> try and triage UNCONFIRMED bugs.

+1

>
> IN_PROGRESS to me is something that should be reserved for when the
> fix is ready to go and just hasn't been fully applied or is readily
> available to all users (say, the fix is on an overlay for testing) --
> I would prefer not to start using that instead of CONFIRMED, but if
> that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
> merged to OPEN, I guess I could live with it.
>
>
>

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[james]

On 06/16/2016 02:51 AM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:

I guess what I mean is these outside developers could continue
hacking and/or breaking things, or whatever else, without worrying
about their "official" branch. We could have a standard that
assumes Gentoo pulls their 'master' branch and they keep other
stuff in 'dev', or some other model. We'll need to decide on *some*
branch, but putting it in writing would make things clearer for
prospective repo maintainers.



OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.


Ok, if we go this route, here is a basic simple question. Why can't the
"gentoo-ci" be a package, or group of packages that runs in a private
persons own resources, regardless it is a single gentoo server or a 
small cluster (openstack)? That way, those gentoo-ciruns can be 
performed by the proxy or the author thus reducing the workload for QA 
or other devs.  I guess what I'm really asking is/will the gentoo-ci be 
packaged up for the gentoo community to use, on a small set of packages?


Is that idea too difficult at this time?
Is there even a glep, or standard or part of PMS that will allow the 
gentoo-ci solution to become a routine tool for all to use?





Alexander
berna...@gentoo.org



curiously,
James

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kent Fredric]

On 17 June 2016 at 01:02, Michał Górny  wrote:
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.


Its also worth pointing out VERIFIED status annoyingly restricts a
package, and so any incorrect usage makes things worse.

Because you can't move an issue from VERIFIED back to CONFIRMED.

You instead have to move it to either RESOLVED or UNCONFIRMED, despite
neither of those being what you want.

( And that of course produces more bugspam )



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Ian Stakenvicius]

On 16/06/16 09:47 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 16:22:32 +0300
> Andrew Savchenko  wrote:
>>  
>> CONFIRMED state is useful, it means that dev or powerful user
>> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Are you saying that bugs that haven't been marked as CONFIRMED have
> less value? Maybe they don't have to be handled at all, unless someone
> you consider more worthy confirms them?
> 

To me it's not about increased or decreased value per se, it's about
workflow:

- An UNCONFIRMED bug I have to reproduce myself and diagnose to
determine if it's really a bug or if it's something else.

- A CONFIRMED bug to me means this has already been done (by myself,
others in the project, or dev's that should know the difference) and I
can skip directly to identifying and fixing the issue.

So when I look at the list of bugs for firefox I know what the state
is more or less for things that are outstanding.  If I have just a
little bit of time to hack away at things I'd rather try to close a
CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
don't have access to my dev system but have plenty of time, I may well
try and triage UNCONFIRMED bugs.

IN_PROGRESS to me is something that should be reserved for when the
fix is ready to go and just hasn't been fully applied or is readily
available to all users (say, the fix is on an overlay for testing) --
I would prefer not to start using that instead of CONFIRMED, but if
that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
merged to OPEN, I guess I could live with it.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 17:27:07 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 15:47:46 +0200 Michał Górny wrote:
> > On Thu, 16 Jun 2016 16:22:32 +0300
> > Andrew Savchenko  wrote:
> >   
> > > On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:  
> > > > Hello, everyone.
> > > > 
> > > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > > 
> > > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > > However, we use the two scarcely. I believe it would be beneficial to
> > > > replace the two with a single NEW state.
> > > > 
> > > > Rationale:
> > > > 
> > > > 1. Most of developers don't care about the two states, and which one
> > > > bugs are in.
> > > > 
> > > > 2. All bugs need to be handled the same, whether they were marked as
> > > > confirmed or not.
> > > > 
> > > > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > > > purpose to the UNCONFIRMED state in other Bugzillas.
> > > > 
> > > > 4. Some people who actually care about the two states change them,
> > > > causing unnecessary bugspam.
> > > > 
> > > > 5. Some users who think that the state matters get furious about bugs
> > > > staying in UNCONFIRMED for long.
> > > > 
> > > > Your thoughts?
> > >  
> > > CONFIRMED state is useful, it means that dev or powerful user
> > > confirmed this bug and gives it more value. I'd like to keep it.  
> > 
> > Are you saying that bugs that haven't been marked as CONFIRMED have
> > less value? Maybe they don't have to be handled at all, unless someone
> > you consider more worthy confirms them?  
>  
> Please don't exaggerate my words. "More value" doesn't imply that
> other bugs have no value. Under some conditions it means order
> of preference; e.g. if I'm not able to handle all bugs in a
> timeslot I have, but I am able to fix something, I may prefer
> confirmed bugs over unconfirmed ones, as bugs which are easier to
> reproduce and are likely to affect more users.
> 
> P.S. Please don't CC me when replying to my e-mails on the list,
> since I'm already subscribed to the list.

Please don't expect others to keep blacklists of people who can't
handle their mail properly, or to generally harm others and ignore good
practices because you can't handle your mail.

-- 
Best regards,
Michał Górny



pgpjbZy_3ds25.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Jason Zaman]

On Thu, Jun 16, 2016 at 03:32:03PM +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 16:18:20 +0300
> Andrew Savchenko  wrote:
> 
> > On Thu, 16 Jun 2016 14:04:19 +0200 Michał Górny wrote:
> > > On Wed, 15 Jun 2016 21:11:30 +0200
> > > Michał Górny  wrote:
> > >   
> > > > Right now we have the following components:
> > > > 
> > > > - Applications,
> > > > - baselayout,
> > > > - Core system,
> > > > - Development,
> > > > - Eclasses and Profiles,
> > > > - Games,
> > > > - GCC Porting,
> > > > - GNOME,
> > > > - Hardened,
> > > > - Java,
> > > > - KDE,
> > > > - Keywording & Stabilization,
> > > > - Library,
> > > > - New packages ('New ebuilds' previously),
> > > > - Printing,
> > > > - SELinux,
> > > > - Server,
> > > > - Unspecified.  
> > > 
> > > Revision two:
> > > 
> > > - Current packages [bug-wranglers@],
> > > - Eclasses [bug-wranglers@],
> > > - Hardened [hardened@],
> > > - New packages [bug-wranglers@],
> > > - Overlays [overlays@],
> > > - Profiles [bug-wranglers@],
> > > - SELinux [selinux@].  
> > 
> > Why hardened and selinux are separate?
> 
> It's in the rationale, below. It may make sense to stage bugs through
> Hardened/SELinux teams since not all developers have access to
> Hardened/SELinux systems. If that's not needed, I'm happy to drop them.

Yes, on behalf of both Hardened and SELinux, please keep those
components.

The bugs can be a problem with the hardening or SELinux policy in which
case we just fix it without bothering the maintainer who probably doesnt
even have an selinux system to test the changes. Sometimes there is an
actual bug in the package in which case we can easily involve the
maintainer or assign to them completely.

-- Jason

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 15:47:46 +0200 Michał Górny wrote:
> On Thu, 16 Jun 2016 16:22:32 +0300
> Andrew Savchenko  wrote:
> 
> > On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> > > Hello, everyone.
> > > 
> > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > 
> > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > However, we use the two scarcely. I believe it would be beneficial to
> > > replace the two with a single NEW state.
> > > 
> > > Rationale:
> > > 
> > > 1. Most of developers don't care about the two states, and which one
> > > bugs are in.
> > > 
> > > 2. All bugs need to be handled the same, whether they were marked as
> > > confirmed or not.
> > > 
> > > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > > purpose to the UNCONFIRMED state in other Bugzillas.
> > > 
> > > 4. Some people who actually care about the two states change them,
> > > causing unnecessary bugspam.
> > > 
> > > 5. Some users who think that the state matters get furious about bugs
> > > staying in UNCONFIRMED for long.
> > > 
> > > Your thoughts?  
> >  
> > CONFIRMED state is useful, it means that dev or powerful user
> > confirmed this bug and gives it more value. I'd like to keep it.
> 
> Are you saying that bugs that haven't been marked as CONFIRMED have
> less value? Maybe they don't have to be handled at all, unless someone
> you consider more worthy confirms them?
 
Please don't exaggerate my words. "More value" doesn't imply that
other bugs have no value. Under some conditions it means order
of preference; e.g. if I'm not able to handle all bugs in a
timeslot I have, but I am able to fix something, I may prefer
confirmed bugs over unconfirmed ones, as bugs which are easier to
reproduce and are likely to affect more users.

P.S. Please don't CC me when replying to my e-mails on the list,
since I'm already subscribed to the list.

Best regards,
Andrew Savchenko


pgpN82PAIPuK7.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Mike Gilbert]

On Thu, Jun 16, 2016 at 9:52 AM, Joshua Kinard  wrote:
> It'd be nice if, when replying in a comment, a flag
> could be made available to automatically to state that "I've encountered this
> issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
> changes the state to CONFIRMED, but doesn't bugspam on this specific state 
> change.

That sounds like the Voting extension, which we already have enabled.
Not sure what the threshold is set to, however.

https://www.bugzilla.org/docs/4.0/en/html/voting.html

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kent Fredric]

On 17 June 2016 at 01:52, Joshua Kinard  wrote:
> because
> sometimes, issues can get reported that are really obscure and, for example,
> tied to a particular hardware configuration, thus cannot be easily and
> independently confirmed


Isn't that why "RESOLVED: Need Info" exists?

Or is "CONFIRMED" supposed to imply "I can replicate this", as opposed
to the description bugzilla uses: "Determined to be present". (
https://bugzilla.readthedocs.io/en/5.0/_images/bzLifecycle.png )

Our current doc only describes CONFIRMED vs UNCONFIRMED in terms of
"valid" and its predominantly used as a "Can't triage" :

> UNCONFIRMED: This bug has recently been added to the database.|
> Nobody has confirmed that this bug is valid.
> Users who have the "canconfirm" permission set may confirm this bug, changing 
> its state to CONFIRMED.
> Or, it may be directly resolved and marked RESOLVED.

> CONFIRMED: This bug is valid and has recently been filed.
> Bugs in this state become IN_PROGRESS when somebody is working on them, or 
> become resolved and marked RESOLVED.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Michał Górny]

On Thu, 16 Jun 2016 09:47:12 -0400
Joshua Kinard  wrote:

> On 06/16/2016 08:04, Michał Górny wrote:
> > On Wed, 15 Jun 2016 21:11:30 +0200
> > Michał Górny  wrote:
> >   
> >> Right now we have the following components:
> >>
> >> - Applications,
> >> - baselayout,
> >> - Core system,
> >> - Development,
> >> - Eclasses and Profiles,
> >> - Games,
> >> - GCC Porting,
> >> - GNOME,
> >> - Hardened,
> >> - Java,
> >> - KDE,
> >> - Keywording & Stabilization,
> >> - Library,
> >> - New packages ('New ebuilds' previously),
> >> - Printing,
> >> - SELinux,
> >> - Server,
> >> - Unspecified.  
> > 
> > Revision two:
> > 
> > - Current packages [bug-wranglers@],
> > - Eclasses [bug-wranglers@],
> > - Hardened [hardened@],
> > - New packages [bug-wranglers@],
> > - Overlays [overlays@],
> > - Profiles [bug-wranglers@],
> > - SELinux [selinux@].
> > 
> > Major changes:
> > 
> > 1. collapsed all category-like components into a single 'Current
> > packages' that is the default component for pretty much every bug
> > related to 'standard' configurations of Gentoo Linux -- making it easy
> > to choose the correct one and ensuring everything goes through
> > bug-wranglers;
> > 
> > 2. split 'eclasses & profiles' into two separate categories -- mainly
> > intended for developer use;
> > 
> > 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> > product) as the non-standard system configurations that desire staging
> > the bugs through respective teams,
> > 
> > 4. left 'New packages' as-is, as category for requesting addition
> > of packages not yet in Gentoo,
> > 
> > 5. added 'Overlays' component for bugs filed against packages
> > in third-party repositories (right now some of them got filed pretty
> > randomly, and having them in Infra->Overlays is kinda wrong),
> > 
> > 6. removed 'Keywording & stabilization'. As pointed out, those can be
> > handled via keywords and we already do stabilizations in other places
> > (e.g. security bugs).
> > 
> > Your thoughts about this one?  
> 
> I'd add at least an entry for "Toolchain" and route it to the toolchain@g.o
> address by default.  Most users know to assign a majority of gcc-related or
> binutils-related bugs to toolchain anyways.

Do they? Is it common for them to report bugs in toolchain rather than
problems caused by toolchain upgrade that are actually bugs in code?

>  Not sure if gcc-porting should be
> broken out, though.  That is a separate alias that's targeted at working out
> issues on newer gcc releases and/or new capabilities.

That was my initial thought too. However, then I noticed it actually
goes to bug-wranglers@...

> I could think of others, like one for Gentoo/Alt, for the FreeBSD and other
> ports that kinda do their own thing.  Linux alt-archs can get sorted out by
> bug-wranglers.

Gentoo/Alt has its own separate product. Not that this decreases
confusion but that's how things are right now...

-- 
Best regards,
Michał Górny



pgpIyu0V4QEVK.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[M. J. Everitt]

On 16/06/16 14:19, James Le Cuirot wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand  wrote:
>
>>> What I'd like to introduce instead is a new STABILIZED state. It
>>> would -- like VERIFIED now -- be only available for bugs already
>>> RESOLVED, and it could be used to signify that the fix has made it
>>> into stable.
>>>
>>> While this wouldn't be really obligatory, it would be meaningful for
>>> trackers that need to ensure that fixes in packages have made it to
>>> stable -- like the functions.sh use tracker.
>> The description of InVCS keyword in bugzilla is:
>> InVCSFix has been added to a VCS(either CVS, SVN, Git, ...)
>> repository. Will be closed when fixes are applied to a stable level
>> package.
>>
>> A bug isn't resolved until it is fixed in a stable package (for
>> packages ever in stable to begin with), but InVCS keyword can be used
>> by developers to filter out the bugs for issues to work with. I
>> oppose a change to that behavior, although I would like to see it
>> being used more consistently as it seems quite a few developers are
>> neglecting the stable tree.
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.
>
Possibly a 'COMMITTED' tag would fit this slightly better? There is room
for some QA 'VERIFIED' tag too, but don't know whether this is
absolutely necessary for Gentoo .. thoughts welcomed, though.

I prefer this Lifecycle diagram to that published in the latest docs:
https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[M. J. Everitt]

On 16/06/16 14:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
>
> Best regards,
> Andrew Savchenko
I think CONFIRMED is useful too, particularly if it shows that the
problem is easily reproducible (ie. either a wrangler/dev/proxy has
actually run the sequence of command as per report, and has replicated
the issue).

ASSIGNED should be the 'default' phase for a bug, after is has been
wrangled. See https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html
for some useful (but not all necessary) states.

I suggest an approximate workflow of NEW->ASSIGNED->CONFIRMED->IN
PROGRESS->RESOLVED/CLOSED/etc.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Joshua Kinard]

On 06/16/2016 09:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Best regards,
> Andrew Savchenko

+1 here, too.  UNCONFIRMED should be the default for new bugs, because
sometimes, issues can get reported that are really obscure and, for example,
tied to a particular hardware configuration, thus cannot be easily and
independently confirmed.  It'd be nice if, when replying in a comment, a flag
could be made available to automatically to state that "I've encountered this
issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
changes the state to CONFIRMED, but doesn't bugspam on this specific state 
change.

Also, +1 to changing UNRESOLVED to OPEN.

Don't suppose we can get a RESOLVED::RTFM, can we? :)

(I'm kidding)

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 16:22:32 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> > Hello, everyone.
> > 
> > Here's my second RFC wrt bugs.gentoo.org redesign.
> > 
> > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > However, we use the two scarcely. I believe it would be beneficial to
> > replace the two with a single NEW state.
> > 
> > Rationale:
> > 
> > 1. Most of developers don't care about the two states, and which one
> > bugs are in.
> > 
> > 2. All bugs need to be handled the same, whether they were marked as
> > confirmed or not.
> > 
> > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > purpose to the UNCONFIRMED state in other Bugzillas.
> > 
> > 4. Some people who actually care about the two states change them,
> > causing unnecessary bugspam.
> > 
> > 5. Some users who think that the state matters get furious about bugs
> > staying in UNCONFIRMED for long.
> > 
> > Your thoughts?  
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.

Are you saying that bugs that haven't been marked as CONFIRMED have
less value? Maybe they don't have to be handled at all, unless someone
you consider more worthy confirms them?

-- 
Best regards,
Michał Górny



pgp4HhIc0h6Vy.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Joshua Kinard]

On 06/16/2016 08:04, Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
> 
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
> 
> Revision two:
> 
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
> 
> Major changes:
> 
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
> 
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
> 
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
> 
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
> 
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
> 
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
> 
> Your thoughts about this one?

I'd add at least an entry for "Toolchain" and route it to the toolchain@g.o
address by default.  Most users know to assign a majority of gcc-related or
binutils-related bugs to toolchain anyways.  Not sure if gcc-porting should be
broken out, though.  That is a separate alias that's targeted at working out
issues on newer gcc releases and/or new capabilities.

I could think of others, like one for Gentoo/Alt, for the FreeBSD and other
ports that kinda do their own thing.  Linux alt-archs can get sorted out by
bug-wranglers.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Michał Górny]

On Thu, 16 Jun 2016 16:18:20 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 14:04:19 +0200 Michał Górny wrote:
> > On Wed, 15 Jun 2016 21:11:30 +0200
> > Michał Górny  wrote:
> >   
> > > Right now we have the following components:
> > > 
> > > - Applications,
> > > - baselayout,
> > > - Core system,
> > > - Development,
> > > - Eclasses and Profiles,
> > > - Games,
> > > - GCC Porting,
> > > - GNOME,
> > > - Hardened,
> > > - Java,
> > > - KDE,
> > > - Keywording & Stabilization,
> > > - Library,
> > > - New packages ('New ebuilds' previously),
> > > - Printing,
> > > - SELinux,
> > > - Server,
> > > - Unspecified.  
> > 
> > Revision two:
> > 
> > - Current packages [bug-wranglers@],
> > - Eclasses [bug-wranglers@],
> > - Hardened [hardened@],
> > - New packages [bug-wranglers@],
> > - Overlays [overlays@],
> > - Profiles [bug-wranglers@],
> > - SELinux [selinux@].  
> 
> Why hardened and selinux are separate?

It's in the rationale, below. It may make sense to stage bugs through
Hardened/SELinux teams since not all developers have access to
Hardened/SELinux systems. If that's not needed, I'm happy to drop them.

-- 
Best regards,
Michał Górny



pgpeVrcBQssXJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kristian Fiskerstrand]

On 06/16/2016 02:56 PM, Kent Fredric wrote:
> On 17 June 2016 at 00:51, Michał Górny  wrote:
>> We could also use plain 'OPEN' ;-).
> 
> 
> +1. I was going to suggest the same.
> 

Bug is still open even if it is IN_PROGRESS or not in stable. But I
currently make use of the UNCONFIRMED / CONFIRMED distinction as well ,
CONFIRMED often in relation to UPSTREAM keyword that I'm not actively
working on myself

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Andrew Savchenko]

On Thu, 16 Jun 2016 15:02:13 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> Here's the third bugs.g.o redesign RFC.
> 
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
> 
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
> 
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
> 
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

+1 Burn it with fire :)
 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.

Wouldn't this bug create even more burden for stabilization process?
Each fix will eventually go into stable when newer version will get
stabilized.

Best regards,
Andrew Savchenko


pgp3rNhohBqTV.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> Here's my second RFC wrt bugs.gentoo.org redesign.
> 
> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> However, we use the two scarcely. I believe it would be beneficial to
> replace the two with a single NEW state.
> 
> Rationale:
> 
> 1. Most of developers don't care about the two states, and which one
> bugs are in.
> 
> 2. All bugs need to be handled the same, whether they were marked as
> confirmed or not.
> 
> 3. We stage bugs through bug-wranglers@ which kinda has a similar
> purpose to the UNCONFIRMED state in other Bugzillas.
> 
> 4. Some people who actually care about the two states change them,
> causing unnecessary bugspam.
> 
> 5. Some users who think that the state matters get furious about bugs
> staying in UNCONFIRMED for long.
> 
> Your thoughts?
 
CONFIRMED state is useful, it means that dev or powerful user
confirmed this bug and gives it more value. I'd like to keep it.

Best regards,
Andrew Savchenko


pgpqpzjzJbEL2.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kristian Fiskerstrand]

On 06/16/2016 03:19 PM, James Le Cuirot wrote:
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.

Exactly

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[James Le Cuirot]

On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand  wrote:

> > What I'd like to introduce instead is a new STABILIZED state. It
> > would -- like VERIFIED now -- be only available for bugs already
> > RESOLVED, and it could be used to signify that the fix has made it
> > into stable.
> > 
> > While this wouldn't be really obligatory, it would be meaningful for
> > trackers that need to ensure that fixes in packages have made it to
> > stable -- like the functions.sh use tracker.
> 
> The description of InVCS keyword in bugzilla is:
> InVCS Fix has been added to a VCS(either CVS, SVN, Git, ...)
> repository. Will be closed when fixes are applied to a stable level
> package.
> 
> A bug isn't resolved until it is fixed in a stable package (for
> packages ever in stable to begin with), but InVCS keyword can be used
> by developers to filter out the bugs for issues to work with. I
> oppose a change to that behavior, although I would like to see it
> being used more consistently as it seems quite a few developers are
> neglecting the stable tree.

I currently set InVCS for pending-stable fixes in conjunction with the
IN_PROGRESS state. I would like to keep InVCS at least.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Andrew Savchenko]

On Thu, 16 Jun 2016 14:04:19 +0200 Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
> 
> > Right now we have the following components:
> > 
> > - Applications,
> > - baselayout,
> > - Core system,
> > - Development,
> > - Eclasses and Profiles,
> > - Games,
> > - GCC Porting,
> > - GNOME,
> > - Hardened,
> > - Java,
> > - KDE,
> > - Keywording & Stabilization,
> > - Library,
> > - New packages ('New ebuilds' previously),
> > - Printing,
> > - SELinux,
> > - Server,
> > - Unspecified.
> 
> Revision two:
> 
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].

Why hardened and selinux are separate?
Having large classes like core/kde/gnome was good too imho.

Looks fine otherwise.

Best regards,
Andrew Savchenko


pgpJfPfgWJZ_R.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Davide Pesavento]

On Thu, Jun 16, 2016 at 3:02 PM, Michał Górny  wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
>
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
>
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

Agreed. However I don't see a strong reason to remove it, unless its
removal simplifies the introduction of STABILIZED. If it's useful to
some people, let them use it.

>
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
>
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.

Makes sense, although, as you said yourself, if it's not used
consistently it cannot be relied upon. Besides, we already have a
mechanism for expressing this, we make the stable request bug block
the tracker.

Thanks,
Davide

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kristian Fiskerstrand]

On 06/16/2016 03:02 PM, Michał Górny wrote:
> Hello, everyone.
> 



> 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.
> 

The description of InVCS keyword in bugzilla is:
InVCS   Fix has been added to a VCS(either CVS, SVN, Git, ...)
repository. Will be closed when fixes are applied to a stable level package.

A bug isn't resolved until it is fixed in a stable package (for packages
ever in stable to begin with), but InVCS keyword can be used by
developers to filter out the bugs for issues to work with. I oppose a
change to that behavior, although I would like to see it being used more
consistently as it seems quite a few developers are neglecting the
stable tree.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Michał Górny]

Hello, everyone.

Here's the third bugs.g.o redesign RFC.

This time it's about closed bugs. Right now we have two states for
them: RESOLVED and VERIFIED.

RESOLVED is the usual state that the developers use when they close
a bug. It's also the only state that could be directly transferred from
other states.

VERIFIED is used scarcely, and not really consistently. It can only be
used on RESOLVED bugs, and sometimes users use it to confirm that
the bug is resolved.

To be honest, I don't really see the need for VERIFIED state. Since
it's used scarcely, it can't be really relied upon. Some users use it
completely incorrectly (e.g. when the bug should be reopened instead).

What I'd like to introduce instead is a new STABILIZED state. It would
-- like VERIFIED now -- be only available for bugs already RESOLVED,
and it could be used to signify that the fix has made it into stable.

While this wouldn't be really obligatory, it would be meaningful for
trackers that need to ensure that fixes in packages have made it to
stable -- like the functions.sh use tracker.

-- 
Best regards,
Michał Górny



pgpGOAf8gP2k_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Kent Fredric]

On 17 June 2016 at 00:04, Michał Górny  wrote:
> Revision two:
>
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].


"Overlays" seems a little vague as descriptor, might make people think
"bugs relating to the overlays" ( ie: like mirroring etc ) as opposed
to "Packages in overlays", which might lead people to choose "Current
Packages" instead.

Also, the sort ordering by alphabetical seems an annoying limitation,
because things at the top of the list are more likely to be seen ( and
used ).

Ideally you want a sort order like this:

> - Current packages [bug-wranglers@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],

> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].


Because IME, those top 3 are what you're going to want the most of.

But I don't know how to make that work.






-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kent Fredric]

On 17 June 2016 at 00:51, Michał Górny  wrote:
> We could also use plain 'OPEN' ;-).


+1. I was going to suggest the same.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 14:51:26 +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 14:41:43 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> > > Hello, everyone.
> > > 
> > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > 
> > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > However, we use the two scarcely. I believe it would be beneficial to
> > > replace the two with a single NEW state.  
> > ... 
> > > Your thoughts?  
> > 
> > How about UNRESOLVED instead?  Else you get bugs which are NEW for years
> > even though they have activity all over.
> 
> We could also use plain 'OPEN' ;-).

Works for me too.

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 14:41:43 +0200
Fabian Groffen  wrote:

> On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> > Hello, everyone.
> > 
> > Here's my second RFC wrt bugs.gentoo.org redesign.
> > 
> > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > However, we use the two scarcely. I believe it would be beneficial to
> > replace the two with a single NEW state.  
> ... 
> > Your thoughts?  
> 
> How about UNRESOLVED instead?  Else you get bugs which are NEW for years
> even though they have activity all over.

We could also use plain 'OPEN' ;-).

-- 
Best regards,
Michał Górny



pgpQzgIDYDXu9.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> Hello, everyone.
> 
> Here's my second RFC wrt bugs.gentoo.org redesign.
> 
> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> However, we use the two scarcely. I believe it would be beneficial to
> replace the two with a single NEW state.
... 
> Your thoughts?

How about UNRESOLVED instead?  Else you get bugs which are NEW for years
even though they have activity all over.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[M. J. Everitt]

On 16/06/16 13:04, Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
>
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
> Revision two:
>
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
>
> Major changes:
>
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
>
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
>
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
>
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
>
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
>
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
>
> Your thoughts about this one?
>
Looks good. +1 here.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

Hello, everyone.

Here's my second RFC wrt bugs.gentoo.org redesign.

Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
However, we use the two scarcely. I believe it would be beneficial to
replace the two with a single NEW state.

Rationale:

1. Most of developers don't care about the two states, and which one
bugs are in.

2. All bugs need to be handled the same, whether they were marked as
confirmed or not.

3. We stage bugs through bug-wranglers@ which kinda has a similar
purpose to the UNCONFIRMED state in other Bugzillas.

4. Some people who actually care about the two states change them,
causing unnecessary bugspam.

5. Some users who think that the state matters get furious about bugs
staying in UNCONFIRMED for long.

Your thoughts?

-- 
Best regards,
Michał Górny



pgpFxj2strrbX.pgp
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 15/06/16 07:42, Andrew Savchenko wrote:
> On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote:
>> On Wed, 15 Jun 2016 00:12:40 +0200
>> "Andreas K. Huettel"  wrote:
>>
>>> Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
>>>
 I would personally be super happy to have my overlay hosted at Gentoo -
   
>>> So what precisely is keeping you from that?
>>>
>>> https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide
>> Don't encourage people to create more work for me when we have GitHub!
> Github is propietary and I don't see why someone have a right to
> enforce its usage on people.
>
> If someone want to use github — go ahead, but if not — in no way
> you can force people to do that (e.g. by refusing to create on
> overlay, or review patch on bugzilla, or whatever).
>
> Best regards,
> Andrew Savchenko
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Davide Pesavento]

On Thu, Jun 16, 2016 at 2:04 PM, Michał Górny  wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
>
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
>
> Revision two:
>
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
>
> Major changes:
>
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
>
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
>
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
>
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
>
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
>
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
>
> Your thoughts about this one?
>

Sounds good to me.

Thanks,
Davide

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Michał Górny]

On Wed, 15 Jun 2016 21:11:30 +0200
Michał Górny  wrote:

> Right now we have the following components:
> 
> - Applications,
> - baselayout,
> - Core system,
> - Development,
> - Eclasses and Profiles,
> - Games,
> - GCC Porting,
> - GNOME,
> - Hardened,
> - Java,
> - KDE,
> - Keywording & Stabilization,
> - Library,
> - New packages ('New ebuilds' previously),
> - Printing,
> - SELinux,
> - Server,
> - Unspecified.

Revision two:

- Current packages [bug-wranglers@],
- Eclasses [bug-wranglers@],
- Hardened [hardened@],
- New packages [bug-wranglers@],
- Overlays [overlays@],
- Profiles [bug-wranglers@],
- SELinux [selinux@].

Major changes:

1. collapsed all category-like components into a single 'Current
packages' that is the default component for pretty much every bug
related to 'standard' configurations of Gentoo Linux -- making it easy
to choose the correct one and ensuring everything goes through
bug-wranglers;

2. split 'eclasses & profiles' into two separate categories -- mainly
intended for developer use;

3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
product) as the non-standard system configurations that desire staging
the bugs through respective teams,

4. left 'New packages' as-is, as category for requesting addition
of packages not yet in Gentoo,

5. added 'Overlays' component for bugs filed against packages
in third-party repositories (right now some of them got filed pretty
randomly, and having them in Infra->Overlays is kinda wrong),

6. removed 'Keywording & stabilization'. As pointed out, those can be
handled via keywords and we already do stabilizations in other places
(e.g. security bugs).

Your thoughts about this one?

-- 
Best regards,
Michał Górny



pgp0uyPC6liJd.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Mikle Kolyada]

15.06.2016 22:11, Michał Górny пишет:

Hello, everyone.

On bug #577398, Pacho has requested removing the 'Development'
component that's rarely used according to its description. However, I'd
rather not remove a single component when it fits the component split
currently used there.

Right now we have the following components:

- Applications,
- baselayout,
- Core system,
- Development,
- Eclasses and Profiles,
- Games,
- GCC Porting,
- GNOME,
- Hardened,
- Java,
- KDE,
- Keywording & Stabilization,
- Library,
- New packages ('New ebuilds' previously),
- Printing,
- SELinux,
- Server,
- Unspecified.

[snip]


I would personally go for the following layout:

- All packages,
- Core system [includes baselayout],
- Eclasses and Profiles,
- GCC Porting,
- Hardened,
- Keywording & Stabilization,
- New packages ('New ebuilds' previously),
- SELinux.

[snip]
I'd drop keywording & stabilization at all, using bug filtering based on 
keywords field. (STABLEREQ/KEYWORDREQ ones).

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:
> I guess what I mean is these outside developers could continue 
> hacking and/or breaking things, or whatever else, without worrying 
> about their "official" branch. We could have a standard that
> assumes Gentoo pulls their 'master' branch and they keep other
> stuff in 'dev', or some other model. We'll need to decide on *some*
> branch, but putting it in writing would make things clearer for
> prospective repo maintainers.
OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYlpqAAoJENQqWdRUGk8B2G0P+wZ3Ol3AmhhsOFns7Jor7wJD
d9wqlLqtTeMcMEfUfYunpD02KwepN0UFN8imIqOGIHBM4IgQsvq19ejDgguh/MK3
uQxuyLWEHMhVNBRjNz6Ngm0IPx/3XaCSJPSu0RZdkCkHcOmAHisQY0Vy4NZj3MdL
JgBWSO5UA+CdOzC8t+TuyPE7+nt4fgC1sCwyPbjFMeD2A5IAtmyJ1hvW+THf0LeC
BW3tKt3SVLvbRLFV1A4kpKQJ+geG6+6t24jeqYrKkcViTaL5YSoAPNfajmYobXyE
zK7q+jN33WrwcOkUQGwWGg15D7/aGN5HzeJp6IGu6ANx+Ya+IVN/nG6ZpCdj569x
eeIKvNsFC7KNE6IV0srXQHKZbz9W7cAadX/vxyWHRxOwsYRQ5ZrxJH+gq6V5yeOf
0jHiT75xLCHkzk8jyKAFvou8YkLV4e9HnNd0R4Yub77hYUrS8kJ/XGRe2pEW9UrC
eMli1kiEdJ4rwI+E62kPpPqSpm17MGsdylFNav/2j4EW7g8l/ez+7LT1kOSY8ywW
JPSPiB53WHDDrnkn0y8Ips/sygu+8brTyu10SoNXSOHKZF2ZYUNXBOUunK3fqahb
zxrnzIAu8e5BD97+YgxSbg284lleUqkSdZP5O7DaNEpSMcEo9yOv1kLYNsD1vGH/
mGYOXf0F5wti+uGJxjoH
=bQST
-END PGP SIGNATURE-

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:34, Daniel Campbell wrote:
> There is overhead in choosing which repositories you want to
> include in your 'upstream'. Even with an automated tool like
> layman, there's maintenance overhead. We'd need another tool to
> assist in discoverability, too. Let's say this idea takes off and
> we start with 100-200 user repos. It's meaningless to learn that
> there are that many repositories and list them (that's what layman
> currently does). What's important is getting a list of *which
> packages* those repos have, even if it's one-by-one and cat'd to a
> file.
> 
> Even if that is written, it adds yet another facet to system 
> administration.
I'm not convinced it will be a big amount of work, and I'm doubly not
convinced most people will have *any* amount of work, as I expect most
people do not care. (I would however be pleasantly surprised to be
proven wrong.) They will start out with the Gentoo repositories, and
only venture outside if they are aspiring devs, powerusers, or have
some specific need that an overlay satisfies. If we have a useful
website (and improved CLI layman-like tool for those who have
webophobia), the complexity of assessing which overlay to use should
be exclusively derived from actual assessment, not being bogged down
in a hodgepodge of unreasonable tools. We should also have some way of
measuring popularity, and let users show appreciation for
repositories, so that there is a way to determine 'this is a top rated
repository that many people use'.

But, yes, unequivocally yes, there is an added level of system
administration for those who choose it! I just happen to think it is a
*desirable* addition for those who end up choosing it.

> Okay, and who chooses which ones get curated? Developers? The
> whole goal of this decentralization, from what I gather, is
> community. If developers are overseeing it all, it adds overhead to
> developers and doesn't really foster community control or support.
I think it is a good idea to have our developers perform reviews and
quality assurance.

> If the goal is community then it should be *community curated*, 
> which means it can exist entirely outside of Gentoo's infra and we 
> shouldn't have to care about it. Why do Gentoo devs need to curate
> it if the aim is community control? In fact, that's already
> possible right here, right now.
At first, I envision *community-assisted development* rather than our
immediate retirement and holiday in the sun. It would however be good
to aim *towards more community control*. Maybe in the future, instead
of having a KDE team we have just one person or two (volunteers like
now) who are performing a bit of review, QA, and coordination, of a
small repository. Then perhaps in a more distant future it is entirely
community driven. Stranger things have happened... But I would be
happy to see the preceding success story, even if we don't get all the
way.

> I'm not against the idea per se, but at the same time I don't see 
> why it's the responsibility of developers to make this sort of
> thing happen. It's not a trivial thing we can mark off in a
> checklist. However, there are enough tools in the Gentoo toolbox to
> make such a thing happen -- if the community wants it. And if they
> want it, they can build it. We don't do anything, to my knowledge,
> to stifle the growth of community repositories.
I think we do a poor job of fostering the growth of community
repositories, outside of making them possible in the first place. The
latter is good, of course, and kudos to everyone who's worked on it.
But it would be interesting to take it a step further and properly
facilitate these repositories.

And, again, modular repositories from our side, would make this that
much more desirable. (And modularising the Gentoo tree is obviously
our responsibility.)
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYloNAAoJENQqWdRUGk8BMZQQAMt4qcmHlbSy7oOYVzjtP14C
j3ROKwsWUS+n9Ejx9cbCShCxLNE7HfDK7SUxmf0LFvFKxOhrmjYmVZ2t8Iu07r6O
8kK5pYlUenJtQKenMIsmMQclOFrRm/y0SX/PlDcmdwMgP+fqShy7zJ3u5JNKBwfr
vitD0/c1rLS5C/p8p+o1w6g7RYUm6UtbPn8SjfkMorMpY1moU43BX4d/PFo4FT6B
CtA5+df8Z5emUkKLDkiS/9xslVU53i1TZhycgOVbubMnyuvoJyHeB2ZWiSOtYqw7
GIUiYYmrQ6JJFf6ZNuIXV3V+zfv6nfNL5D9xvpBYg5RwMQEMUXWP8f0ca+2sE5Kx
RojMEOKQx6Y1rYHOtq9gXpsAArT0TCWmglaxCqUwrf6SKL373TEkmr8RMvvRDGBV
GFJcOsxv9OrkJTe0FYvmr8y8N93b+KTK7RhDekYuWm+rrbfebo+dcKPZmtPcYxoR
NgmhLEdllUhdwti+e2Lo+qSXBScoRBeqYmWW+lN/k02YSV/gIiumbi7d4H/HRy6n
kNbELzGpqLr/FIZRxD5Sx7ufSjEC+OlnP59OM6Uj1A6yUmuepyqlJJrmeaZ9LzGg
6/vzgrX82jjrMAishtNleftquaxpzSNQsFGB1PgZ/h2XObacuBMnOgOMV8RvsfVG
4VUp+ttdQi+DDxLQA4Bi
=zHis
-END PGP SIGNATURE-

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Daniel Campbell]

On 06/16/2016 12:35 AM, Alexander Berntsen wrote:
> On 16/06/16 09:24, Daniel Campbell wrote:
>> To touch on the user repo part.. can't it be as simple as adding
>> one requirement to user repos that wish to be considered as
>> curated?
> 
>> Create a "gentoo-ci" branch or something else, and the maintainer
>> of each repo can update said branch when QA 'approves' a given
>> commit. Then others can 'subscribe' to that branch and development
>> remains unhindered by the QA process in a distributed format.
> I'm not sure what you mean by unhindered. I didn't mean for my idea to
> create any hindrance. My idea was to fork their repository, and have
> some dev(s) take the responsibility of merging from the user. Or, we
> could do what Exherbo does, just let them carry on and trust them, and
> only (perhaps temporarily) remove their repository if we find them
> guilty of some wrongdoing.
> 
> While I'm not axiomatically opposed to your idea, I think it may
> create noise if everybody makes a gentoo-ci branch, and most of them
> are close to worthless.
> 
I guess what I mean is these outside developers could continue hacking
and/or breaking things, or whatever else, without worrying about their
"official" branch. We could have a standard that assumes Gentoo pulls
their 'master' branch and they keep other stuff in 'dev', or some other
model. We'll need to decide on *some* branch, but putting it in writing
would make things clearer for prospective repo maintainers.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:24, Daniel Campbell wrote:
> To touch on the user repo part.. can't it be as simple as adding
> one requirement to user repos that wish to be considered as
> curated?
> 
> Create a "gentoo-ci" branch or something else, and the maintainer
> of each repo can update said branch when QA 'approves' a given
> commit. Then others can 'subscribe' to that branch and development
> remains unhindered by the QA process in a distributed format.
I'm not sure what you mean by unhindered. I didn't mean for my idea to
create any hindrance. My idea was to fork their repository, and have
some dev(s) take the responsibility of merging from the user. Or, we
could do what Exherbo does, just let them carry on and trust them, and
only (perhaps temporarily) remove their repository if we find them
guilty of some wrongdoing.

While I'm not axiomatically opposed to your idea, I think it may
create noise if everybody makes a gentoo-ci branch, and most of them
are close to worthless.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYla5AAoJENQqWdRUGk8BjQAP/jfWOmR3DHMSlUpYGQILCrRp
na0WUIHqWqVFirb5UaG4Jn419TXvHynT7WqeP1brL/czWiwZ/XO7IUF/Qw2Qbg29
uXtFS03V+KvnJSZNHBuY9yAsruKtv41fbRF906Erxo9KDoubJRlJdYoIazjwCA4a
TMvFcAwLhvU0eJ+kXxZHzBWO5JSH29HA9Nwikd7vSDLZEGoB1wjjzKb2eNsU60Pg
NBW7osLk7LPB+Lmqisjs/EmHJobrVCdpPl1495b/X9/I433v3Y6FE4JZQ3msclv9
aZmqAFa6nqE3Sy6bEdOJPFk7ThnS3rNU0B0hpDt4V8wG4pNRMSdW30ua3KojfcIZ
Gbk77onNR8UiJNKiwW042DgZhn6ne1+19BtMQ+C9AT+5bAlnWrTPykcf+pbNfejK
W4V8hIcFsus8Umug/uqxugTbtROyRCAZlll3eYLsi6NaWs16iJhJRGc1KOYwlnDJ
DBO6quTK1EHGbugWPERKxMdRDikum7RnQCZYXjiYOqJI+MgReArMjqihpM9teKTL
c1DUF2u8yVSxftLaClmva95wFmcbdbdWnfXVA5w1QhLeIYC+ptGUKJhV35FInTn2
Hcig2gtHZibCujBikSxsXcWigQlIzjDAtsX+lxZfa9jWwTD2b3x1ny4UQKHsA4Qi
Qd5mUTzBM/1csYZtRlue
=u0jJ
-END PGP SIGNATURE-

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Daniel Campbell]

On 06/15/2016 12:22 AM, Alexander Berntsen wrote:
> On 14/06/16 08:48, Daniel Campbell wrote:
>> What sort of modularization are you talking about?
> The cheap answer is "as much as possible.
> 
>> Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon,
>> et al getting their own overlays? dev-lang/foo getting its own
>> overlay, etc?
> Yes. Although I would not want to impose my thoughts too much in this
> regard, as I think we have a lot of capable devs, who are hopefully more
> fit for this task than I am.
> 
>> To some degree, that will simplify some people's trees and quicken
>>  emerge, but then it just pushes maintainance to a part that most
>> users don't really mess with much (repos.conf)
> I don't know what maintenance you are speaking about.

There is overhead in choosing which repositories you want to include in
your 'upstream'. Even with an automated tool like layman, there's
maintenance overhead. We'd need another tool to assist in
discoverability, too. Let's say this idea takes off and we start with
100-200 user repos. It's meaningless to learn that there are that many
repositories and list them (that's what layman currently does). What's
important is getting a list of *which packages* those repos have, even
if it's one-by-one and cat'd to a file.

Even if that is written, it adds yet another facet to system administration.
> 
>> You can achieve mostly the same end via your own git repo at
>> /usr/local/ and pulling overlays in via either layman or git
>> submodules, for overlays that aren't already in layman.
> The repository isn't hosted by us along with everybody else's
> repository, so there is no community element. And the Gentoo tree isn't
> modular today. So I completely fail to see how that would be "mostly the
> same".
> 
>> zugaina and layman are great tools that could use a bit more
>> polish, and could be either adopted or assisted as an official part
>> of the handbook.
> That would be great.
> 
>> There's no guarantee on their quality, and if an overlay becomes
>> popular then there may be pressure put on the Gentoo tree to adopt
>> whatever the popular overlay has. This could be detrimental *or*
>> beneficial, depending on what the changes are.
> I assume that using PPAs is at your own risk, so this is not a real
> problem. Gentoo would have a curated and reviewed set of repositories,
> venturing outside of that is clearly for power users.
> 
Okay, and who chooses which ones get curated? Developers? The whole goal
of this decentralization, from what I gather, is community. If
developers are overseeing it all, it adds overhead to developers and
doesn't really foster community control or support.

If the goal is community then it should be *community curated*, which
means it can exist entirely outside of Gentoo's infra and we shouldn't
have to care about it. Why do Gentoo devs need to curate it if the aim
is community control? In fact, that's already possible right here, right
now.

I'm not against the idea per se, but at the same time I don't see why
it's the responsibility of developers to make this sort of thing happen.
It's not a trivial thing we can mark off in a checklist. However, there
are enough tools in the Gentoo toolbox to make such a thing happen -- if
the community wants it. And if they want it, they can build it. We don't
do anything, to my knowledge, to stifle the growth of community
repositories.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Daniel Campbell]

On 06/15/2016 12:37 AM, Alexander Berntsen wrote:
> You've got most things right, Rich. But a couple of comments follow.
> 
> On 15/06/16 02:25, Rich Freeman wrote:
>> 1.  Developers wouldn't have access to all the ebuilds in the
>> curated repositories.  They would only have access to the ones they
>>  contribute to.
> I'm not sure I completely agree with that as a hard rule. E.g. I think
> that having an inter-repository QA team would be valuable.
> 
>> 2.  Exherbo at least requires peer review for all commits I
>> believe. So, even if you're committing to your "own" overlay you're
>> still going to need review if your overlay is a curated one.
> Once again you are misrepresenting Exherbo. But since this thread is
> about Gentoo, I will limit my reply to Gentoo. We should not enforce
> anything on a user's repository like this. Instead, I suggest we
> maintain a fork of their repository in which we perform review.

To touch on the user repo part.. can't it be as simple as adding one
requirement to user repos that wish to be considered as curated?

Create a "gentoo-ci" branch or something else, and the maintainer of
each repo can update said branch when QA 'approves' a given commit. Then
others can 'subscribe' to that branch and development remains unhindered
by the QA process in a distributed format.

We've settled on git, and anything that replaces git in the future will
need an analog or replacement for branches, so it seems like a sound
idea to me.

Of course, pulling that off in infra and coordinating review is a
completely different issue; one that won't be solved with software.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature