On Mon, Jan 17, 2011 at 10:04 AM, Ronald van Haren pressh@gmail.com wrote:
On Mon, Jan 17, 2011 at 12:41 AM, Seblu seblu@seblu.net wrote:
On Sun, Jan 16, 2011 at 10:09 PM, Ronald van Haren <c> wrote:
Some pointers
- cairo-xcb is broken and unmaintained by upstream
http://cgit.freedesktop.org/cairo/log/ i see several commit from this january about xcb. Reading changelog, the backend does not seem abandoned.
i see activity on ml: http://lists.cairographics.org/archives/cairo/2010-December/thread.html http://lists.cairographics.org/archives/cairo/2010-November/thread.html http://lists.cairographics.org/archives/cairo/2010-October/thread.html
i see patched on last release changelog: http://cairographics.org/news/cairo-1.10.2/
- cairo-xcb is known to cause X crashes and rendering issues
Crawling arch bugtracker is not really revelent of this. I don't find many bugs around this issue (maybe not detected as corollary). RedHat bug is not really accurate.
I also use cairo-xcb from aur everyday and i don't see issues.
- crashes and redering issues will probably appear in other
applications than awesome
Sure! This is to avoid.
- people don't know that they are using something that is unsupported
(at least by upstream)
Upstream speak about experimental feature, not unsupported (see README). By our bleeding edge point of view, we enable a lot of experimental feature (in particular in linux kernel). Experimental "tag" is not always a synonym of unstable (or unsuported) but more like really Bleeding edge.
- it is generally a bad idea to support something which is encouraged
not to by upstream
I agree. But i'm wondering why debian include it by default in next release (squeeze) http://git.debian.org/?p=collab-maint/cairo.git;a=blob;f=debian/rules;h=9270...
I see in configure, they include --enable-xlib and --enable-xcb. _Maybe_ we can enable the two to have the best of both worlds. This need more investigation.
So unless you want to fix all issues in cairo-xcb, it is probably not a good idea to support it. In case you will, upstream is also looking for a maintainer of the xcb backend if I'm not mistaken.
I don't see the job offer :)
But then again, you may need to first fix all issues before you bring it in :-)
I see the point. I would contact cairo debian maintainers about that. To have their point of view.
On 01/21/2011 08:04 PM, Seblu wrote:
On Mon, Jan 17, 2011 at 10:04 AM, Ronald van Harenpressh@gmail.com wrote: I see the point. I would contact cairo debian maintainers about that. To have their point of view.
that means that you don't trust the arch maintainer judgment?
https://bugzilla.redhat.com/show_bug.cgi?id=465759#c23
On Fri, Jan 21, 2011 at 7:12 PM, Ionuț Bîru biru.ionut@gmail.com wrote:
On 01/21/2011 08:04 PM, Seblu wrote:
On Mon, Jan 17, 2011 at 10:04 AM, Ronald van Harenpressh@gmail.com wrote: I see the point. I would contact cairo debian maintainers about that. To have their point of view.
that means that you don't trust the arch maintainer judgment?
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
I speak about this link previouly. But this bug does not inspire me confidence. It is mainly based on the fact "Upstream is not unmaintained". And this is not obvious.
Debian include awesome 3.4 in their distro. It does not seem to be stupid to understand this choice! As well as to understand why redhat do not.
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU? As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR. In the past theres been many patched beyond recongnition packages in community eg. many packages with lcd patches from ubuntu, urxvt with 256 colour support and many other patches included etc. AFAIK the reason awesome was removed from community was that JGC removed the cairo backend from the package in extra AND the awesome maintainer didnt want to maintain a cairo-xcb package himself. If he did awesome would still be in community...
Greg
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
If you are just going to ignore and say, screw Jan decisions, I'm going to upload it just because I can, you are not welcomed in the team.
In the past theres been many patched beyond recongnition packages in community eg. many packages with lcd patches from ubuntu, urxvt with 256 colour support and many other patches included etc.
Do a list with the current packages that doesn't follow the arch way and i will take care of them.
AFAIK the reason awesome was removed from community was that JGC removed the cairo backend from the package in extra AND the awesome maintainer didnt want to maintain a cairo-xcb package himself. If he did awesome would still be in community...
He respected the decision and trusted Jan because we are a team and we have to work together to accomplish a goal.
Ionut wrote:
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
Ah OK.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
Nice to know that :)
-- Ionuț
On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
I think if the package meets the guidelines then you shouldn't bully someone into not maintaining it. As long as he's providing the support that should suffice. Sometimes we may need to adjust the guidelines, and we decide this as a group through a formal vote.
If you are just going to ignore and say, screw Jan decisions, I'm going to upload it just because I can, you are not welcomed in the team.
The TUs are a separate group in the Arch community who can make different decisions on what or what not to maintain.
In the past theres been many patched beyond recongnition packages in community eg. many packages with lcd patches from ubuntu, urxvt with 256 colour support and many other patches included etc.
Do a list with the current packages that doesn't follow the arch way and i will take care of them.
AFAIK the reason awesome was removed from community was that JGC removed the cairo backend from the package in extra AND the awesome maintainer didnt want to maintain a cairo-xcb package himself. If he did awesome would still be in community...
He respected the decision and trusted Jan because we are a team and we have to work together to accomplish a goal.
I would encourage him to not be bullied out of maintaining things that he would like to maintain in community. As long as they are not really creating more work for anyone than himself, they should be fine.
On Sat, Jan 22, 2011 at 12:13 PM, Loui Chang louipc.ist@gmail.com wrote:
On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
I think if the package meets the guidelines then you shouldn't bully someone into not maintaining it. As long as he's providing the support that should suffice. Sometimes we may need to adjust the guidelines, and we decide this as a group through a formal vote.
Seriously? Since when is adding a package that is already in the repos with a different configure flag a good idea? We don't even allow this in the AUR...
Ronald
On Sat 22 Jan 2011 19:03 +0100, Ronald van Haren wrote:
On Sat, Jan 22, 2011 at 12:13 PM, Loui Chang louipc.ist@gmail.com wrote:
On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
I think if the package meets the guidelines then you shouldn't bully someone into not maintaining it. As long as he's providing the support that should suffice. Sometimes we may need to adjust the guidelines, and we decide this as a group through a formal vote.
Seriously? Since when is adding a package that is already in the repos with a different configure flag a good idea? We don't even allow this in the AUR...
Seriously. While it's not ideal, it has been done. I would consider it the same as including bin/lib32 packages just to include things like wine or whatever. The [community] repo is intended for this kind of experimentation and freedom.
I think awesomewm has enough of a user base to justify such measures if a TU is willing to maintain it.
I'm starting to get a bit peeved with people confusing [community] and [unsupported] with the [core] and [extra] bits.
that means that you don't trust the arch maintainer judgment?
/snip
But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
+1
Everyone can make mistakes, even Arch packagers. Ffs, Allan's a core dev :P More shocking news at 11.
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
Who's "us"?
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
I think if the package meets the guidelines then you shouldn't bully someone into not maintaining it. As long as he's providing the support that should suffice. Sometimes we may need to adjust the guidelines, and we decide this as a group through a formal vote.
+1 for discussion and voting, -1 for "because I said so, noob".
Seriously? Since when is adding a package that is already in the repos with a different configure flag a good idea? We don't even allow this in the AUR...
I think there's been a misunderstanding. The package would have a different name via the suffix to indicate the option, which is permissible in both [community] and the AUR.
Seriously. While it's not ideal, it has been done. I would consider it the same as including bin/lib32 packages just to include things like wine or whatever. The [community] repo is intended for this kind of experimentation and freedom.
I think awesomewm has enough of a user base to justify such measures if a TU is willing to maintain it.
I mostly agree.
The Arch ideal is to include the most vanilla package possible and let users compile their own custom packages if they need or want them, but if there is a considerable demand for non-vanilla build options then I see no reason not to either change the "vanilla" package or include a clearly labelled alternative package. As already stated, this has been done before and it isn't a big deal at all.
I'm starting to get a bit peeved with people confusing [community] and [unsupported] with the [core] and [extra] bits.
Well, now that [community] is official, the line between it and [extra] is slowly being blurred, maybe even erased, so there's not much reason to be peeved about the confusion.
I really don't see much difference in the types of packages included in either. I suspect that some devs treat [extra] as though it were [community] and that there is no strict policy in place to determine what belongs there and what belongs in [community].
On 01/22/2011 08:35 PM, Loui Chang wrote:
On Sat 22 Jan 2011 19:03 +0100, Ronald van Haren wrote:
On Sat, Jan 22, 2011 at 12:13 PM, Loui Changlouipc.ist@gmail.com wrote:
On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
Seblu wrote:
It looks like a trick question! But if I want to be a good maintainer, I do understand the reasons.
and **The trust does not exclude the audit.**
Excuse me for asking but is there anything preventing you from moving cairo-xcb to community if you become a TU?
Yes, us.
As far as i know if you become a TU you can maintain anything you want that has more than 10 votes in the AUR.
Becoming a TU means that you become a member in the developement team, a team in which we trust each other, respect each other decisions, use the same packaging standards, the same tools as developers etc.
I think if the package meets the guidelines then you shouldn't bully someone into not maintaining it. As long as he's providing the support that should suffice. Sometimes we may need to adjust the guidelines, and we decide this as a group through a formal vote.
Seriously? Since when is adding a package that is already in the repos with a different configure flag a good idea? We don't even allow this in the AUR...
Seriously. While it's not ideal, it has been done. I would consider it the same as including bin/lib32 packages just to include things like wine or whatever. The [community] repo is intended for this kind of experimentation and freedom.
I think awesomewm has enough of a user base to justify such measures if a TU is willing to maintain it.
While are you at this add firefox/thunderbird cairo system support. It has enough user base and a lot of complains about fonts that are not consistent with system, doesn't matter if firefox/tb is broken.
We can do this </sarcasm>
I'm starting to get a bit peeved with people confusing [community] and [unsupported] with the [core] and [extra] bits.
On Sun 23 Jan 2011 11:53 +0200, Ionuț Bîru wrote:
On 01/22/2011 08:35 PM, Loui Chang wrote:
On Sat 22 Jan 2011 19:03 +0100, Ronald van Haren wrote:
Seriously? Since when is adding a package that is already in the repos with a different configure flag a good idea? We don't even allow this in the AUR...
Seriously. While it's not ideal, it has been done. I would consider it the same as including bin/lib32 packages just to include things like wine or whatever. The [community] repo is intended for this kind of experimentation and freedom.
I think awesomewm has enough of a user base to justify such measures if a TU is willing to maintain it.
While are you at this add firefox/thunderbird cairo system support. It has enough user base and a lot of complains about fonts that are not consistent with system, doesn't matter if firefox/tb is broken.
We can do this </sarcasm>
Sure, why not? This doesn't compare with awesome though, which doesn't exist in the repos, and actually requires cairo-xcb. Firefox is available in the repos and your font issues can likely be worked around. At least I have no problems with fonts there.
I'm starting to get a bit peeved with people confusing [community] and [unsupported] with the [core] and [extra] bits.
aur-general@lists.archlinux.org