Ticket #3752 (closed task: fixed)

Opened 7 months ago

Last modified 6 months ago

extfs: tester: export some more useful variables.

Reported by: mooffie Owned by: mooffie
Priority: major Milestone: 4.8.19
Component: mc-vfs Version: master
Keywords: Cc:
Blocked By: Blocking: #3753
Branch state: merged Votes for changeset: committed-master

Description

The tester currently exports, and documents, only MC_TEST_EXTFS_LIST_CMD.

But as the rpm test proves, two additional variables are needed for tests:

  • MC_TEST_EXTFS_DATA_DIR - path to the data dir.
  • MC_TEST_EXTFS_INPUT - path to the input file.

This series of patches make this happen.

(Tests can actually already access these values but only by accessing private variables of the test_all script ($DATA_DIR and $INPUT), something we want to discourage.)

Change History

comment:1 Changed 7 months ago by mooffie

  • Blocking 3753 added

comment:2 follow-up: ↓ 5 Changed 7 months ago by mooffie

  • Owner set to mooffie
  • Status changed from new to accepted
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.19

branch: 3752_extfs_tester_export_more_variables
Initial changeset:9f99838fbe0ab3579ea13069d89115ffa0a7571b

Last edited 7 months ago by andrew_b (previous) (diff)

comment:3 Changed 7 months ago by mooffie

A question:
The commit-id I need to write after "changeset:" is supposed to be that of the earliest commit ("base") in the branch, or that of the latest ("tip")?

comment:4 Changed 7 months ago by zaytsev-work

The earliest; the idea behind this rule was that it lets you easily browse commits using Trac repository browser interface to perform reviews, as Trac recognises commit hashes, but not the branch names.

This was very important before we moved the canonical repository to GitHub (which was publicly launched and started getting traction just a few months before the last "bloody revolution" when we took over the project). Now I still find it useful, but I think it's a bit annoying to do every time. I was thinking of writing a maintainer script to do it, but never got to it, and Andrew has the will of steel & never makes mistakes, so I guess he didn't even consider this option.

If you want, I can try to install https://trac-hacks.org/wiki/XmlRpcPlugin on the server so that it would be easier to automate as compared to just sending normal HTTP request using requests library (which should be trivial enough though).

comment:5 in reply to: ↑ 2 Changed 7 months ago by andrew_b

Replying to mooffie:

branch: 3752_extfs_tester_export_more_variables
Initial changeset:9f99838fbe0ab3579ea13069d89115ffa0a7571b

There is no need to put Ticket #XXXX in each commit. This should be in the first commit of branch only.

comment:6 Changed 6 months ago by mooffie

(My new questions are in bold.)

Replying to andrew_b:

There is no need to put Ticket #XXXX in each commit. This should be in the first commit of branch only.


Ok (I'll fix this before I merge to master).

Note that the title of a 1st commit in a branch is often very different than the ticket's title. You see this here and in #3751. So we'll have "Ticket #XYZ: some-title-seemingly-not-related-to-the-ticket". Are you fine with this?

Replying to zaytsev-work:

The earliest;


Ah. I now see that you two write "Initial changeset" instead of "changset" when there's more than 1 commit.

a bit annoying to do every time. I was thinking of writing a maintainer script to do it, but never got to it [...] If you want, I can try to install https://trac-hacks.org/wiki/XmlRpcPlugin


(If you ever find the time I'd appreciate it: I may find other good uses for this plugin. Whatever, I hope to study Trac and help you to maintain it.)

So:

We're waiting for either one of you to add his name to "Votes for changeset", right?

comment:7 Changed 6 months ago by zaytsev

(If you ever find the time I'd appreciate it: I may find other good uses for this plugin. Whatever, I hope to study Trac and help you to maintain it.)

Done; FYI, I've restricted the usage of RPC via SSL only.

In as far as good use and maintenance is concerned, I'm not sure if the effort is worth it; I just thought if you'll want to write short Python / Ruby / whatever scripts to automate annoying stuff, it will make it easier for you. I have said many times that contrary to the popular belief, I don't see Trac as an ultimate ideal platform for the project, it's just that it fits the bill right now, and the maintenance requirements are reasonable.

If something clearly so much better comes up, and someone steps up to make a high quality conversion, then why not. After all, we moved to GitHub after maintaining our own git hosting for years, after GitHub became clearly superior. Only right now, the issue tracking system they have is still garbage in my and Andrews opinion...

What's really good at GitHub right now I think is the wiki and GitHub pages functionality, and the documentation from Trac wiki should definitively be moved to Markdown, or ReST, or what not and hosted in a git repository, such that a nice website like doc.m-c.o can be generated out of it. Only it seems that nobody cares about the documentation anyways, so maybe this is also effort not well spent :-/

comment:8 Changed 6 months ago by zaytsev

Note that the title of a 1st commit in a branch is often very different than the ticket's title. Are you fine with this?

You have a valid point, but I'm personally fine with it and so I think is Andrew. The idea behind this "Ticket #XXX: ..." reference is that you can later easily find the reason why stuff was committed, along with the reviews / design discussions, etc. For individual commits what follows after "Ticket #XXX: ..." usually matches the title, for first commits in the feature branch, unfortunately, not. However, I think it's good enough and prefixing every commit in feature branches if you do --no-ff merges anyways adds too much noise. In some projects they have a rule for referring to the issue at the end of the sentence in parens (like "Do X and Y (INFRA-123)"), but the old style stuck and we saw no reason to change something we're used to.

comment:9 follow-up: ↓ 11 Changed 6 months ago by zaytsev

  • Votes for changeset set to zaytsev
  • Branch state changed from on review to approved

We're waiting for either one of you to add his name to "Votes for changeset", right?

Yes.

comment:10 Changed 6 months ago by mooffie

  • Status changed from accepted to testing
  • Votes for changeset changed from zaytsev to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

comment:11 in reply to: ↑ 9 Changed 6 months ago by mooffie

Replying to zaytsev:

(If you ever find the time I'd appreciate it: I may find other good uses for this plugin.

Done; FYI, I've restricted the usage of RPC via SSL only.


Thanks!

In as far as good use and maintenance is concerned, I'm not sure if the effort is worth it; [...] I have said many times that contrary to the popular belief, I don't see Trac as an ultimate ideal platform for the project, it's just that it fits the bill right now, and the maintenance requirements are reasonable.


Got it.

We're waiting for either one of you to add his name to "Votes for changeset", right?

Yes.


Yeeeeeha! :-)

comment:12 Changed 6 months ago by mooffie

  • Status changed from testing to closed

comment:13 follow-up: ↓ 14 Changed 6 months ago by zaytsev

Don't forget about NEWS-4.8.19, i.e. you can add this ticket to the following group:

comment:14 in reply to: ↑ 13 Changed 6 months ago by mooffie

Replying to zaytsev:

Don't forget about NEWS-4.8.19


Yes, updated.

comment:15 Changed 6 months ago by andrew_b

And don't forget to remove merged branches.

Note: See TracTickets for help on using tickets.