Avro
  1. Avro
  2. AVRO-187

Move top-level source files into separate directories for easier maintenance

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3.0
    • Component/s: c
    • Labels:
      None

      Description

      This patch separates all top-level source into specific top-level directories (e.g. io, tests, datatypes) to make it easier to maintain.

      1. AVRO-187.patch
        762 kB
        Matt Massie

        Activity

        Hide
        Doug Cutting added a comment -

        Matt, I find it hard to read this patch. The best practice when restructuring the code tree is to:

        • attach a shell script that performs the required 'svn mv', 'svn rm', etc. commands.
        • use 'svn diff no-diff-deleted', and perhaps the '-notice-ancestry' option to make the patch more readable.
        Show
        Doug Cutting added a comment - Matt, I find it hard to read this patch. The best practice when restructuring the code tree is to: attach a shell script that performs the required 'svn mv', 'svn rm', etc. commands. use 'svn diff no-diff-deleted', and perhaps the ' -notice-ancestry' option to make the patch more readable.
        Hide
        Matt Massie added a comment -

        I'm make sure to do that for future patches. Thanks for the guidance, Doug.

        This patch only touches code in the 'src/c' directory. It just creates some directories in 'src/c' to help organize the code and updates the Makefile.am. No changes to the code itself except to update the paths for files.

        Show
        Matt Massie added a comment - I'm make sure to do that for future patches. Thanks for the guidance, Doug. This patch only touches code in the 'src/c' directory. It just creates some directories in 'src/c' to help organize the code and updates the Makefile.am. No changes to the code itself except to update the paths for files.
        Hide
        Doug Cutting added a comment -

        Can you please re-create the patch in a manner that's more readable? Otherwise there's not much point in posting it.

        Show
        Doug Cutting added a comment - Can you please re-create the patch in a manner that's more readable? Otherwise there's not much point in posting it.
        Hide
        Doug Cutting added a comment -

        Sorry, I didn't realize you'd already committed this. You have not resolved it yet. That should be done when you commit it.

        Show
        Doug Cutting added a comment - Sorry, I didn't realize you'd already committed this. You have not resolved it yet. That should be done when you commit it.
        Hide
        Doug Cutting added a comment -

        This is not a regression, so it shouldn't be flagged for potential inclusion in the 1.2.1 bugfix release (if we ever in fact make such a release). Also, since it's an "Improvement" it probably doesn't need an "Affects Version".

        Also, generally we only mark things as fixed in a single version, either the next upcoming release, or the release branch we intend to backport it to. We generally fix things in trunk, including adding a message to CHANGES.txt, then sometimes backport the patch to a release branch. Things that are backported should be moved to the section of trunk's CHANGES.txt for the branch they're backported to. We don't want a change listed twice in CHANGES.txt, since trunk generally includes all changes listed. So the only time things are marked as fixed in multiple versions are things that will be backported to multiple branches. Does that make sense?

        Show
        Doug Cutting added a comment - This is not a regression, so it shouldn't be flagged for potential inclusion in the 1.2.1 bugfix release (if we ever in fact make such a release). Also, since it's an "Improvement" it probably doesn't need an "Affects Version". Also, generally we only mark things as fixed in a single version, either the next upcoming release, or the release branch we intend to backport it to. We generally fix things in trunk, including adding a message to CHANGES.txt, then sometimes backport the patch to a release branch. Things that are backported should be moved to the section of trunk's CHANGES.txt for the branch they're backported to. We don't want a change listed twice in CHANGES.txt, since trunk generally includes all changes listed. So the only time things are marked as fixed in multiple versions are things that will be backported to multiple branches. Does that make sense?
        Hide
        Matt Massie added a comment -

        Makes sense.

        I will:

        • make sure to not mark an "Affects Version" unless I'm submitting a bug fix
        • set the "Fix Version" to the next major release
        • will update the "Fix Version" to include minor releases only if we decide to backport a fix
        Show
        Matt Massie added a comment - Makes sense. I will: make sure to not mark an "Affects Version" unless I'm submitting a bug fix set the "Fix Version" to the next major release will update the "Fix Version" to include minor releases only if we decide to backport a fix

          People

          • Assignee:
            Matt Massie
            Reporter:
            Matt Massie
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development