[Infrastructure] GitHub Branch Cleanup

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Tue Feb 4 05:49:17 MST 2020

On 2020-02-03 9:18 μ.μ., Ryan Sleevi wrote:
> On Mon, Feb 3, 2020 at 1:51 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>     I do not oppose removing all previous "experimental" branches,
>     etc. As you noted, there were several people engaging in this
>     activity without clear instructions, git knowledge (including me
>     of course) or a clear documented process. We are getting better at
>     this and already have a somewhat documented procedure to create
>     redline versions by using a local repository. I think we should
>     nail down the procedure, check its results and if everything works
>     as expected, then remove the old branches. How does that sound?
> I don't see how they're related, or why we should gate removing the 
> branches on that process.
> I can appreciate that we run the risk of more branches being 
> introduced after we clean them up, and that's a compelling reason to 
> improve documentation, but it doesn't seem a compelling reason not to 
> remove now. We can remove new ones that crop up later, and iteratively 
> address whatever problem they're solving.
> I'm probably missing an important point you're trying to make, though, 
> so I'm hoping you can help me understand a bit more why deleting old 
> and unused branches should be gated on better process instructions.

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

If this doesn't make any sense to others and I am the only one with 
these concerns, we can safely ignore them.

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

More information about the Infrastructure mailing list