Re: [gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-11 Thread Jose Luis Rivero

Mark Loeser wrote:

Jose Luis Rivero [EMAIL PROTECTED] said:
Mark, I think you are looking at the problem only with the ebuild 
maintainer hat put on. We have other players in our business, being one of 
them the users. This policy would bring too many problems to them so .. 
nono by my side.


I purposely did this.  I like the proposal, but I also know that it has
a lot of problems.  It was better than sending something out asking what
people think though.


Indeed.

I would prefer to analyze the causes of the slacker arch (manpower, 
hardware, etc) and if we are not able to solve the problem by any way 
(asking for new devs, buying hardware, etc) go for mark it as experimental 
and drop all stable keywords.


This is one way to resolve it.  We need to establish how an arch gets
pushed to experimental and how maintainers need to deal with that
though.  An example is removing the only version of a package that works
on that specific arch, is this a problem if the arch is declared to be
experimental?

If this is the path we want to go down, lets set up some rules for how
to handle experimental archs and what it means to go from
stable-experimental and experimental-stable.


Now we are thinking the same, brother. Clear procedures and rules for 
moving an arch to experimental and what keyword policy applies to 
experimental. Also, what is needed to allow an experimental arch to 
start its stable branch and be sure we are not going to be moving from 
experimental - stable every month.


If someone want to start thinking more seriously about this, count me in.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Doc



Re: [gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-11 Thread Jose Luis Rivero

Richard Freeman wrote:

Jose Luis Rivero wrote:
I would prefer to analyze the causes of the slacker arch (manpower, 
hardware, etc) and if we are not able to solve the problem by any way 
(asking for new devs, buying hardware, etc) go for mark it as 
experimental and drop all stable keywords.


How is that better?  Instead of dropping one stable package you'd end up 
dropping all of them.  A user could accept ~arch and get the same 
behavior without any need to mark every other package in the tree 
unstable.  


Accept ~arch for the random package which has lost the stable keyword a 
random day? And next week .. which is going to be the next? The key is 
the concept 'stable' and what you hope of it.


A long/middle-term solution for arches with very few resources instead 
of generating problems to users seems a much better approach to me.


An arch could put a note to that effect in their installation 
handbook.  The user could then choose between a very narrow core of 
stable packages or a wider universe of experimental ones.


Mixing software branches is very easy in the Gentoo world but it has 
some problems. Are you going to install in your stable (production, 
critial, important,...) system a combination of packages not tested 
before? Because the arch teams or the maintainers are not going to test 
every posible combination of core stable + universe of experimental 
packages. This is why branches exists.


I guess the question is whether package maintainers should be forced to 
maintain packages that are outdated by a significant period of time. 
Suppose something breaks a package that is 3 versions behind stable on 
all archs but one (where it is the current stable).  Should the package 
maintainer be required to fix it, rather than just delete it?  


Maintainer has done all he can do, this means: that is broken, this 
version fix the problem, go for it. Maintainer's job finishes here, now 
 it's the problem of your favorite arch team.


I suspect 
that the maintainer would be more likely to just leave it broken, which 
doesn't exactly leave things better-off for the end users.


It's a different approach (maybe with the same bad results) but 
different anyway. Leave the bug there, point the user to the bug and 
maybe you can gain a new dev or an arch tester.


While the proposal made here is to throw random keyword problems to 
users by policy (which in the case of amd64 some months ago would have 
created a complete disaster).


I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise 
discretion on removing stable versions of these packages.  However, for 
some obscure utility that next-to-nobody uses, does it really hurt to 
move from stable back to unstable if the arch maintainers can't keep up?


Special cases and special plans are allowed, what we are discussing here 
is a general and accepted policy.


I guess it comes down to the driving issues.  How big a problem are 
stale packages (with the recent movement of a few platforms to 
experimental, is this an already-solved problem?)?  How big of a problem 
do arch teams see keeping up with 30-days as (or maybe 60/90)?  What are 
the practical (rather than theoretical) ramifications?


An interesting discussion. Ask our council to listen all parts: 
maintainers, current arch teams, the experience of mips, etc. and try to 
make a good choice.


Thanks Richard.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Do



Re: [gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-10 Thread Jose Luis Rivero

Mark Loeser wrote:

Removing Stable Ebuilds

If an ebuild meets the time criteria above, and there are no technical issues
preventing stabilization, then the maintainer MAY choose to delete an older
version even if it is the most recent stable version for a particular arch.


Mark, I think you are looking at the problem only with the ebuild 
maintainer hat put on. We have other players in our business, being one 
of them the users. This policy would bring too many problems to them so 
.. nono by my side.


I would prefer to analyze the causes of the slacker arch (manpower, 
hardware, etc) and if we are not able to solve the problem by any way 
(asking for new devs, buying hardware, etc) go for mark it as 
experimental and drop all stable keywords.


Thanks.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Alpha Gentoo/Doc




Re: [gentoo-dev] GCC 4.3 pre-stabilization

2008-11-01 Thread Jose Luis Rivero

Ryan Hill wrote:

In anticipation of getting GCC 4.3 stabilized sometime, I'd like to ask
maintainers check if their current stable packages build with 4.3, and
if not please stabilize a version that does in the near future if at
all possible.  Stabilizing this version is going to be a huge job due
to the number of packages that don't compile due to implicit C++
standard library header dependencies that got cleaned up in 4.3.[i], so
anything you could do ahead of time to save our sanity would be
greatly appreciated.



What version is the candidate to reach stable? 4.3.2?

Thanks.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha



Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Jose Luis Rivero
On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
 On 02:03 Tue 14 Oct , Jose Luis Rivero wrote:
  
  There are some others sceneries but are not so common as the one presented
  could be. Any decent solution for this case?
 
 There are only a few obvious ones, you'll have to pick which one you 
 like best. Most of the other options basically duplicate these in some 
 way or add more work to them for negligible gain:
 
 - Backport the ebuild from EAPI=2 to EAPI=0

EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
going to happen when we release new and more feature rich EAPIs), and
changes usually come with bugs. The ebuild is committed directly to stable
implies bugs in stable, which for me is a no-go.

 - Backport the security patch to the EAPI=0 ebuild

Which sometimes is going to be impossible, require lot of work, and we
fall into the risk of bad backported patches when non trivial backport
patches are needed (which turns into buggy patches in the stable branch)

 - Stabilize portage quickly

Most of the times this is not going to be possible. Seems to me that EAPI 
changes are not trivial to PMs and need some kind of decent testing
period. 

Thanks.

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha




[gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-13 Thread Jose Luis Rivero
Hi all:

Reading a random discussion in our dev mailling list, I came with a
doubt about our new EAPI policy and its procedures. I couldn't find it
documented nor discussed anywhere so I bringing it here.

Supposing that anyone can currently add an ebuild using EAPI-2 under the
testing branch: what are we going to do if an EAPI-2 ebuild (which are
only managed by ~arch package managers) needs to go stable due to some
kind of major reason like security? 

Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2)
with new features marked as testing. A security problem appears
affecting both. UPSTREAM release foo-3 to solve the security issue.

There are some others sceneries but are not so common as the one presented
could be. Any decent solution for this case?

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha




Re: [gentoo-dev] why not player/stage/gazebo

2008-05-18 Thread Jose Luis Rivero
On Fri, May 16, 2008 at 06:33:15PM -0300, Zhu Sha Zang wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Someone can speak to me why this programs aren't in portage tree, cos
 they are a good programs to robotic area? I finded only this packages in
 overlay, but so old. If i wish to put this sources in portage what i
 need to do?
 

I'm currently working for a robotics research lab and I've seen my
co-workers using these apps lots of times. I'm interesting in this area,
involved in an Humanoid project and familiar with the basics of robotics 
although I have no current experience with the apps.

Please, contact me out of the list and we'll see how can we improve
the robotics support in Gentoo.

Thanks Zhu.

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Available hardware

2008-01-16 Thread Jose Luis Rivero
On Tue, Jan 15, 2008 at 04:25:21PM -0800, Daniel Ostrow wrote:
 1x Dec/Compaq PWS 600 600 MHz Alpha

I'm quite interested in the Alpha machine since toolchain debugging is
not always fine to do in a remote enviroment. Just a couple of things:

 - I can pay a reasonable price to move it from US to Spain but dunno if
   it will be too much. Anyone know how much it could cost?

 - If someone is able to provide a box like this in Europe, I
   would be very grateful.

 - If any of the Gentoo developers wants to join Gentoo/Alpha picking
   this box please let me know.

@Daniel: thanks for the offer, let's continue talking about it in private 
mails.

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for December

2007-12-01 Thread Jose Luis Rivero
On Sat, Dec 01, 2007 at 05:45:02AM +, Mike Frysinger wrote:
 This is your monthly friendly reminder !  Same bat time (typically
 the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
 (#gentoo-council @ irc.freenode.net) !
 
 If you have something you'd wish for us to chat about, maybe even
 vote on, let us know !  Simply reply to this e-mail for the whole
 Gentoo dev list to see.
 

The new USE documentation discussion was mailed to the council by
flameeyes after the first posts in gentoo-dev[1], but I'm not sure if 
it's really in the agenda so, please, consider it to be discussed.

I would suggest this kind of question based on the different ideas shown
by the developers comunity:

 - What is proper way to make changes to ebuild related information
   (metadata.dtd)? Do we need a GLEP? It only need to be discussed in -dev
   first? Gentoo-doc is who control metadata.dtd?

And depends on the conclusion, please think if the current USE
documentation specified in metadata.xml is consider as final.

Thanks.

P.D: This is not a post to discuss the new USE documentation (again), is
just a request to the council to decide in this area where we
(developers) have different points of view.

[1] http://archives.gentoo.org/gentoo-dev/msg_149120.xml

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] New USE flags documentation

2007-11-24 Thread Jose Luis Rivero
Hi all:

I've read on the planet the recently included support to document USE
flags in metadata. Seems like it was an idea from flameeyes and cardoe,
discussed on the planet [1][2] and performed by -infra (bug #199788).

While planet is a good medium to share ideas and get contributors, seems to
me like we need a more official way to discuss this kind of 'global'
ideas before make them real. Or at least drop a note on -dev-announce
explaining the new feature and telling devs and users this is now
officially supported.

I'm not asking for an extra overhead of 'bureaucracy' (write specs,
mailling @dev, send to the council, etc.) but a bit more of communication 
would be appreciated:

Is the feature ready to be used? Is there any kind of documentation
(aside of DTD)? It will replace use.desc?

Thanks. 

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2007/11/24/proposing-more-use-flag-documentation
[2] http://blog.cardoe.com/archives/2007/11/23/metadataxml-updates-examples/

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08

2007-07-17 Thread Jose Luis Rivero (YosWinK)
I'm missing some people in the nominees list which everytime they appear 
is to give solutions or ideas in a positive way, what for me is a 
pleasure to find:


dsd  (Daniel Drake)
lu_zero  (Luca Barbato)
zmedico  (Zac Medico)

Thanks.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha
--
[EMAIL PROTECTED] mailing list



[gentoo-dev] Gentoo/Alpha status

2007-06-09 Thread Jose Luis Rivero (YosWinK)

Hi all:

After kloeri's leaving, the Gentoo/Alpha crew wants to make a little
note about the status of the arch team:

Devs:
-
 - armin(general keywording)
 - ferdy(general keywording and AT program)
 - spb  (selinux stuff)
 - stefaan  (openAFS)
 - wolf (release stuff and keywording)
 - yoswink  (general keywording)
 - Spanky   (general fixing)

Contributors

 - grknight  (arch tester)
 - blackb|rd (dev box admin and testing)

Leadership
--
ferdy is our new Strategic Leader. One leader is enough for such a
reduced group.

Security

We are going to keep the status of security supported arch and ferdy is
also the new security laison though the rest of us generally work on
security bugs too.

Dev boxes
-
After Virginia University announced it can't support our 7 box cluster
anymore, we've changed our dev box to a lovely AlphaServer ES40. We are
also waiting to osuosl to put on-line some boxes HP donated years ago.

Acknowledgements

During the last times, there were some changes in the people and
entities who have helped Gentoo/Alpha in different ways. We want to send
a big thanks to: Virginia University (and special to Dforge, for all the
support with the gendcc cluster), Tobias Klausmann (for providing the
new dev box), HP and OSUOSL (for the boxes and hosting) and, specially,
to Bryan (kloeri) for being always the great mentor and person we had in
#gentoo-alpha channel.

Thanks.

P.D: for those of you worried out there: *NO*. Gentoo/Alpha is *not*
going to have a different default package manager than the rest of Gentoo ;)

--
Life is not so serious, leave the flames and find a real vicious.

Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

2007-05-01 Thread Jose Luis Rivero (YosWinK)

Petteri Räty wrote:

Mike Frysinger kirjoitti:

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.



I would like the council to remind everyone that this is not appropriate
for any team:
https://bugs.gentoo.org/show_bug.cgi?id=176256#c4



The alpha arch team is *fully* agree with sparc in this case (as many 
others) and hope the council make a clear statement against this kind of 
keywording, which we think can create many more problems than solutions.


We *really* appreciate the great job doing by our games herd (one of the 
best out there) but, in this case, this is not the way to follow.


Thanks.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-11 Thread Jose Luis Rivero (YosWinK)

Mike Frysinger wrote:
well it's about that time of the year ... time for nominating people 
for the next Gentoo Council




I would like to nominate kloeri (Bryan Østergaard) to the council if he 
has enough free time and if his devrel lead position (where his work is 
priceless) doesn't block the nomination.


Thanks.

--
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New Developer: Lukasz Damentko

2005-09-11 Thread Jose Luis Rivero (YosWinK)

Sven Vermeulen wrote:

On Fri, Sep 09, 2005 at 12:21:30AM +0200, Jan Kundrát wrote:


internal GDP joke
Is staking, poking out of the eyes and burning of hands considered a
warm welcome? :-)
/internal GDP joke



Must have missed a few memo's. I thought only YoswinK was allowed to do
this.



You know some people want to use my methods ... bah! impostors!

Btw, i see it's too late to stop dev status for rane so ... i'll say:
- be careful, you know what you don't have to touch.

--
YosWinK @ gentoo.org
Gentoo Doc Spanish Team
Gentoo Alpha
--
gentoo-dev@gentoo.org mailing list