Splitting this from #1887796-4: Make rcross a co-maintainer for update_advanced...

@hass: I've seen a lot of your patches and I know you're a careful coder, although we've certainly disagreed on many things over the years. ;) I'm a little reluctant to add you as a co-maintainer since I don't want to get in fights about the direction of this module with you. But, I also don't want to hold a grudge, nor stifle initiative and interest. I just want to make sure that there's a healthy and supportive atmosphere among the co-maintainers. That's my concern. What do you think? What would your plans for this module be if you became a co-maintainer?

Thanks,
-Derek

Comments

hass’s picture

hass CreditAttribution: hass commented

Well... maybe true. But I definitively have no intention to change any directions nor do I have time for this. If you have any directions, please share them and I try not breaking them intentionally :-). I have a need to use the module in some projects for not spamming customers with update notifications. I have seen it works well except one bug that I'd like to fix. My main intention here was only to do minimal maintenance for now as it just works as it should and I see no reasons to change the module in any unknown direction.

The main to do's I planed, doing a review of all translatable strings, review the queue and get outstanding bugs issues nailed out, fix all possible coder issues if there are any and make a release to follow up with the German translation. As you may know, without a release the strings do not appear on l.d.o. That's where I mainly came from, too. :-). That's all.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Postponed (maintainer needs more info) » Fixed

Sounds good, thanks. ;) My only plans for this module are keep it as small and simple as possible.

I just gave you "write to VCS", "maintain issues", and "edit project" permissions for this project. I didn't yet grant "administer releases" since I'd like to at least check-in again before you start creating releases. #1779280: Create D7 release of Update status advanced settings would be a good place for that. If you get a chance, please update the issue summary there with any issues you're planning to fix before a 7.x-1.0 release. Also, I wouldn't mind if we did at least one beta1 before we jump straight to 1.0 (although it might not matter since the module is so small).

Probably goes without saying, but:

  • please be careful
  • always reference an issue number in the commit (unless it's just a trivial code-style fix)
  • don't fix/change different issues in the same commit -- keep them small and self-contained so they're easier to review and understand (and roll-back if necessary)
  • use proper attribution for giving credit during Git commits (I'm a fan of using --author where appropriate, instead of just "[#xxx] by yyy: whatever")

Thanks!
-Derek

hass’s picture

hass CreditAttribution: hass commented

THX, however the missing administer releases permission really blocks me from doing what I mainly planned to do on the end of the day...

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Understood. I'm just saying I want to check-in first. Once you (and/or rcross) make any more progress towards the release, we can reassess. This release has waited a couple years. 1 more day isn't going to hurt. ;)

Cheers,
-Derek

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Thanks for the flurry of activity!

However, you never got the memo that starting a Git commit with # is a bad idea? If anyone ever tries an interactive rebase for any reason, all the commits will be lost since that first character means comment. The official convention is to use:

Issue #xxx by yyy: zzz

Although I prefer:

[#xxx] by yyy: zzz

Oh well. We can't fix it now since you've already pushed these broken commits and we can't change them without changing the hashes which would be a non-fast-foward push (which d.o disallows for all sorts of good reasons).

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

p.s. See Commit messages - providing history and credit for more, especially the part in bold starting with "Important:" ;)

hass’s picture

hass CreditAttribution: hass commented

Uhhh. I was not aware of this small details and Git bug. I just cared about the link automatically created to the case. I'm the auhor therefore the "by" looked useless to me and I left it out. Thanks for noting this as I'm doing this "wrong" since Git migration. Is it possible to refuse a commit on server side if there is a hash starting if Git has a problem with this? However bold you are writing these docs... I'm not searching for this as was not aware of this.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Is it possible to refuse a commit on server side if there is a hash starting if Git has a problem with this?

I believe it's possible, yes, but not a great idea for reasons I don't want to get into (and this isn't the place to discuss it). Pretty sure there have already been numerous issues about this, so you could search if you're really interested (I don't have time to find them for you).

I know, people don't read the docs. I didn't write them in this case, just pointing them out to you. :)

These "broken" commits are not the end of the world. Mistakes happen.

Cheers,
-Derek

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hass’s picture

hass CreditAttribution: hass commented
Status: Closed (fixed) » Active

We still have no release yet. Can you grant me the full permissions, please?

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Active » Closed (fixed)

I replied at the issue about the 7.x-1.0 release. That kind of base-line testing is the stuff I think we need to do before a release, so for now, I'm going to keep being a single point of failure (for better or worse -- probably worse, but such is life). ;)

Thanks,
-Derek