Re: [gentoo-dev] Should "server" be a global use flag?

[Jeroen Roovers]

On Tue, 24 May 2011 11:52:51 +0400
Peter Volkov  wrote:

> В Пнд, 23/05/2011 в 17:19 +0200, Jeroen Roovers пишет:
> > I find myself wondering why so much information is being jammed into
> > USE flag descriptions that /should/ be available in HOWTOs from
> > upstream, or else should be written down in HOWTOs we maintain
> > ourselves - we (Gentoo) used to be good at providing HOWTOs as
> > needed and it's a good tradition to keep up. It helps the entire
> > open source community and not just our users, too.
> 
> I don't see how moving USE flag descriptions from portage tree in
> HOWTOs will help community. This will just take more time to check
> what USE flag does. Also it's clear that maintaining another 10
> guides will just slow things down with no real benefit.

I never suggested were moving USE flag descriptions into HOWTOs (how?
what does that mean?). I said USE flag descriptions were being (ab)used
where proper HOWTOs would serve users better.

And I suggested HOWTOs should be used to introduce users to new
software - good upstreams do this, and Gentoo used to do this a lot,
which is one of Gentoo's great attractions.

Explaining how a package works in USE flag descriptions is no
replacement for good documentation, and the  tags in
metadata.xml weren't introduced to replace documentation.

> > Anyway, count the YESs above. Maybe some people want to
> > comment/explain/defend how they wrote their descriptions, so don't
> > touch them just yet. :) 
> 
> We can add global 'server' USE flag and still keep local USE flag
> descriptions where they make global description a bit more clear. And
> if I understood your last message correctly, in case you want to
> update USE flag descriptions yourself, please, don't touch USE flag
> descriptions but open bugs for maintainers to decide.

Who me? Please read the entire thread.

And please don't be so territorial either - just blame the right people
when they mess up, instead.


 jer

Re: [gentoo-dev] arch teams and better tools

[Rich Freeman]

On Tue, May 24, 2011 at 3:39 AM, "Paweł Hajdan, Jr."
 wrote:
> On 5/22/11 11:33 AM, Markos Chandras wrote:
>> I would also like to see a minimal webpage ( under
>> http://www.gentoo.org/proj/en/base/tools? ) which would describe how
>> to use these tools on daily basis to deal with the bug workload. That
>> will help the rest of us integrate your scripts to our workflow and
>> be more efficient.
>
> I'll think about that, and it's definitely a good idea. It's just still
> early in development, but after the discussion about more automated
> testing I decided to post what I have ("release early, release often")
> to avoid possible duplication of work.
>

A guide of some sort would definitely be appreciated.  If a few devs
have worked out a super-efficient way of doing stabilizations without
making mistakes it would be nice if everybody else had the option to
do the same without having to stumble around finding it.

Along the same lines - some kind of gentoo dev tips page might be
useful if anybody cared to start creating one.  I have a few
scripts/aliases that I've made use of (often passed along from
somebody else or snipped from a list).  Perhaps not every new
developer knows that they can run "qlist ${1} | xargs scanelf -L -n -q
-F '%n #F' | tr , ' ' | xargs qfile -C | sort -u" to get a starting
list of package dependencies.

Rich

Re: [gentoo-dev] Should "server" be a global use flag?

[Peter Volkov]

В Пнд, 23/05/2011 в 13:32 -0400, Anthony G. Basile пишет:
> On 05/23/2011 12:37 PM, Michał Górny wrote:
> > On Mon, 23 May 2011 16:48:15 +0200
> > Ulrich Mueller  wrote:
> >> From :
> >> | If the effect of the USE flag upon pkg-one is substantially
> >> | different from the effect it has upon pkg-two, then the flag is not
> >> | a suitable candidate for being made a global flag. In particular,
> >> | note that if client and server USE flags are ever introduced, they
> >> | can not be global USE flags for this reason.

We need to update this. As with USE ssl - it just enables ssl support
with no knowledge in advance how it'll be implemented. Since we are
allowed to have both global and local USE flag descriptions, global USE
flag now better defines overal sense of USE flag while local may adjust
it to make better sense for current package...

