Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Dirkjan Ochtman]

On Tue, Apr 6, 2010 at 04:13, Nirbheek Chauhan  wrote:
> * Use a separator in the commit message like "== \n" to denote that
> everything after this is dev-only information and should be skipped
> from the user ChangeLog

I think this is fairly elegant, and a good solution to this problem.

Cheers,

Dirkjan

[gentoo-dev] Council meeting 19 April 2010

[Ulrich Mueller]

Next monthly council meeting will be at 19 April 2010, 18:00 UTC
in #gentoo-council.

If you have any topics you want us to discuss or even vote about,
simply followup to this message.

Ulrich

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

First, I've been using git to hack Linux for some embedded devices. My
development was in sync with upstream linux-omap to which I sent several
patches. So, consider yourself that I have some experience with git.

On 06-04-2010 08:41, Fabian Groffen wrote:
> On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
>>   - Irritating conflicts while merging branches or remote master
>> + Similar argument for having only distfile manifests; but I digress...
>>   - Duplication of effort and information
>>   - Saves space for local checkouts
> 
> This seems to assume
> a) that we will do branches, and
> b) that those branches somehow are official and in use
> 
> In CVS we are not allowed to use branches, as a policy, that somehow
> makes sense.  Our stable tree is visible via keywords instead.
> 
> Why would we suddenly do branches?  It still isn't a good thing.  If you
> talk about branches in the sense of a clone of the entire repo, why
> would we suddenly do massive concurrent development on the same ebuilds?

IMHO repository branching would be greatly useful on Gentoo portage,
specially for third-party and other Gentoo-based distros. It will be a
lot easier for them to keep their own changes to ebuilds while in sync
with main Gentoo tree. This is a big win for everyone.

With my experience in Gentoo-embedded I can also present a problem where
branching is extremely useful:
1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64.
2) Some dev at -embedded decides that package is useful and applies his
traditional cross-compile hackery.
3) The usual route would be to open a shi*load of bugs, wait a cr*pload
of time for the maintainer response and if the weather feels like it,
there is authorization to commit. Then there is also need to retest for
already keyworded arches so we know we don't break others.

3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start putting
quick patches in the tree for specific arches while not breaking others.

IMHO, the only bottleneck I see on Gentoo development is the massive
policy (not saying it is not needed) a -dev has to follow just to commit
a simple fix. Git my friends, will be our holly grail.
> 
> I can tell you from good experience that you only do such things if you
> really have to, e.g. when you are in an overlay that needs to have
> modifications to nearly everything and you try to keep that overlay
> up-to-date with its origin, gentoo-x86.  It's no fun, because it
> conflicts pretty much on lots of things, not ChangeLogs.
> 
> It seems to me, that if you are in a clone working on something, you
> just only write the ChangeLog once you merge it with its origin,
> gentoo-x86.  You have to review what happened at that stage anyway.
> 
> If you really have lots of changes, you will find that many commits on
> the other side will cause you conflicts, so the ChangeLog is just a very
> small part of it.  Conclusion, if you can, try hard to keep your changes
> minimal, and preferably zero compared to the origin, gentoo-x86.
> 
> 

I don't know why but people seem to have eternal scarring to merge
conflicts. Yes, they happen and yes they are trivial to fix if people
don't commit crap that touches a lot of stuff. In portage, the tree is
very well organized and with some good policies like restricting each
commit to one package will pretty much prevent conflicts.

I will not comment on if Changelogs are going to give conflicts or not.
That would be best answered by the people that is running portage git
for some time.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Ciaran McCreesh]

On Wed, 07 Apr 2010 11:58:13 +0200
Angelo Arrifano  wrote:
> With my experience in Gentoo-embedded I can also present a problem
> where branching is extremely useful:
> 1) Package foobar-1.2 is in the tree and keyworded only for ~x86
> ~amd64. 2) Some dev at -embedded decides that package is useful and
> applies his traditional cross-compile hackery.
> 3) The usual route would be to open a shi*load of bugs, wait a
> cr*pload of time for the maintainer response and if the weather feels
> like it, there is authorization to commit. Then there is also need to
> retest for already keyworded arches so we know we don't break others.
> 
> 3*) With git, one would just branch (lets call it embedded branch) the
> package. Apply the patches there and let people using embedded
> profiles to emerge from that branch instead of master.
> Benefits? I think they are pretty obvious - people can start putting
> quick patches in the tree for specific arches while not breaking
> others.

And then you have to keep merging master into your embedded branch
every few hours to keep up. It's a waste of time. Instead, you should
just put a modified foobar-1.2 in your own repository and rely upon the
package manager's extensive and clean handling of multiple repositories
to avoid having to do any merging yourself.

There are uses for merges, but working around the shortcomings in a
package manager shouldn't be one of them. Migrating to Git should be
about addressing problems with CVS, not about addressing problems with
Portage.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

On 07-04-2010 00:21, Robin H. Johnson wrote:
> On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote:
>> Why not just get rid of the in-tree Changelogs entirely?  The scm
>> logs already document this information, so why have it in a file?
> The major concern with this is users that are NOT connected to the
> internet always.
> If you are connected, you can just use --exclude Changelog in your rsync
> options.
> 

That's a good point. But can't we generate the ChangeLogs automatically
from git on the main rsync server?

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Sebastian Pipping]

On 04/04/10 00:24, Sebastian Pipping wrote:
> Concrete tasks
> ==
> - [..]
> - work on association between bugs and packages
>   (for all bugs, not just bugday ones)

I've been playing with code answering the questions:
- How do bugs and packages relate?
- How is bugload distributed across developers?

I came to a point where
- I have something that starts to be useful
- I am facing troubles that need further
  consideration first, see below.


Current results
===
Bug load per developer
--
http://dev.gentoo.org/~sping/bug-heartbeat/report--bug-count-by-person.html

Bug load per herd
-
http://dev.gentoo.org/~sping/bug-heartbeat/report--bug-count-by-herd.html

Bugs in a tree of category and package
--
http://dev.gentoo.org/~sping/bug-heartbeat/report--bugs-by-package.html

Bugs that may lack mention of package name
--
http://dev.gentoo.org/~sping/bug-heartbeat/report--bugs-without-package.html


Question to be answered
===
 - herds.xml does not hold membership lists for
   all projects, not even herds.  The load
   evaluator needs access to complete mappings
   to generate output close to reality.
   How can such a mapping be made without
   duplicating data?

 - Pulling XML out of Bugzilla does no longer
   feel right with this amount of data:
   it's 15,000 open bugs that need to be
   refreshed periodically in chunks of 100 bugs
   (Bugzilla's limit) each.  That's 150 request
   for a full sync.  How can that be improved?


Generating reports yourself
===
In case you want to play with the code yourself:
http://git.goodpoint.de/?p=gentoo-bug-heartbeat.git;a=summary

Run the report generator as following:

  # bzip2 -d xmlbugs.xml.bz2
  # python modules/heartbeat/reporter.py

The .bz2 file needed is up at
, too.



Sebastian

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Ben de Groot]

On 7 April 2010 13:20, Sebastian Pipping  wrote:
>  - herds.xml does not hold membership lists for
>   all projects, not even herds.  The load
>   evaluator needs access to complete mappings
>   to generate output close to reality.
>   How can such a mapping be made without
>   duplicating data?

herds.xml should be the definitive resource for herds, so any herds
that are not on there should be added, and outdated information should
be brought up to date.

Other projects should have membership listed on their project pages.
Again, where these are outdated, they should be brought up to date.

Cheers,
-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 11:05, Ulrich Mueller  wrote:
> Next monthly council meeting will be at 19 April 2010, 18:00 UTC
> in #gentoo-council.
>
> If you have any topics you want us to discuss or even vote about,
> simply followup to this message.

1. reconsider metadata changepolicies proposal
==

