[Infrastructure] GitHub Branch Cleanup

[Dimitris Zacharopoulos (HARICA)]

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 <mailto: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.

>
> I wholeheartedly agree that we want to be able to provide folks easy 
> access to viewing changes before they're made. That's normally 
> accomplished through Pull Requests. The Pull Request remains an 
> artifact of the repository, and so doesn't go away, and you can also 
> download the pull request as a .patch file to reproduce the immutable 
> history, and attach that to the mail archive, if the concern is about 
> redundancy of storage.

Yes, I think this practice would satisfy everyone.

>
> 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.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200204/e2fefdff/attachment-0001.html>