> > With that definition, USE=crypt should definitely not be global.
> >
> Yep.  Eg. USE="crypt" for evolution means dependence on app-crypt/gnupg
> and is local while USE="crypt" for thunderbird means dependency on
> x11-plugins/enigmail and is global.  Both are substantially different
> from what USE="crypt" means for util-linux which enables crypto-loop and
> is a global.

It's good idea to open bug and suggest better local USE flag
descriptions.

--
Peter.

Re: [gentoo-dev] Should "server" be a global use flag?

[Peter Volkov]

В Пнд, 23/05/2011 в 17:19 +0200, Jeroen Roovers пишет:
> I find myself wondering why so much information is being jammed into
> USE flag descriptions that /should/ be available in HOWTOs from
> upstream, or else should be written down in HOWTOs we maintain
> ourselves - we (Gentoo) used to be good at providing HOWTOs as needed
> and it's a good tradition to keep up. It helps the entire open source
> community and not just our users, too.

I don't see how moving USE flag descriptions from portage tree in HOWTOs
will help community. This will just take more time to check what USE
flag does. Also it's clear that maintaining another 10 guides will just
slow things down with no real benefit.

> Anyway, count the YESs above. Maybe some people want to
> comment/explain/defend how they wrote their descriptions, so don't
> touch them just yet. :) 

We can add global 'server' USE flag and still keep local USE flag
descriptions where they make global description a bit more clear. And if
I understood your last message correctly, in case you want to update USE
flag descriptions yourself, please, don't touch USE flag descriptions
but open bugs for maintainers to decide.

--
Peter.

Re: [gentoo-dev] arch teams and better tools

[Paweł Hajdan, Jr.]

On 5/22/11 11:33 AM, Markos Chandras wrote:
> Thanks for sharing your scripts. I would prefer to have a single
> script doing everything, instead of multiple scripts here and there.

Right, having to complete pieces from various sources can be
frustrating. I'm planning to make arch-tools a complete solution (i.e.
no need to fetch any additional scripts, and only a minimal setup), but
I think it'll consist of multiple scripts (probably the bugzilla viewer,
emerge launcher, and mass committer).

> I would also like to see a minimal webpage ( under 
> http://www.gentoo.org/proj/en/base/tools? ) which would describe how
> to use these tools on daily basis to deal with the bug workload. That
> will help the rest of us integrate your scripts to our workflow and
> be more efficient.

I'll think about that, and it's definitely a good idea. It's just still
early in development, but after the discussion about more automated
testing I decided to post what I have ("release early, release often")
to avoid possible duplication of work.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] arch teams and better tools

[Paweł Hajdan, Jr.]

On 5/22/11 10:13 AM, Thomas Kahle wrote:
> I like it.  Funnily It digged up some stable bugs from the stone-age
> that have been processed, but x86 was still on the CC-list.

Thanks. Those old bugs being displayed was a bug, I fixed it.

> Have you seen app-portage/tatt ? I think there is a huge overlap between
> your project and tatt.

Yeah, the project was in fact inspired by tatt and the earlier gatt.

> tatt can already fetch bugs from bugzilla,
> create USE-flags and reverse dependency, as well as cvs commit scripts.
> You can use your own templates for the scripts, but tatt also provides
> some.

One of the main things I wanted was being able to see all bug comments,
bug dependencies, related bugs, and repoman output in the bugzilla
viewer. Can tatt do that?

I think I'm going to either re-use or copy tatt's parts responsible for
compiling and committing the changes. For now I just focused on the
first part of the workflow (identifying bugs to work on, and identifying
possible problems as early as possible).

> Regarding the work-order I intentionally try to be agnostic.  I do
> security bugs first, and then work on the oldest bug.

Right, but sometimes there are bugs with no input from the maintainer.
Another thing I'd like to do is to mark such a bug as ignored, or even
"ignored until the next update" (e.g. when someone replies on that bug).



signature.asc
Description: OpenPGP digital signature