The fact is there is a spectrum from ebuild maintainers' side about
how desirable it is for non-maintainers to step in, ranging from
"don't touch this ever" to "please do touch this". There may be very
valid reasons for this (in some cases intimate knowledge of the
package may be required, for example, or on the opposite side someone
might not have the time or motivation to do much about that specific
package) that have little to do with territoriality. While there is a
need for basic policies to be made more explicit, it is also obvious
that there is no good "one policy fits all" approach. The metadata
changepolicies proposal beautifully captured this spectrum and has
wide support from developers. While this information isn't directly
useful to users, the argument that it "would bloat the file for no
good reason" is false, because there are very good reasons: to
facilitate cooperation between devs as well as a better overall
quality of the tree. This benefits users, so I'm quite sure they don't
mind we use metadata.xml for that. Can council please decide to honor
the wish from developers to implement this?


2. website redesign
===

This is a recurring theme in discussions about Gentoo's shortcomings.
While there have been some minor improvements in recent years, the
resign project itself failed miserably, but is still as needed as
ever. We should have one elegant design that will be consistently
applied to all official Gentoo websites. A look at znurt.org should
convince anyone of what can be done. Also our frontpage needs to be
more focussed on communicating the things users and new visitors are
looking for. Can council assure that a team will be assembled that can
effectively tackle this issue?


3. manpower and recruitment issues
==

Another recurring theme is the lack of manpower in certain areas, the
recruitment bottleneck and the quizzes. There are some initiatives but
more decisive leadership is needed. Can council decide to actively
pursue solutions for these structural problems?


4. devrel ineffectiveness
=

What can be done to assure that conflicts are addressed in a timely
and effective manner by DevRel? What can be done to remove poisonous
people from Gentoo and its communication channels more decisively and
effectively? The fact that many people indicate they do not want to
become a developer for this exact reason, should be cause for concern.
Can council make a statement that they share these concerns and are
actively looking to address them?


5. centralize developer documentation
=

Currently the documentation a developer needs to effectively write
ebuilds and maintain packages is scattered all over the place. We have
the (incomplete) devmanual, the developer handbook, various guides and
policies in individual projects, the GLEPs, council decisions, and a
legacy of unwritten rules or poorly documented policies. It would be
very helpful to centralize all that information, and work on properly
documenting our policies. At the very least there should be one page
that funtions as a portal to all existing relevant information. Even
better would be to have as much of that relevant information as
possible consolidated into one place, so that everyone knows where to
go to look that up. Can council decide to see this implemented?

Thanks,
-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Richard Freeman]

On 04/07/2010 05:58 AM, Angelo Arrifano wrote:

3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start putting
quick patches in the tree for specific arches while not breaking others.

IMHO, the only bottleneck I see on Gentoo development is the massive
policy (not saying it is not needed) a -dev has to follow just to commit
a simple fix. Git my friends, will be our holly grail.


I think that allowing for different levels of QA standards, and 
accomodating things like this are good reasons to use branches. 
HOWEVER, we do need to manage this so that it doesn't get out of hand.


We really don't want users following 14 different branches and have 10 
different variations on every package in the tree - which is how it 
could get after a year or two of branching without any effort to do 
pruning and get things merged into a main tree.


Having branches to do development and facilitate access and testing 
seems fine, however we should always have the goal of getting these 
tested revisions merged back into the main tree.  We really don't want 
divergent development to be the norm.

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot  wrote:
> 1. reconsider metadata changepolicies proposal
> ==
[...]
> Can council please decide to honor
> the wish from developers to implement this?

The council will be glad to vote on a GLEP when ready. From GLEP 1,
GLEPs are the "primary mechanisms for proposing significant new
features, for collecting community input on an issue, and for
documenting the design decisions". So use them.

Also, you might want to check the log and summary of the last meeting
to find out why the council may end up voting no to such a GLEP.

> 2. website redesign
> ===
[...]
> Can council assure that a team will be assembled that can
> effectively tackle this issue?

You want the council to aim their collective gun at volunteer
developers and force them to assemble in a team and work on something
they might not want to work on?

In other words, if you want it then work on it and make it happen.
This is and has always been the Gentoo way.

> 3. manpower and recruitment issues
> ==
>
> Another recurring theme is the lack of manpower in certain areas, the
> recruitment bottleneck and the quizzes. There are some initiatives but
> more decisive leadership is needed. Can council decide to actively
> pursue solutions for these structural problems?

