Re: mc and me

[Egmont Koblinger]

On Sun, Nov 8, 2015 at 10:29 PM, Yury V. Zaytsev  wrote:

> Sure, I can try to find time to help... Are you on IRC?

Nope.  I can join if I know there's something particular going on that
I know about in advance and happen to be available at that time, but
generally I prefer offline discussions (bugtracker, mailing list).

Thanks for the links!  It's new to me that I can edit the wiki page, I
guess you guys just recently granted me permissions.

I'll let you know if I get stuck somewhere.


thanks,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Yury V. Zaytsev]

On Fri, 2015-11-06 at 19:43 +0100, Egmont Koblinger wrote:

> For minor changes, such as a followup bugfix in the viewer (e.g. 3531)
> I wouldn't want to wait for more than a couple of days; let's say a
> week at most.  Does this sound okay?

A week would be fine with me for minor changes, and I trust your
judgment on what's minor enough... sadly, I can't keep track of changes
on this timescale, but hopefully Andrew will keep an eye and yell if
something goes very very wrong.

You probably already know this, but there is a helpful report page on
Trac which among other things can show tickets waiting for a review...
you can use that to check for tickets that need feedback.

As far as I can see, you've accepted the GitHub invitation, so you
should have access to the repository by now, and you've got Trac admin
privileges as well, so that you can ravage the tickets and the wiki.

Let me know if there is anything else I can do for you. I'll be checking
the mailing lists from time to time, but one way to catch my attention
in the case of emergency is to put me explicitly on CC.

-- 
Sincerely yours,
Yury V. Zaytsev


___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

Hi,

My git knowledge is pretty accurately described by
http://xkcd.com/1597/ , so the first time I'll do that branching and
merging (esp. the latter) it'd be great if someone double checked on
me.

Also: What are the steps to be performed before/after a commit?  I
mean, run the unittests (make tests -- that's it?), check if the code
is formatted (make indent -- correct?), update the NEWS file (how?),
anything else?


thanks,
egmont


On Sun, Nov 8, 2015 at 9:49 PM, Yury V. Zaytsev  wrote:
> On Fri, 2015-11-06 at 19:43 +0100, Egmont Koblinger wrote:
>
>> For minor changes, such as a followup bugfix in the viewer (e.g. 3531)
>> I wouldn't want to wait for more than a couple of days; let's say a
>> week at most.  Does this sound okay?
>
> A week would be fine with me for minor changes, and I trust your
> judgment on what's minor enough... sadly, I can't keep track of changes
> on this timescale, but hopefully Andrew will keep an eye and yell if
> something goes very very wrong.
>
> You probably already know this, but there is a helpful report page on
> Trac which among other things can show tickets waiting for a review...
> you can use that to check for tickets that need feedback.
>
> As far as I can see, you've accepted the GitHub invitation, so you
> should have access to the repository by now, and you've got Trac admin
> privileges as well, so that you can ravage the tickets and the wiki.
>
> Let me know if there is anything else I can do for you. I'll be checking
> the mailing lists from time to time, but one way to catch my attention
> in the case of emergency is to put me explicitly on CC.
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

On Sun, Nov 8, 2015 at 10:43 PM, Yury V. Zaytsev  wrote:

> Sure, I also prefer pull to push, but I find realtime to be much more
> efficient when it comes to stuff like "can you hand-hold me while I'm
> merging a branch for the first time".

Sure, let's do so at one point.

Thanks,
e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Yury V. Zaytsev]

On Sun, 2015-11-08 at 22:14 +0100, Egmont Koblinger wrote:
> 
> My git knowledge is pretty accurately described by
> http://xkcd.com/1597/ , so the first time I'll do that branching and
> merging (esp. the latter) it'd be great if someone double checked on
> me.

Sure, I can try to find time to help... Are you on IRC? Otherwise, I've
just revealed a magic trick to attract my attention by email.

Some info is available from here:

http://www.midnight-commander.org/wiki/GitGuideLines

http://www.midnight-commander.org/wiki/WorkingGuideLines

http://www.midnight-commander.org/wiki/Hacking

> Also: What are the steps to be performed before/after a commit?

You pretty much summed it up :-) Commit everything is a nice patch
series to a topic branch, check tests & indentation, create tentative
NEWS entry and push for review...

