[Infrastructure] GitHub Branch Cleanup

[Ryan Sleevi]

On Tue, Feb 4, 2020 at 9:58 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-02-04 4:09 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Feb 4, 2020 at 7:49 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> I have no strong feelings about deleting these branches. I just wish we
>> could send some kind of "warning" or "instructions" to the Forum on how
>> they can track down changes applied to various ballots and how they can
>> compare with redlines introduced in ballots.
>>
>
> Are you talking historically or going forward?
>
>
> I was thinking historically. But I come to realize that we can't easily
> satisfy this so we have to settle for going forward.
>
>
>
>> For example, I recall Ben Wilson who was keeping all these branches just
>> to be able to demonstrate that the changes he applied to the Guidelines
>> were correct and in sync with the ballot that was approved.
>>
>
> Sure, but that's why we don't need them now, right? Or are you saying
> folks may want to retroactively look at them? If the latter, could you
> explain more?
>
>
> I was thinking of retroactively looking into ballot redlines that are
> available ONLY on GitHub. Before allowing just a redline to exist in the
> ballot motion, everyone could confirm what we voted on (checking
> historically). The ballot itself had all the necessary information in case
> something was not properly added in the Final Maintenance Guideline,
> someone could go back and verify that what we voted was indeed added in the
> updated Guideline. Keeping the actual redline in the ballot itself would
> accommodate that.
>
> I guess the best way to convince members that "it's ok to delete possible
> links to redlines" is that before Guidelines are published under a new
> version number, they are confirmed by multiple individuals that make sure
> the changes reflect the voted changes in the ballot.
>

Right. A Pull Request process can give us that system of checks and
balances and validation, which is why I'm so gung-ho on it.

However, as you note, the links we have today are already suspect, and
nothing we do may prevent those from being problematic. We could take the
exercise to go through every ballot for links to GitHub and make sure
there's an archive, but at the same time, the point is that the Git
repository (whether or not hosted by GitHub in the future) should be the
canonical thing.


> I agree we can and should provide directions on how to create Pull
> Requests, both as individuals proposing ballots or (as we've often
> discussed), if they don't want / are unable to, then the Chair / Vice Chair
> / Delegates / whomever can do so.
>
> If this doesn't make any sense to others and I am the only one with these
>> concerns, we can safely ignore them.
>>
>
> I'm trying to be precise, not to dismiss your concerns, but to better
> understand them, because I definitely want to make sure you're 100%
> comfortable with what we go with :) Apologies if that seems very
> direct/dismissive - but it's rather quite the opposite! :D
>
>
> I think you have understood my concerns. I am satisfied with the answers
> posted so far. Providing a documented step-by-step procedure that addresses
> these concerns going forward is a good next step. I wish we could make diff
> files out of ballot redline links before we delete the branches. Do you
> think that would work? If it's too much effort, I'm still good with just
> deleting the old branches, unless someone else has an objection.
>

Right, I'm not opposed, other than its a lot of work, and I want to make
sure we understand why that work is being done and that it's useful work :)

If I understand the proposal correctly:
- Scan all of our mail archives for links to GitHub
- Download any links/diffs/PRs as .patch files
- Attach them to the Wiki (which itself doesn't guarantee files are
stable/archived, nor does the mail archive)
- ???

At this point, I think if there were still lingering questions about the
application of the red line, then the next step would be what we did in the
past when things got jumbled - vote to readopt in their present form.

I say all of this as one of the few people who does go through the mail
archives, well back into 2009, to understand how things happened and what
changed. Despite my passion for understanding how and why and what
happened, to make sure both process was followed and understand bugs, I
don't think the GitHub links would be entirely valuable to that :)

That said, going forward, I agree we've got options and can do better here
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200204/eb3f4fb4/attachment.html>