jss

Clone
Source Code
GIT

#25 [RFC] branches in upstream
Closed: fixed 5 years ago Opened 5 years ago by cipherboy.

Closed: fixed
Reopen Issue

This is an RFC for an enhancement in JSS upstream.

I'd like to prune away some of the old branches in JSS upstream and create a process around adding and removing branches in the future. For reference, here is a list of current branches and their last commit dates as of the time of writing.

What I propose is the following:

  • Remove all branches with last commits before 2014 (5 years as of 2019). In the link above, this is everything line 8 and after (270 branches!).
  • Decide on a deadline to remove the remaining branches which are 6 months old, merging in with master if necessary.

  • Leave the following version branches:

    • v4.4.x (was: JSS_4_4_BRANCH)
    • v4.5.x
    • master
    • In the above, x is a literal character x and not a variable.

  • Whenever master diverges from the last major/minor version (e.g., when v4.6.x is started from v4.5.x or v5.x.y is started from v4.x.y), we use the last v4.5.x release's tag as the starting point for the v4.5.x branch.

  • Whenever a major, breaking change will be made, a dev branch can be created to test and combine these changes (from separate PRs) before splitting the release branch and forking master.
  • To save the current state, a jss-archive repository will be created under the Dogtag PKI organization on GitHub. This will archive the state of the repository at the time of the switch from Mozilla's HG to GitHub and will contain all branches and tags at the time. That way, if anyone needs to reference the old branches, they can do so from a separate repository that has the same commit hashes as jss:
    git remote add archive https://github.com/dogtagpki/jss-archive git fetch --all git checkout archive/OLD_BRANCH
    And then all missing tags and branches will appear as desired.
  • The jss-archive repository currently is here: https://github.com/cipherboy/jss-archive -- I'd transfer ownership to Dogtag PKI org.

Benefits:

  • Significantly decrease the number of branches upstream.
  • Looking at branches on GitHub shows more relevant information (such as like OpenSCAP): the versioned branches and master.
  • We can keep branches around that correspond to downstream-supported distributions, with master roughly corresponding to rawhide.
  • Anyone can still access the old commits and branches and tags as usual by adding a new remote. (Tags in master's history will not be removed, but tags against other branches might be removed as a side-effect of removing the branch, but I'm not sure).

Downsides:

  • We'd lose existing branches that some users might be relying on (unlikely). They could recover these branches by adding a new remote.
  • We'd need to define new processes for contributing, based on where a patch goes (do we forward-port to master from the oldest branch we care about, or backport from master to the oldest branch we care about?).

Thoughts?

/cc: @mharmsen, @cfu, @jmagne, @edewata, @dmoluguw, @emaldonado
(updated: 10/09/2018 by @cipherboy)

While I understand the desire to do this, it should be understood that JSS is a project that has been around for over 20 years.

Consequently, while it may be exceedlingly rare, there are times when one needs to go looking for something that may have been checked-in to an extremely old branch (but never to the master).

Two things have been a part of my lengthy experience:

* If you throw something away, the odds of you actually "needing" it
   in the future increase dramatically.
* Alternatively, if you archive something, the odds are that you will never
   actually "need" to reference it in the future.

That being said, I far prefer to have something archived that no one will probably ever need to look at, rather than just throwing something away permanently.

In short, I would be perfectly fine with this approach of pruning branches going forward as long as there exists an archived version of the tree and all of its branches PRIOR to any pruning taking place.

my 2 cents
Edited 5 years ago by mharmsen

Metadata Update from @mharmsen:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
5 years ago

Thanks for the reply, @mharmsen!

I do agree that having an archive would be safest and appreciate your recommendation. I'll update the main document, but what I'd suggest is a jss-archive repository that archives Mozilla's mercurial repository on GitHub. This will contain all of the branches that we'd remove from the main jss repository in case we ever need to reference them.

By archiving the Mozilla repository, this'd give us the benefit of keeping a backup copy in case Mozilla decides to remove jss in the future. I think we can do it in such a way that we start from our upstream jss repository and check it out at the point in time that JSS was branched. This'd give us the benefit of having the same commit hashes between jss and jss-archive.

I've open an archive repository on my GitHub: https://github.com/cipherboy/jss-archive -- if this is suitable, I'll transfer ownership to Dogtag PKI. Note how
commit 6c67e535cd40ab1cdbe529579b15481d509be886 exists in both jss-archive and Dogtagpki/jss. I'll work on pulling tags as well.

Yes, a transfer of ownership of jss-archive to Dogtag PKI is prudent think to do.

Okay, after validating that the jss-archive repository has all the old branches from jss and no commits are missing (i.e., they have the same hashes), I've gone ahead and removed most of the old branches from the upstream jss repository.

The remaining branches are:

  • master -- for active development
  • gh-pages -- for documentation
  • JSS_4_4_BRANCH -- 4.4.x release branch

The candidates for removal are:

Note that all of the above branches are present in jss-archive.

Edited 5 years ago by cipherboy

The candidates for removal are:

JSS_EXPERIMENTAL_BRANCH -- I'd like confirmation from both @jmagne and @emaldonado before removing this branch. It looks like there are various bugfixes in this branch that aren't in master and aren't in the JSS_4_4_BRANCH: https://github.com/dogtagpki/jss/compare/master...JSS_EXPERIMENTAL_BRANCH

Yes, it can be removed. Likely experimental work @jmagne and were carrying on, he can confirm.

JSS_EXPERIMENTAL2_BRANCH -- I'd like confirmation from @emaldonado before removing this branch.

Yes, it's safe to remove.

BUG1322364_BRANCH -- I'd like confirmation from @emaldonado and @jmagne before >
Don't know as I'm not authorized to access bug #1322364.

You should have access to 1322364: it is against Mozilla's BZ, not Red Hat's: https://bugzilla.mozilla.org/show_bug.cgi?id=1322364

It appears to be releasing JSS v4.4.x, which has been done. (RH'z BZ is unrelated to JSS so that's why I suspected Mozilla's BZ). I've gone ahead and removed that branch.

Hearing no objections from @jmagne, and seeing as how the branches are available with the jss-archive, these three branches have been removed from upstream and this RFC is now complete.

Metadata Update from @cipherboy:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
5 years ago

Login to comment on this ticket.

Metadata
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.