> I mean, run the unittests (make tests -- that's it?),

Yes, that's always a good idea.

> check if the code is formatted (make indent -- correct?), 

Yes; in addition, Travis is supposed to do it when you push your feature
branch, and inform by email if there is a problem.

> update the NEWS file (how?), anything else?

When the ticket it closed, it should be added to the news page:

http://www.midnight-commander.org/wiki/NEWS-4.8.16

>From there, it makes it into the release NEWS; see the old one here:

http://www.midnight-commander.org/wiki/NEWS-4.8.15

-- 
Sincerely yours,
Yury V. Zaytsev


___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Slava Zanko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Yury,

> I'm all for granting Egmont commit access.

+1 from me.

- --
*From:* Yury V. Zaytsev
*To:* Egmont Koblinger, Slava Zanko, Andrew Borodin
*Cc:* Mc Devel
*Subject:* Re: mc and me
*Sent:* 06.11.2015 11:12:23



05.11.2015 23:55, Yury V. Zaytsev пишет:
> On Wed, 2015-11-04 at 22:09 +0100, Egmont Koblinger wrote:
>> 
>> Hereby I'm requesting to become a member of the team, with git
>> access, getting to know the development process, policies (e.g.
>> which changes require approval, when to git branch, etc.), and
>> requesting to get faster responses to my patches that require
>> review – or to be able to submit them if I don't get response in
>> a certain amount of time.  (We can still revert a change later if
>> someone disagrees.)
> 
> Hi,
> 
> Just briefly: I'm all for granting Egmont commit access. Slava,
> Andrew?
> 
> He's proven his engineering and communication skills through
> numerous extensive and technically challenging contributions, and
> I'm confident that even if he happens to break something in the
> future, he'll get back to it, find the root of the problem and fix
> it.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlY8YQYACgkQb3oGR6aVLpqmvQCfTbuvmlWGiJmxn7KDXZ6kkbj8
C1oAn1O5mPju68JGMKbXwoe3Q9fE5icr
=NPj2
-END PGP SIGNATURE-
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Andrew Borodin]

On Fri, 6 Nov 2015 11:12:55 +0300 Slava Zanko wrote:
> > I'm all for granting Egmont commit access.
> 
> +1 from me.

Me too.

-- 
Andrew
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Egmont Koblinger]

Thanks to all of you guys!

On Thu, Nov 5, 2015 at 10:13 PM, Yury V. Zaytsev  wrote:

> How about doing it the other way around from now on? You put the branch
> on review, and if there is no vote coming, and no one vehemently objects
> on technically substantiated grounds, it can go into master after 4
> weeks, or I can rubber-stamp it if you want to keep the formalities :-)

Could we make it more flexible based on the weight of the change?
E.g. for an mcview rewrite 4 weeks is totally reasonable.  For
user-visible changes such as dimming wrapped lines (3546) it's also
okay for me to wait that long for input, to give you time to speak up
against it or come up with alternative approaches.

For minor changes, such as a followup bugfix in the viewer (e.g. 3531)
I wouldn't want to wait for more than a couple of days; let's say a
week at most.  Does this sound okay?

> The obligations anyone here has are at best the "moral" ones. There is
> no signing of contracts involved in getting commit access. Only I'd
> expect you not wiping the repository after a tequila party, feeling
> responsible for fixing stuff you happened to break, being careful with
> the private keys if you need/want access to more infra, etc. and in
> general keep the pills handy. I don't think this would be a problem,
> would it?

This is of course obvious.  (I didn't sign anything for gnome-terminal
either, at least I can't remember... I might have had to click once on
some legal stuff, but definitely nothing more than that.)


Thanks a lot,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Yury V. Zaytsev]

On Wed, 2015-11-04 at 22:09 +0100, Egmont Koblinger wrote:

> getting to know the development process, policies (e.g. which changes
> require approval, when to git branch, etc.), and 

Well, basically it's all about having a ticket & a topic branch per
feature / non-documentation bugfix, where ticket number and summary are
in the commit message along with a short description and a sign-off, and
doing a --no-ff merge when it's finished (i.e. rebase first to keep the
history nice and clean), see git log. Changes to the documentation,
maintainer scripts, translations, etc. can go directly into master.

There is more legalese on the trac at various stages of bitrot, but
that's basically all that matters to me, I think. Does this sound
reasonable to you?

> requesting to get faster responses to my patches that require review –
> or to be able to submit them if I don't get response in a certain
> amount of time.

Here comes the tricky part; the first rule was that the branch gets
merged as soon as it gets 3 votes from the maintainers other than the
main author, then it was quickly changed to 2 votes, and then eventually
degraded into 1 vote, and then... then you know what happened.