The only way to solve this is to address these issues where they are.
That means joining the recruiters team and helping them with that.
Another thing you might want to do is properly mentor recruits.
Because one reason recruiting takes so long, and thus why there is a
backlog, is (to put is simply) that mentors suck at mentoring.

> 4. devrel ineffectiveness
> =

In case you haven't noticed there was a recent change of devrel lead.
This means it is urgent to wait for the results of the change. Because
you never know, it might just be that the change of lead was intended
to solve such things at a perceived devrel ineffectiveness.

> 5. centralize developer documentation
> =

This is an interesting idea which I believe I have seen discussed on
irc at some point. Feel free to work on a GLEP to address that.

Before we go any further, let me make the following PA announcement:

 1 - If you want to improve a project or subproject the best (and
often only) thing to do is to join it.

 2 - The council isn't a super-nanny metaproject with enough magical
powers to solve each and every of your oh-so-annoying problems. We do
have magic wands but you don't want to see them.

Denis.

Re: [gentoo-dev] Re: [Gentoo Pheonix] Heartbeat team force

[Markos Chandras]

On Tuesday 06 April 2010 10:03:26 Torsten Veller wrote:
> * Sebastian Pipping :
> > - Package tree history  (VCS logs, ..)
> > 
> > - get real numbers on how much active manpower we have
> 
> I am generating monthly stats for gentoo-x86 for a year or so:
> http://dev.gentoo.org/~tove/stats/gentoo-x86/
> 
> It lists the number of commits per month (cvs-log-20...) for all
> "active" devs. Monthly commits per dev over time (dev/commits-$dev...).
> 
> cvs-log-sum.txt total number of commits per dev.
> 
> slacker.txt combines the last two month and adds further information for
> devs without commits (date of last commit, date of last bugzilla
> interaction, dev bug information, away status).
> 
> Since 2010 I also add cvs-log-all-.. which adds all not-retired devs
> with gentoo-x86 access.
> 
> grep for Sum, Mean,...:
> http://dev.gentoo.org/~tove/files/activedevs.txt
> http://dev.gentoo.org/~tove/files/sum.txt
> http://dev.gentoo.org/~tove/files/mean.txt
> http://dev.gentoo.org/~tove/files/median.txt
Very useful. Thank you very much 
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Markos Chandras]

On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
Just a question:

Why do we even need to care about ChangeLog files? Can't we just use the git 
commit message to generate logs? E.g run a script on server side which will 
read the whole git shortlog and generate a changelog every $timeframe?

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 17:00, Denis Dupeyron  wrote:
> Before we go any further, let me make the following PA announcement:
>
>  1 - If you want to improve a project or subproject the best (and
> often only) thing to do is to join it.
>
>  2 - The council isn't a super-nanny metaproject with enough magical
> powers to solve each and every of your oh-so-annoying problems. We do
> have magic wands but you don't want to see them.


Gentoo Council project page :

"1.  Project Description
The elected Gentoo Council decides on global issues and policies that
affect multiple projects in Gentoo."

GLEP 39 also says "Global issues will be decided by an elected Gentoo council."

So all I'm asking is to do your job and make decisions on issues that
affect all of Gentoo. The issues I brought up are wider than a single
individual project.

Thanks,
-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Markos Chandras]

