Kumba [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted
below, on Mon, 11 Jun 2007 21:25:14 -0400:
It's competition, at the core. No one likes draws, ties, or even photo
finishes, let alone losing. They like to win, and win by a large
margin. If someone tries to slip the last word in
Matthias Langer [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Mon, 11 Jun
2007 22:10:52 +0200:
On Mon, 2007-06-11 at 19:01 +0200, Alexander Gabert wrote:
[snipped]
if you came to the conclusion, that ciaranm is some kind of ultra-nasty
troll, then why is it so hard for you
Duncan wrote:
Kumba [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted
below, on Mon, 11 Jun 2007 21:25:14 -0400:
It's competition, at the core. No one likes draws, ties, or even photo
finishes, let alone losing. They like to win, and win by a large
margin. If someone tries to slip the
Hi,
# Christian Faulhammer [EMAIL PROTECTED] (12 Jun 2007)
# mask for removal:
# upstream dead, does not work with current Emacs 22
# replacement is app-emacs/slime{,-cvs}
app-emacs/ilisp
app-emacs/ilisp-cvs
V-Li
signature.asc
Description: PGP signature
Hi all,
I think it's worth to discuss the `behaviour of removing ebuilds from
the tree`.
In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets
updated
the older ebuild gets removed in the same turn. In my opinion, it is
better to
keep the older ebuild around for a while
cilly [EMAIL PROTECTED]:
What do you think?
I agree with that.
PS: other topics to be discussed `Not to modify ebuilds which are
already in the tree... even if masked` what do you think?
Explain please.
--
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/
On Jun 12, 2007, at 11:49 AM, Christian Faulhammer wrote:
PS: other topics to be discussed `Not to modify ebuilds which are
already in the tree... even if masked` what do you think?
Explain please.
I will start a new topic on that.
cec
--
[EMAIL PROTECTED] mailing list
cilly wrote:
Hi all,
I think it's worth to discuss the `behaviour of removing ebuilds from
the tree`.
Currently it's up to the developer, some people are more conservative,
some prefer to get rid of certain stuff asap.
You should differentiate between ~ and stable ones btw...
In my
On Tue, Jun 12, 2007 at 11:40:26AM +0200, cilly wrote:
In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets
updated the older ebuild gets removed in the same turn. In my
opinion, it is better to keep the older ebuild around for a while
since if there are some bugs in the
On Tue, Jun 12, 2007 at 11:59:28AM +0200, Luca Barbato wrote:
lu - that prefers less rules and more people aware.
Couldn't agree more.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgpliNQUioYQL.pgp
Description: PGP signature
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which are
already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the
version-number, i.e. ebuild-r1 is in the portage tree and the ebuild-
r1 gets
On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote:
I think that setting arbitrary guidelines that try to rule every
situation is just *plain* wrong.
Some of the packages I maintain are better removed when a new
maintenance version is released. And I plan to keep it that way :)
As usual,
On Tue, Jun 12, 2007 at 12:07:11PM +0200, cilly wrote:
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which are
already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the version-number, i.e.
cilly wrote:
What do you think?
There is already a guideline about it it basically says :
Every changes that just fix an issue for a certain deals of users (e.g.
optional dep version bump, different use handling, anything that makes
the program not build just in that particular case BUT
cilly kirjoitti:
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which are
already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the
version-number, i.e. ebuild-r1 is in the portage tree and the
On Tue, Jun 12, 2007 at 12:14:37PM +0200, cilly wrote:
On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote:
I think that setting arbitrary guidelines that try to rule every
situation is just *plain* wrong.
Some of the packages I maintain are better removed when a new
maintenance
On Jun 12, 2007, at 12:21 PM, Luca Barbato wrote:
There is already a guideline about it it basically says :
Every changes that just fix an issue for a certain deals of users
(e.g.
optional dep version bump, different use handling, anything that
makes
the program not build just in that
On Jun 12, 2007, at 12:20 PM, Petteri Räty wrote:
http://devmanual.gentoo.org/general-concepts/ebuild-revisions/
index.html
This is the current policy. So far it has worked quite well for me
at least.
Okay, does this include ~ packages? And what about hard masked ones?--
[EMAIL PROTECTED]
On Jun 12, 2007, at 12:21 PM, Fernando J. Pereda wrote:
Well, if maintainers can't properly follow upstream development they
should probably seek help in their maintenance job.
Hi Fernando,
well, I wouldn't bring up this discussion if there aren't any
problems. I `think` a reminder to all
Fernando J. Pereda wrote:
Some of the packages I maintain are better removed when a new
maintenance version is released. And I plan to keep it that way :)
Can you clarify this? What scenarios do you run into where it isn't
good for stable users to have access to more than one version of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
well, I wouldn't bring up this discussion if there aren't any problems.
Hi Cecilia,
perhaps you could go into some more specifics of these problems?
Which packages were removed and were they stable, testing or masked at the
time of
Richard Freeman wrote:
Can you clarify this? What scenarios do you run into where it isn't
good for stable users to have access to more than one version of the
software?
- Security issues.
- Downgrade to hell scenarios
- Other colorful issues that may happen from time to time.
One thing
On Tue, Jun 12, 2007 at 06:36:31AM -0400, Richard Freeman wrote:
Fernando J. Pereda wrote:
Some of the packages I maintain are better removed when a new
maintenance version is released. And I plan to keep it that way :)
Can you clarify this? What scenarios do you run into where it isn't
On Jun 12, 2007, at 12:40 PM, Marijn Schouten (hkBst) wrote:
Hi Cecilia,
perhaps you could go into some more specifics of these problems?
Which packages were removed and were they stable, testing or masked
at the
time of removal? What problems did the removal cause?
Marijn
Hi Marijn,
On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote:
Keep in mind that the trade off is :
- our time
- our sanity
- what provide to our used
- the quality of what we provide to out users.
We all try our best to not burn out while serving you the best we
could
think.
Does it make such a
On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
Known to be buggy versions.
Of course, there are bugs in every version. Sometimes a user must be
able to choose which bug is more problematic, i.e. the bug in the
newer ebuild which makes the package unusable for them or the older
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Freeman wrote:
One thing that I noticed is that in many cases there are multiple
testing versions of a package available, and one stable version. So, if
you run unstable you can pick and choose, but if you're running stable
(which in
On Jun 12, 2007, at 12:53 PM, cilly wrote:
Of course, there are bugs in every version. Sometimes a user must
be able to choose which bug is more problematic, i.e. the bug in
the newer ebuild which makes the package unusable for them or the
older bug which has a security issue the users are
On Tue, Jun 12, 2007 at 12:53:16PM +0200, cilly wrote:
On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
Known to be buggy versions.
Of course, there are bugs in every version. Sometimes a user must be able to
choose which bug is more problematic, i.e. the bug in the newer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
please, understand that I do not want to `blame` any developer, unless
it is discussed here with a final solution. Since I am not a gentoo-dev,
some of the devs `may not understand` my concerns and probably `feel
offended`.
Hi
On Tue, 12 Jun 2007 12:07:11 +0200
cilly [EMAIL PROTECTED] wrote:
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which
are already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the
cilly kirjoitti:
On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote:
Keep in mind that the trade off is :
- our time
- our sanity
- what provide to our used
- the quality of what we provide to out users.
We all try our best to not burn out while serving you the best we could
think.
On Jun 12, 2007, at 1:03 PM, Fernando J. Pereda wrote:
If the user thinks he knows better than me which version he wants to
use, there is the code. I'll still keep in Gentoo's tree whatever *I*
feel it is best for every gentoo user.
Fernando, I do not complain against you, may be if everyone
cilly wrote:
Sometimes the chance for the users to place the ebuild comfortably into
overlay is simply taken, since the ebuild has been removed and doesn't
exist after a sync anymore.
any ebuild from day 0 till now lives in the cvs, you can fetch it from
the cvs attic anytime, I'm afraid this
Richard Freeman [EMAIL PROTECTED]:
One thing that I noticed is that in many cases there are multiple
testing versions of a package available, and one stable version. So,
if you run unstable you can pick and choose, but if you're running
stable (which in theory should be the target audience
On Tue, 12 Jun 2007 12:59:42 +0200
cilly [EMAIL PROTECTED] wrote:
On Jun 12, 2007, at 12:53 PM, cilly wrote:
Additional:
Sometimes the chance for the users to place the ebuild comfortably
into overlay is simply taken, since the ebuild has been removed and
doesn't exist after a sync
On Jun 12, 2007, at 1:27 PM, Luca Barbato wrote:
any ebuild from day 0 till now lives in the cvs, you can fetch it from
the cvs attic anytime, I'm afraid this information isn't exactly well
known =/
I am aware of it, but this means much more frickle-time (forget
frickle if you don't know it
On Jun 12, 2007, at 1:29 PM, Christoph Mende wrote:
It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
and hit Show X dead files in the dir of the ebuild you want ;)
so you misunderstood comfortably :)
--
[EMAIL PROTECTED] mailing list
On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
Hi Marius,
Not realistic. Think about it:
- upstream location for a package changes, so old SRC_URI stops
working. If we don't update the existing ebuild people can't use it
anymore, if we bump it to a new revision existing users have to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
I also recommend to manage hard-masked packages the same way, it
prevents confusion in
bug-reports.
I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several
On Jun 12, 2007, at 1:21 PM, Petteri Räty wrote:
Nope and they should usually be kept but we can't make a hard rule
because there are cases where the old ebuilds don't work any more. If
you find that a broken version slipped the cracks of the arch teams
and
made it to stable with the old
On Jun 12, 2007, at 1:25 PM, Christian Faulhammer wrote:
That is not by purpose. Most people clean-up a package when
stabilisation round has been done. So I must say clarify my first
statement: I think it is a good idea to have old stable versions in
the
tree, but that should be the
On Jun 12, 2007, at 1:50 PM, Vlastimil Babka wrote:
I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several times
until
unmasked (think about new KDE versions etc). Revbumping with each
change
and then finally
On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:
P.S.: I think you are fighting against windmills here. Most devs are
happy with the current policy, and even I see no urgent point from
your
arguments.
yeah, I already figured out...
--
[EMAIL PROTECTED] mailing list
cilly [EMAIL PROTECTED]:
Okay, I understand that. Just keep in mind, that order bugs to the
ebuilds might be more difficult without changing the version number.
And the guidelines say, if an ebuild is changed the version number
i.e. -rx should be increased.
You have the cvs diff
On Jun 12, 2007, at 1:56 PM, Christoph Mende wrote:
It seems a bit that you didn't fully understand that case. That
package
fails to install for 10% but works flawlessly for the other 90%. Those
10% will get the fix even without a version bump, the other 90% don't,
but that's ok, they don't
On Jun 12, 2007, at 2:05 PM, Christian Faulhammer wrote:
You have the cvs diff abilites and we have a header that says which
CVS revision one is having.
Well, who are bugreporters? I'd say a lot of users report bugs who
don't use CVS at all. And they even don't know about the different
cilly wrote:
So this will require users to file a bugreport, but I for myself am
burned out in filing bugreports related to ebuilds concerning this
matter... I know what is to be done by myself: uncomfortably browsing
the source and packing the older ebuild into overlay.
Another solution
On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:
P.S.: I think you are fighting against windmills here. Most devs are
happy with the current policy, and even I see no urgent point from
your
arguments.
So this will require users to file a bugreport, but I for myself am
burned out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
- a mistake in the ebuild prevents installation for 10% of the users,
but doesn't affect runtime behavior. SHould we bump it just for that
and force the other 90% of the users to
On Jun 12, 2007, at 2:14 PM, Carsten Lohrke wrote:
Could you please stop spamming the list with your one sentence
replies!
Waiting a day and then sending a single subsuming reply to the most
important
arguments suffices completely. The mailing list is not a chat channel.
Carsten
Hi list,
Luca Barbato schrieb:
Another solution could be provide a nice script that does that for you...
Prefix project uses one already ;) Worth trying
Greetz
-jokey
signature.asc
Description: OpenPGP digital signature
cilly wrote:
On Jun 12, 2007, at 2:05 PM, Christian Faulhammer wrote:
You have the cvs diff abilites and we have a header that says which
CVS revision one is having.
Well, who are bugreporters? I'd say a lot of users report bugs who don't
use CVS at all. And they even don't know about
Btw, both of your issues could probably be solved by bug 126059 without
adding new rules or new work for ebuild devs.
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a
On Jun 12, 2007, at 2:55 PM, Marius Mauch wrote:
Btw, both of your issues could probably be solved by bug 126059
without
adding new rules or new work for ebuild devs.
Thanks a lot for this, I totally agree.
--
[EMAIL PROTECTED] mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
Known to be buggy versions.
Of course, there are bugs in every version. Sometimes a user must be
able to choose which bug is more problematic, i.e. the bug in the newer
cilly [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on
Tue, 12 Jun 2007 12:59:42 +0200:
On Jun 12, 2007, at 12:53 PM, cilly wrote:
Of course, there are bugs in every version. Sometimes a user must be
able to choose which bug is more problematic, i.e. the bug in the newer
On Mon, Jun 11, 2007 at 02:35:42PM +0200, Alexander Gabert wrote:
You left the project and it's your choice to continue working with it and on
it.
Nonono, you got it all wrong.
He didn't leave, he was fired [1].
cheers,
Wernfried
[1] https://bugs.gentoo.org/show_bug.cgi?id=114944
On Tue, 12 Jun 2007 21:00:55 +0200
Wernfried Haas [EMAIL PROTECTED] wrote:
On Mon, Jun 11, 2007 at 02:35:42PM +0200, Alexander Gabert wrote:
You left the project and it's your choice to continue working with
it and on it.
Nonono, you got it all wrong.
He didn't leave, he was fired [1].
On Mon, Jun 11, 2007 at 10:54:31PM +0100, Steve Long wrote:
after all Paludis is useless without the portage tree.
Untrue.
--
Alexander Færøy
--
[EMAIL PROTECTED] mailing list
Am Dienstag, den 12.06.2007, 20:46 +0100 schrieb Stephen Bennett:
On Tue, 12 Jun 2007 21:00:55 +0200
Wernfried Haas [EMAIL PROTECTED] wrote:
On Mon, Jun 11, 2007 at 02:35:42PM +0200, Alexander Gabert wrote:
You left the project and it's your choice to continue working with
it and on
Am Dienstag, den 12.06.2007, 21:57 +0200 schrieb Alexander Færøy:
On Mon, Jun 11, 2007 at 10:54:31PM +0100, Steve Long wrote:
after all Paludis is useless without the portage tree.
Untrue.
Care to elaborate?
That would also mean, that a harddisk isn't useless without any
platters.
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels; not only against developers
but also against volunteering users.
So do most people on this list.
--
[EMAIL
Am Dienstag, den 12.06.2007, 17:23 -0400 schrieb Stephen P. Becker:
On Tue, 12 Jun 2007 23:12:27 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
Am Dienstag, den 12.06.2007, 21:57 +0200 schrieb Alexander Færøy:
On Mon, Jun 11, 2007 at 10:54:31PM +0100, Steve Long wrote:
after all
Am Dienstag, den 12.06.2007, 22:44 +0100 schrieb Stephen Bennett:
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels; not only against developers
but also
On Tue, 12 Jun 2007 23:42:45 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
Let's see...CRAN repository support, rubygems support, not to
mention the QA and search tools which may be used on any ebuild
overlay or repository.
Oh, and all these repositories are not organized as a
Benjamin Judas wrote:
Am Dienstag, den 12.06.2007, 22:44 +0100 schrieb Stephen Bennett:
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels; not only
Stephen Bennett wrote:
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels; not only against developers
but also against volunteering users.
So do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya A. Volynets-Evenbakh wrote:
Stephen Bennett wrote:
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
Am Dienstag, den 12.06.2007, 20:46 +0100 schrieb Stephen Bennett:
On Tue, 12 Jun 2007 21:00:55 +0200
Wernfried Haas [EMAIL PROTECTED] wrote:
On Mon, Jun 11, 2007 at
2007-06-11, Matti Bickel sanoi:
Christian Faulhammer [EMAIL PROTECTED] wrote:
Olivier Galibert [EMAIL PROTECTED]:
So my question is, what could I do to help having it end up in the
official package database?
Become a developer.
From the looks of it, there's already a gentoo
Steev Klimaszewski wrote:
Ilya A. Volynets-Evenbakh wrote:
Stephen Bennett wrote:
On Tue, 12 Jun 2007 23:10:32 +0200
Benjamin Judas [EMAIL PROTECTED] wrote:
...which means that he has a documented history of trolling not only
on mailinglists but also in irc-channels; not only
Steev Klimaszewski wrote:
So this other list would allow non-civil discussions to continue and
rage on? I mean, you wouldn't have to be civil to others on it, you
could just join and start trolling everyone?
Read the bug I filed with infra. You'll find the answer to this there.
--Kumba
73 matches
Mail list logo
