[gentoo-dev] Changes in libreoffice ebuild

[gentoo-dev] Changes in libreoffice ebuild

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1488 bytes --]

Re: [gentoo-dev] Changes in libreoffice ebuild

[Alexandre Rostovtsev]

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

[Alexis Ballier]

On Tue, 13 Aug 2013 11:00:57 -0400
Alexandre Rostovtsev <tetromino@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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Changes in libreoffice ebuild

[Rich Freeman]

On Tue, Aug 13, 2013 at 12:03 PM, "Paweł Hajdan, Jr."
<phajdan.jr@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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

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/>

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Changes in libreoffice ebuild

[Chí-Thanh Christopher Nguyễn]

-----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-----

[gentoo-dev] Re: Changes in libreoffice ebuild

[Patrick Lauer]

On 08/13/2013 04:10 PM, 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.

I left the bug open so it doesn't get forgotten. It'll not take you more
time to handle that bug ...

> 
> 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.

I have no interest in spending some hours to figure out an arcane
interface that doesn't work by default. Since you already know how it
works it's a more efficient use of your two minutes than wasting hours
listening to my frustrated ranting

> 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.

Then don't leave such simple bugs open for a long time. It was broken,
now it builds again: User experience has been improved.

Your work for further triaging this bug has not been affected.

Everyone profits.

Re: [gentoo-dev] Changes in libreoffice ebuild

[Luca Barbato]

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

[Peter Stuge]

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

[Luca Barbato]

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 patches@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 patches@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