On Monday 05 April 2010 21:51:34 Nathan Zachary wrote:
> On 05/04/10 11:07, Jon Portnoy wrote:
> > On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
> >> Just replying randomly.
> >> 
> >> On 05.04.2010 04:33, Tobias Heinlein wrote:
> >>> I think this is a good starting point to get rid of the "some important
> >>> questions are too hard to answer" dilemma that can be implemented
> >>> relatively fast. On top of that I like Sebastian's idea to order the
> >>> quizzes by difficulty -- this means just ordering by the categories I
> >>> just mentioned would be sufficient: 1 first, then 2, then 3.
> >> 
> >> I am not against this idea but frankly, I do not understand what is so
> >> demotivating about the ebuild quiz.  If you get demotivated because of a
> >> single exam, perhaps the problem is with the motivation and not with the
> >> exam itself.  I took the published quiz just for the fun of it and to
> >> see where I missed.  It is not that long.
> > 
> > Agreed...
> > 
> > I've been following this discussion with mixed feelings. When we
> > originally began using the quiz system the idea was simply to try
> > to force new developers to RTFM -- and I was not such a fan of the
> > entire concept (as I recall, the quizzes were a "suggestion" from
> > Daniel).
> > 
> > As it turns out, the quiz system has repeatedly proven itself useful
> > in another way: developers who whine/bitch/moan and are hesitant to
> > even attempt to complete the quizzes often turn out to be bitchy,
> > unmotivated, or unpleasant developers. I don't want to name any names,
> > but I've seen this often.
> > 
> > IMO, those "boring" "too much like high school" quizzes serve one
> > extremely valuable function: finding out up front who's a team player
> > (or at least willing to do something mildly unpleasant for the
> > Greater Good)
> > 
> > If that's causing potential devs to drop out... perhaps the system is
> > working as it should? :)
> 
> My problem with the quizzes is not that they have to be done, but rather
> the way they are structured.  I have read through the dev manual (which
> is excellent in explaining some things, and a little rough in others),
> but it would be much more enlightening to me to work on creating ebuilds
> while working one-on-one with a mentor.  For instance, in a recent
> ebuild I wrote, the application installed successfully but yielded
> sandbox errors.  By jumping on IRC and chatting with a few people, I
> readily found a solution to that problem.  Later, it was brought to my
> attention that there were other problems with the ebuild.  I would have
> never known about these issues solely from the information presented in
> the devmanual.  Therefore, I think the most valuable aspect of the
> recruitment process is "hands-on" time with ebuilds, commits, et cetera
> WHILE working with a mentor.
> 
> --Zach
This is why it is good to train "wanna-be" developers in our overlays. 
Studying and blindly answering the quizzes is not enough. They have to work on 
actuall ebuilds, dealing with as many eclasses as possible and handle all kind 
of bugs in our bugzilla. In other words, recruitment must not be one-
dimensional but it has to cover all aspects of gentoo development
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot  wrote:
> So all I'm asking is to do your job and make decisions on issues that
> affect all of Gentoo. The issues I brought up are wider than a single
> individual project.

And almost 100% of the time this needs to run through a GLEP, which is
the case here. Then the council will do all the things you've pasted
from GLEP 39.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 20:05, Denis Dupeyron  wrote:
> On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot  wrote:
>> So all I'm asking is to do your job and make decisions on issues that
>> affect all of Gentoo. The issues I brought up are wider than a single
>> individual project.
>
> And almost 100% of the time this needs to run through a GLEP

Where is that policy documented?

-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras  wrote:
> On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
> Just a question:
>
> Why do we even need to care about ChangeLog files? Can't we just use the git
> commit message to generate logs? E.g run a script on server side which will
> read the whole git shortlog and generate a changelog every $timeframe?
>

You seem to have missed the gist of the situation. I'm quoting it here
again to highlight it:

* It makes zero sense to manually manage ChangeLogs in git[1]
[snip]
* Proposed is to generate ChangeLogs from git commits on the rsync
server side when metadata generation is done
 - Scripts to do this already exist[1]
[snip]

1. http://live.gnome.org/Git/ChangeLog
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Sebastian Pipping]

On 04/07/10 14:00, Ben de Groot wrote:
> On 7 April 2010 13:20, Sebastian Pipping  wrote:
>>  - herds.xml does not hold membership lists for
>>   all projects, not even herds.  The load
>>   evaluator needs access to complete mappings
>>   to generate output close to reality.
>>   How can such a mapping be made without
>>   duplicating data?
> 
> herds.xml should be the definitive resource for herds, so any herds
> that are not on there should be added, and outdated information should
> be brought up to date.

they are in there but keep their member list elsewhere.
an example is herd "bsd":

  
bsd
b...@nospam
Support for *BSD system packages,
and *BSD derived packages.

  /proj/en/gentoo-alt/bsd/index.xml

  

