A place to document issues related to transition to r/w git for httpd.

Items needed day zero

  1. ???

Items that can be refined after the migration

  1. Release Scripts
    1. stuff at https://svn.apache.org/repos/asf/httpd/dev-tools needs to be taught how to do the non-dist stuff with git. This could probably be handled during 1 low-stakes release.
  2. Development processes
    1. Assume no STATUS file and no existing dev scripts needed for backporting
    2. Do we need any extra email stuff enabled to get more activity on dev@?
    3. On 2.4.x, should we force  2 reviews needed to merge?
      1. What about CTR exceptions (ask infra?)
  3. Other repos like test framework, dev-tools
  4. Issues vs. bugzilla


Items needing no action

  1. WebSite (already git)
  • No labels

2 Comments

  1. Ruediger Pluem

    Why won't we need a STATUS file any longer? I was assuming the same process here to properly document the decisions. We could make PR's mandatory for backports though and just ease the process a little bit. Or is your intention to work via the reviewers functionality of PR's? With regards to CTR in this case I guess we could live with this in case there is no technical solution and people could do a kind of "dummy" review with just giving CTR - no review done comment on the PR.
    Regarding Issues vs. Bugzilla I would stay with Bugzilla for now. We can change this later if we like, but I don't want to do more than needed in one blow. Small steps (smile)

    1. Eric Covener

      Yes, I was assuming mandatory PR for backport and using the built-in review process.  At that point with everything happening in such a first-class GH way, it just seems very clunky to swivel over to a STATUS file.

      If we lose anything from the more curated STATUS file, maybe we can improve it with GH Projects to draw attention to some PRs especially if you want to flag something as a showstopper.