Re: [gentoo-dev] Changes in libreoffice ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz schrieb: On 14:37 Tue 13 Aug , Rich Freeman wrote: If a maintainer is holding something up for months by all means escalate it if you think it is justified, but if a maintainer just wants a few days to look into things, that isn't asking too much. If this were a security patch I might feel differently, or a stable regression (though as has been pointed out that shouldn't happen with reverse dep testing). Turns out we already wrote this down. See Touching other developers ebuilds: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself. This is only if the maintainer does not respond. In this case the maintainer made it clear that he didn't want those patches before they were submitted (not necessarily accepted) upstream. Best regards, Chí-Thanh Christopher Nguyễn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlILXMIACgkQ+gvH2voEPRDVGACeIHPGBf0/HZthRw8q5ID1VV/r Ga8An1NUeyG1MjfNfuMLLTF+5x8S7zzJ =/ud4 -END PGP SIGNATURE-
Re: [gentoo-dev] Changes in libreoffice ebuild
On 13/08/13 10:10, Tomáš Chvátal wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list or provide some sane alias to cope with it's specific ways... lu
Re: [gentoo-dev] Changes in libreoffice ebuild
Luca Barbato wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list Usually Gerrit just needs an OpenID in order to accept git push via SSH. That seems significantly better to me than parsing emails. //Peter
Re: [gentoo-dev] Changes in libreoffice ebuild
On 14/08/13 17:56, Peter Stuge wrote: Luca Barbato wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list Usually Gerrit just needs an OpenID in order to accept git push via SSH. That seems significantly better to me than parsing emails. # git-way: git commit ... git send-email -10 --compose --to patc...@project.org # gerrit-way: Register with gerrit Install the magic gerrit commit hooks OR Figure out how you should push your try ## Then we have feedbacks and we want to provide updates # git-way: Read the email comments git rebase -i git send-email -8 --compose --in-reply-to --to patc...@project.org # gerrit-way Follow the links to the website with the comments. Read the documentation again since you will forget how to push stuff in gerrit, hope the commit hook you have manages the rebase and push again. --- Gerrit probably can be nice if you are used to it, you always have a browser open and you do not have a wast mean to move from your mail client to your git (people with emacs would explain better, I use vim and thunderbird and yet I'm quicker in addressing projects using the git email approach than those that use gerrit. lu
[gentoo-dev] Changes in libreoffice ebuild
As per my comment in bugzilla [1] I said that the patch should be submitted upstream prior having it in cvs. Yet you decided to completely ignore my statement and just smash in the patch anyway [2]. Please don't do this ever again. We had shitload of distro patches before and it is hell to strip away later on. For your statement of lacking documentation, when I google gerrit libreoffice first two links lead directly to the instance and 3rd to wiki [3], which no suprise is guide how to set it up and submit request, so stop lying. As you like to ignore maintainer requests I now expect you to submit it to the gerit, since now you have the guide and you can proceed without an issue right? Note that I have nothing against other devs submitting fixes to ebuilds maintained by me, but directly ignoring what I said on a bug and doing whatever you see fit does not match that at all. Tomas [1] https://bugs.gentoo.org/show_bug.cgi?id=479604#16 [2] https://bugs.gentoo.org/show_bug.cgi?id=479604#19 [3] https://wiki.documentfoundation.org/Development/gerrit
Re: [gentoo-dev] Changes in libreoffice ebuild
On Tue, 2013-08-13 at 10:10 +0200, Tomáš Chvátal wrote: As per my comment in bugzilla [1] I said that the patch should be submitted upstream prior having it in cvs. Yet you decided to completely ignore my statement and just smash in the patch anyway [2]. Please don't do this ever again. We had shitload of distro patches before and it is hell to strip away later on. For your statement of lacking documentation, when I google gerrit libreoffice first two links lead directly to the instance and 3rd to wiki [3], which no suprise is guide how to set it up and submit request, so stop lying. As you like to ignore maintainer requests I now expect you to submit it to the gerit, since now you have the guide and you can proceed without an issue right? Note that I have nothing against other devs submitting fixes to ebuilds maintained by me, but directly ignoring what I said on a bug and doing whatever you see fit does not match that at all. Tomas [1] https://bugs.gentoo.org/show_bug.cgi?id=479604#16 [2] https://bugs.gentoo.org/show_bug.cgi?id=479604#19 [3] https://wiki.documentfoundation.org/Development/gerrit Tomáš, considering that libreoffice and libreoffice-bin were both broken on ~arch (so ~arch users did not have a compatible office suite to fall back on); the bug had 33 people in the CC list; a working patch was submitted, with a justification for why it is the correct solution, and was verified to work; and your response was (paraphrased) I will look at this later - I personally think that a small violation of openoffice team policies could in this particular case be forgiven. In addition, the policy itself is IMHO rather strange. If the goal is to ensure that any gentoo patch is visible to upstream developers and to libreoffice maintainers from other distros, so that they can merge it if they agree with the implementation, surely it would make no difference whether the patch got submitted to gerrit by Patrick before committing to gx86, or by you a week later? [1] On the other hand, if the goal is to avoid any divergence from upstream, presumably you want to first obtain feedback from upstream developers and an indication that they will merge the patch - in which case merely submitting something to gerrit, without waiting for upstream developer response, doesn't make sense. [1] on August 11, you had indicated that you would have time to look at the bug in ~10 days time.
Re: [gentoo-dev] Changes in libreoffice ebuild
On Tue, 13 Aug 2013 11:00:57 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Tomáš, considering that libreoffice and libreoffice-bin were both broken on ~arch (so ~arch users did not have a compatible office suite to fall back on); the bug had 33 people in the CC list; a working patch was submitted, with a justification for why it is the correct solution, and was verified to work; and your response was (paraphrased) I will look at this later - I personally think that a small violation of openoffice team policies could in this particular case be forgiven. In addition, the policy itself is IMHO rather strange. If the goal is to ensure that any gentoo patch is visible to upstream developers and to libreoffice maintainers from other distros, so that they can merge it if they agree with the implementation, surely it would make no difference whether the patch got submitted to gerrit by Patrick before committing to gx86, or by you a week later? [1] On the other hand, if the goal is to avoid any divergence from upstream, presumably you want to first obtain feedback from upstream developers and an indication that they will merge the patch - in which case merely submitting something to gerrit, without waiting for upstream developer response, doesn't make sense. [1] on August 11, you had indicated that you would have time to look at the bug in ~10 days time. Your arguments make sense but you should also consider it the other way: When you are maintaining a package properly by forwarding patches upstream, having $randomdev jumping in, adding a patch, and letting you clean up the mess is kind of annoying. Part of Tomas' original email was: I've googled it for you, now would you please submit that patch upstream and be forgiven? Alexis.
Re: [gentoo-dev] Changes in libreoffice ebuild
On 8/13/13 8:39 AM, Alexis Ballier wrote: Your arguments make sense but you should also consider it the other way: When you are maintaining a package properly by forwarding patches upstream, having $randomdev jumping in, adding a patch, and letting you clean up the mess is kind of annoying. Part of Tomas' original email was: I've googled it for you, now would you please submit that patch upstream and be forgiven? I agree with staying very close to upstream and submitting patches to them. This is especially important for big packages like libreoffice or say chromium (I help to maintain the latter). Note that there is a possible confusion what ~arch is about. Are breakages allowed there? How long before they get fixed? For example, one could arguably say neon-0.30.0 was added to the tree without testing reverse dependencies. Interestingly, it was submitted by Arfrever (just stating the fact). To his defense, he submitted the libreoffice patch to bugzilla on the same day. Still, one could ask: why wasn't neon-0.30.0 masked instead? One thing I think is really important is respecting the maintainers. If maintainer said please send the patch upstream before committing to cvs, it is _not_ OK to just ignore that. There are other options available like masking neon. And finally to the defense of libreoffice maintainers: packages take long time to compile, people have life. The policy about staying close to upstream is a very good one, and I can totally understand and agree with what they're saying. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes in libreoffice ebuild
On Tue, Aug 13, 2013 at 12:03 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: One thing I think is really important is respecting the maintainers. If maintainer said please send the patch upstream before committing to cvs, it is _not_ OK to just ignore that. There are other options available like masking neon. Also, users running ~arch should know to search bugzilla when they have problems, and there they would find the patch which they could apply. I think it is important to work with maintainers first and foremost. They're the ones with the long-term commitment. Sure, there can be exceptions for simple file additions like init scripts, but certainly random parties shouldn't be adding patches to ebuilds without maintainer agreement unless they're willing to step in and become a committed co-maintainer (with all the responsibilities that entails). If a maintainer is holding something up for months by all means escalate it if you think it is justified, but if a maintainer just wants a few days to look into things, that isn't asking too much. If this were a security patch I might feel differently, or a stable regression (though as has been pointed out that shouldn't happen with reverse dep testing). Rich
Re: [gentoo-dev] Changes in libreoffice ebuild
On 14:37 Tue 13 Aug , Rich Freeman wrote: If a maintainer is holding something up for months by all means escalate it if you think it is justified, but if a maintainer just wants a few days to look into things, that isn't asking too much. If this were a security patch I might feel differently, or a stable regression (though as has been pointed out that shouldn't happen with reverse dep testing). Turns out we already wrote this down. See Touching other developers ebuilds: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpFgfbAJDv3x.pgp Description: PGP signature