now that i have a closer look maybe the herds itself are manageable,
besides the annoyance of being in another CVS tree:

  
  
  

  welp
  drizzt
  aballier
  the_paya

that looks usable.

with the herd "embedded" it's difficult though: the page

lists members for it but the page source does not
hold it, explicitly.  where does it come from?



> Other projects should have membership listed on their project pages.
> Again, where these are outdated, they should be brought up to date.

seems like they use the same syntax, too.  i start to like guidexml :-)

some of the mail aliases i don't handle yet, could also be a problem
(especially those i don't have permission to look at).



sebastian

Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

[Ben de Groot]

On 7 April 2010 20:55, Sebastian Pipping  wrote:
>  welp
>  drizzt
>  aballier
>  the_paya
>
> that looks usable.

Except that it's out of date as welp is retired.

> with the herd "embedded" it's difficult though: the page
> 
> lists members for it but the page source does not
> hold it, explicitly.  where does it come from?

It does, as can be seen in
http://www.gentoo.org/proj/en/base/embedded/index.xml?passthru=1

-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] Council meeting 19 April 2010

[Arun Raghavan]

Hi Ben,

On 7 April 2010 22:44, Ben de Groot  wrote:
[...]
> "1.  Project Description
> The elected Gentoo Council decides on global issues and policies that
> affect multiple projects in Gentoo."
>
> GLEP 39 also says "Global issues will be decided by an elected Gentoo 
> council."
>
> So all I'm asking is to do your job and make decisions on issues that
> affect all of Gentoo. The issues I brought up are wider than a single
> individual project.

I don't understand what you expect the council to do in some of these
cases. Taking the website redesign or consolidation of documentation
as examples, do you want them to:

a) Decide that this should be done?
b) Call for volunteers? (they obviously cannot force anyone to do it)
c) Do it themselves?
d) What you probably mean that I fail to see

Regards,
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 23:02, Arun Raghavan  wrote:
> I don't understand what you expect the council to do in some of these
> cases. Taking the website redesign or consolidation of documentation
> as examples, do you want them to:
>
> a) Decide that this should be done?
> b) Call for volunteers? (they obviously cannot force anyone to do it)
> c) Do it themselves?
> d) What you probably mean that I fail to see

Mostly, I want them to show leadership. I want the council to affirm
that these are important goals, to raise awareness of where our weak
areas are, and what needs to be done to improve things. And yes, I
want the council to call for volunteers, and where necessary to
recruit people who are able to help.

-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Markos Chandras]

On Wednesday 07 April 2010 21:41:49 Nirbheek Chauhan wrote:
> On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras  
wrote:
> > On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
> > Just a question:
> > 
> > Why do we even need to care about ChangeLog files? Can't we just use the
> > git commit message to generate logs? E.g run a script on server side
> > which will read the whole git shortlog and generate a changelog every
> > $timeframe?
> 
> You seem to have missed the gist of the situation. I'm quoting it here
> again to highlight it:
> 
> * It makes zero sense to manually manage ChangeLogs in git[1]
> [snip]
> * Proposed is to generate ChangeLogs from git commits on the rsync
> server side when metadata generation is done
>  - Scripts to do this already exist[1]
> [snip]
> 
> 1. http://live.gnome.org/Git/ChangeLog
Ah you are right. It seems that I missed that e-mail on my inbox. Thanks for 
posting it again.
It seems we are on the same page :)
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[gentoo-dev] Re: Should we disable RESOLVED LATER from bugzilla?

[Christian Faulhammer]

Hi,

Petteri Räty :
> I don't think later is valid resolution. If there's a valid bug it
> just means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? I would like to avoid things like this:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
> 
> Not applicable to the bug above but in general our social contract
> says: "We will not hide problems"

 Kill REMIND and LATER, introduce Later keyword or ASSIGNED LATER.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://gentoo.faulhammer.org/>



signature.asc
Description: PGP signature

Re: [gentoo-dev] Council meeting 19 April 2010

[Richard Freeman]

On 04/07/2010 11:00 AM, Denis Dupeyron wrote:

5. centralize developer documentation
=


This is an interesting idea which I believe I have seen discussed on
irc at some point. Feel free to work on a GLEP to address that.



To be honest, this doesn't even need a GLEP so much as a website or 
something.  If somebody consolidated all this stuff into a reasonable 
format, I bet that half the devs would pitch in and make their 
contributions.  The only thing that might warrant a GLEP is a policy 
decision that all development policies must be documented or linked from 
that site to be binding, or something like that.


I don't think that for the council to make a policy decision that there 
needs to be a GLEP.  Sure, it is the best way to make big changes, or 
changes that require some level of formality.  However, the council can 
still show leadership in affirming their agreement on issues even if it 
isn't a formal affair.  I'm sure every other town government in the 
Western World has taken a vote in support of their troops or something 
like that without going through the official lawmaking process and all 
that - it is just a gesture.


I don't have the time to create such a website although I would agree 
that it is sorely needed.  Hence, I will try to be careful in throwing 
around criticism - it is much easier to bring problems to the table than 
solutions...


Rich

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Enrico Weigelt]

* Maciej Mrozowski  schrieb:

Hi,

> Apart from PDEPEND, one change needed as well in cups ebuilds:
> --with-pdftops pdftops
> needs to be replaced with
> --with-pdftops=/usr/bin/pdftops
> 
> as otherwise it will fail during configure phase (giving absolute path 
> disables autodetection)

Hardcodig a pathname is not a good idea, IMHO.
If ./configure really insists on autodetection when given name is
not absolute, we should fix the source ;-p

> cups can use either poppler or ghostscript as pdf-to-ps filter, 
> so given the fact that ghostscript is already a dep of cups, 
> maybe --with-pdftops=gs could be used instead to avoid poppler 
> dependency completely, but that's up to cups maintainers to 
> determine whether it's safe/desired.

hmm, does it _really_ need gs, even when pdftops is used ?

maybe we could move out this whole issue to an wrapper script
(configurable via eselect) ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Enrico Weigelt]

* Nirbheek Chauhan  schrieb:
> On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot  wrote:
> > Would it be possible to make cups a PDEPEND in gtk+ or is it really
> > needed at compile time?
> >
> 
> cups is definitely needed at compile-time

Does anyone know what exactly for ?
Didnt have the time for an deeper investigation, but if an widget
toolkit requires an printing service, something really strange
is happening, IMHO ... ;-o


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Nirbheek Chauhan]

On Thu, Apr 8, 2010 at 4:13 AM, Enrico Weigelt  wrote:
> * Nirbheek Chauhan  schrieb:
>> On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot  wrote:
>> > Would it be possible to make cups a PDEPEND in gtk+ or is it really
>> > needed at compile time?
>> >
>>
>> cups is definitely needed at compile-time
>
> Does anyone know what exactly for ?
> Didnt have the time for an deeper investigation, but if an widget
> toolkit requires an printing service, something really strange
> is happening, IMHO ... ;-o
>

Download the gtk+ tarball and take a peek inside ./modules/printbackends/cups

You'll find your answer there.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Enrico Weigelt]

* Nirbheek Chauhan  schrieb:

> If it turns out there is no easier way of properly fixing this, 
> we may have to split poppler-utils out from poppler. 

ACK. Having separate packages for public libraries and utils
which just happen to use these libs should be the default case.
Not just because of circular deps - which, in 99.99% have 
absolutely _no_ technical reason, beside certain people's mental 
lazyness (at least that's what my about 20yrs swe experience 
shows up ;-o) - but also a matter of clean sw design.

This should start at the source, so if upstream doesnt want to
fix this, let's fork. (i'm hereby volunteering as maintainer).


cu

PS: please no "we're not debian"-flamewars ;-o
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Enrico Weigelt]

* Ben de Groot  schrieb:

> Or maybe the gtk+ maintainers want to split up their package... 

Actually, that would be a big step forward ...


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Nirbheek Chauhan]

Why are you replying to a thread that has already been resolved? Please stop.

On Thu, Apr 8, 2010 at 4:43 AM, Enrico Weigelt  wrote:
> * Nirbheek Chauhan  schrieb:
>
>> If it turns out there is no easier way of properly fixing this,
>> we may have to split poppler-utils out from poppler.
>
> ACK. Having separate packages for public libraries and utils
> which just happen to use these libs should be the default case.
> Not just because of circular deps - which, in 99.99% have
> absolutely _no_ technical reason, beside certain people's mental
> lazyness (at least that's what my about 20yrs swe experience
> shows up ;-o) - but also a matter of clean sw design.
>
> This should start at the source, so if upstream doesnt want to
> fix this, let's fork. (i'm hereby volunteering as maintainer).
>
>
> cu
>
> PS: please no "we're not debian"-flamewars ;-o
> --
> -
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> -
>  Please visit the OpenSource QM Taskforce:
>        http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
>        http://patches.metux.de/
> -
>
>



-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Enrico Weigelt]

* Nirbheek Chauhan  schrieb:

> > Does anyone know what exactly for ?
> > Didnt have the time for an deeper investigation, but if an widget
> > toolkit requires an printing service, something really strange
> > is happening, IMHO ... ;-o
> >
> 
> Download the gtk+ tarball and take a peek inside ./modules/printbackends/cups
> 
> You'll find your answer there.

Yes, sometimes answers you'd even wouldn't like to know ;-o

Folks, these gtk guys are on bad drugs (well, that's not sucha
new enlightenment ;-o) ...

a) gtk-printer backends are separate *shared* libraries, which
   are loaded somewhere at runtime. absolutely no need to ship
   and build them within the gtk+ tree
 
b) the whole gtk-printer api might be a nice thing (even i just
   have a dozen of better solutions at the tip of my head ;-o),
   but I can't see any technical reasons for having that all
   within a widget toolkit, instead of a separate library.


hmm, time for a fork ? ;-)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 4:30 PM, Richard Freeman  wrote:
> Sure, it is the best way to make big changes

Why then use anything else than the best tool when you can use the
best tool? I didn't say that he should work on a GLEP though, but that
he should "feel free" to do so, which is different. That meant that if
he thought there was a point to it, was willing to do it, etc...

Just a note about this. The council could for example make the
decision to centralize all the documentation in a wiki, force the doc
team to use tools they haven't chosen or even take that responsibility
out of their hands. Basically step on their toes. Nice way to show
respect for all the hard work they've done for years. Or this could be
discussed on the relevant mailing-list(s) by everybody who feels
concerned, input from the whole community (including the doc team)
could be gathered, council members could chime in (I usually do),
dissenting opinions could be documented, a consensus could be reached
and then design decisions could be documented. See GLEP 1 for more
information on that work flow.

Gentoo has been driven by consensus since Daniel left, for better or
for worse. You might not like this way to work, but that's OK. I
didn't say I thought it was optimal either. All I know is I'm going by
the book, but it allows me to rewrite some pages when I don't like
them. The good news is that during the last meeting the council has
decided to initiate an overhaul of GLEP 39. I'm still gathering
material from various sources to start the discussions open to all
users and developers. At that point you'll have the opportunity to
suggest anything you think may improve the way the council works.

> However, the council can
> still show leadership in affirming their agreement on issues even if it
> isn't a formal affair.

We don't need a meeting for that. We can show leadership on the
mailing-lists everyday. What do you think I'm doing right now for
example? And by the way I don't believe that issuing a statement along
the lines of "Yep, we agree" shows any leadership at all.
Additionally, leadership is not about doing your job. You may want to
peruse the council meeting logs and summaries for examples of
leadership, and vote for real leaders next time if you think we suck.

> I'm sure every other town government in the Western
> World has taken a vote in support of their troops or something like that
> without going through the official lawmaking process and all that - it is
> just a gesture.

We've been down that road many times before, but let me say it again:
Gentoo is not a government, so any comparison to one is pointless.

> I don't have the time to create such a website although I would agree that
> it is sorely needed.  Hence, I will try to be careful in throwing around
> criticism - it is much easier to bring problems to the table than
> solutions...

Wise words, although constructive criticism is always welcome. In
order to be really constructive however, criticism needs among other
things to take into account goals, resources, history and rules.

Denis.