How about doing it the other way around from now on? You put the branch
on review, and if there is no vote coming, and no one vehemently objects
on technically substantiated grounds, it can go into master after 4
weeks, or I can rubber-stamp it if you want to keep the formalities :-) 

Does this sound reasonable?

> keep doing what I did so far and do even more, but without
> obligations.

The obligations anyone here has are at best the "moral" ones. There is
no signing of contracts involved in getting commit access. Only I'd
expect you not wiping the repository after a tequila party, feeling
responsible for fixing stuff you happened to break, being careful with
the private keys if you need/want access to more infra, etc. and in
general keep the pills handy. I don't think this would be a problem,
would it?

-- 
Sincerely yours,
Yury V. Zaytsev


___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

mc and me

[Egmont Koblinger]

Hi guys,

I've been thinking about writing something like this for quite a long time...

Some of you might know that I like contributing to various open source
projects as a hobby.  Some of you might know what my top hobby project
is.  mc is the second in the line.

Recently I've devoted a much bigger portion of my hobby time to that
other project (gnome-terminal/vte), probably mostly because I'm
welcome there.  I have git access (I didn't request, they recommended
it to me), I can submit the trivial changes straight away, while I
still ask the main developer's opinion on bigger ones.  Sometimes we
disagree, I try to convince him, but if I fail, it's his choice.
Sometimes he reverts a patch that he disagrees with.  Despite these,
contributing there is fun.

We've talked a lot about the development process not being anywhere
near as smooth as it should be.  On one hand there's noone to blame:
it's just a bunch of guys all spending their free time on the project.
On the other hand: I think it would be the responsibility of the
current developers to allow others to contribute more easily, and step
out of the way if they're the bottleneck.

I think I have contributed quite some useful features and generally
good quality code, and hope that I could build up certain reputation
and trust in the team.  Some guys here have already recommended that I
get git access, although I never asked.

The time has come.  The current way of so slowly getting feedback or
acceptance on my contributions is not going to work anymore.  I'm
tired of this, really tired.  I'm happy to contribute as long as it's
fun.  Probably #3534 comment 18 was the last straw (a one-character
change probably not making it into the next release).  No, I didn't
get offended, I didn't take it personally.  It could have been the
lack of feedback on any other ticket, there's been so many recently.

I just realized it doesn't work.  I realized it's no longer fun.

The question is: backwards, or forwards?

Hereby I'm requesting to become a member of the team, with git access,
getting to know the development process, policies (e.g. which changes
require approval, when to git branch, etc.), and requesting to get
faster responses to my patches that require review – or to be able to
submit them if I don't get response in a certain amount of time.  (We
can still revert a change later if someone disagrees.)

I'm sorry, but next to a full-time job, another hobby coding project,
and some weird thing called life, I'd like to make it clear that I
can't take on any responsibility.  I'm happy to help and improve mc
whenever/wherever I feel like, keep doing what I did so far and do
even more, but without obligations.  Can you guys make it easier for
me?  Do you trust me enough?

If so, let's move forward!

If not, I'll replace mc by another hobby where I have much more fun.

Thanks a lot,
egmont
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc and me

[Mooffie]

On 11/4/15, Egmont Koblinger  wrote:
> Hi guys,
>
> I've been thinking about writing something like this for quite a long
> time...

Egmont, I feel for you!

(I hope these are suitable words. I'm not an English speaker. At this
moment I'm hungry and tired so I'm giving up revising that sentence
;-)

It'd pain me greatly to see you go or no longer contributing. I'm
relatively new here and you (and Yury, and Andrew) are the only one(s)
I've seen showing care/love towards MC. So, in a very straightforward
way, you're very precious to me - and to every user of MC. Not from a
utilitarian point of view but also from that of being a kin - bonded
by love for MC. Though I don't think we're a crowd that differentiates
between "love" and "utility" when it come to our hobby software! ;-)

> Probably #3534 comment 18 was the last straw (a one-character
> change probably not making it into the next release).

I'm sorry that I chimed in there. I thought I could help expedite
matters by providing "review" to help bring the issue to conclusion,
but, alas, my "contribution" there added needless volume and probably
did the opposite.

On the up side, every comment of yours there attest to your
thoroughness. Not that I needed more evidence for that. One needs to
read only few of your tickets to understand that the community can
entrust you with responsibility.

>
> The question is: backwards, or forwards?

So indeed, Yury, why not forward?

The sun is shining, the birds are chirping, the coffee is a brewing,
and a cheery letter from Egmont is waiting; what can be better than
that?
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel